[Sql-Server]what data type to use for password salt and hash values and what length?

sql-server-2005 hash types passwords salt

24,751

Solution 1

ASPNET_DB says this - can't go wrong.

Password nvarchar(128) NOT NULL,
PasswordSalt nvarchar(128) NOT NULL,

while 128 may seem like a lot, various types of encryption can result in larger strings than you started out with. There is absolutely no reason not to follow the lead of the very smart people who have spend thousands of man hours developing the asp.net membership system.

Solution 2

We store our passwords as a binary SHA512 hash

24,751

Author by

ACP

Updated on May 19, 2020

Comments

ACP almost 4 years

I am generating salt and hash values from my passwords by using,

string salt = CreateSalt(TxtPassword.Text.Length);
string hash = CreatePasswordHash(TxtPassword.Text, salt);

private static string CreateSalt(int size)
{
    //Generate a cryptographic random number.
    RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();
    byte[] buff = new byte[size];
    rng.GetBytes(buff);

    // Return a Base64 string representation of the random number.
    return Convert.ToBase64String(buff);
}

private static string CreatePasswordHash(string pwd, string salt)
{
    string saltAndPwd = String.Concat(pwd, salt);
    string hashedPwd =
     FormsAuthentication.HashPasswordForStoringInConfigFile(
     saltAndPwd, "sha1");

    return hashedPwd;
}

What datatype you would suggest for storing these values in sql server? Any suggestion...

Salt:9GsPWpFD

Hash:E778AF0DC5F2953A00B35B35D80F6262CDBB8567

TomTom almost 14 years

-1 / sorry, but "microsoft is smart, me stupid, me follow massa" is a bad attitude. Especialyl given the tremendous amounts of stupidity coming out of Microsoft at times. Bring arguments.
Sky Sanders almost 14 years

@tomtom - wow. I guess that you have a lot of experience implementing security stacks and have been over every line of source code and column and stored procedure that composes the very robust and flexible asp.net provider stack to back up your summary judgement of my statement. hmmm... I know someone that fits that description.....
TomTom almost 14 years

Well, i did. But I also try using my brain and not follow blindly things other people may have done - out of totally different reasons that you dont even care to give. Btw., I seriosuly doubt even MS would spend thousands (!) of man hours just developin the asp.net membership system when other people take mabe 100 or so all in all. And you know the membership system was "tacked on" in a later .net version after the smart people totally overlooked making it extensible by any means? MS is not perfect.
TomTom almost 14 years

Without using salt this is stupi and gross neglect as it means a simple dictionary attack can hack passwords - and do so the faster the more passwords your list has.
Sky Sanders almost 14 years

@Pandiya - well, it really depends on the approximate length of your salt. I suspect that the similar lengths were simply out of convention rather than expected necessity. You could probably cut in half with no problems. But I would stay with a variable length field unless you want to have to trim your query results, in the case of CHAR, or convert to and from bytes/string in order to compare, in the case of binary. The wide type (N) is likely not necessary, but again, it is likely from convention and consistency.
TomTom almost 14 years

Actually the password as nvarchar(128) makes sense because the membership provider allows to store unencrypted passwords in the database if configured so - in this case both length as well as special characters MAY be allowed. This is toatlly stupid bad practice, but then the provider model is generic and configurable and also accounts for low security scenarios. Note though that non-ascii chars as passwordsa re always stupid - you never know whether you need to log in from an internet cafee and can not rely on keyboard settings in such scenarios.
Joe Phillips almost 14 years

You can do the same with a salt
ghord over 9 years

@JoePhilllips I think that he ment rainbow table attacks, which are avoided when using salt.
Joe Phillips over 9 years

@ghord I don't disagree. Either way, you hash the salted password and it gets stored as a binary SHA512 hash (I guess it's technically not the password anymore)
Rohan Shenoy over 4 years

If I'm using SHA512 algorithm then size exceeds. It's better to make it NVARCHAR(Max)
user460114 about 4 years

128 was perfect for my password hashing involving three interations of the hash with salt added.