views:

300

answers:

2

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

+1  A: 

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.

Sky Sanders
-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.
TomTom
@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.....
Sky Sanders
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
@code poet password length for salt is a good or bad idea?
Pandiya Chendur
@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.
Sky Sanders
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.
TomTom
A: 

We store our passwords as a binary SHA512 hash

Joe Philllips
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.
TomTom
You can do the same with a salt
Joe Philllips