Hashing Passwords With ASP.NET MVC 3

Question

I am right now in the process of trying to figure out the best way of hashing the password for my ASP.NET MVC 3 application. From what I hear, it is good to use the given password and a random salt and then store the hashed password and salt together. My question is won't that make the random salt pointless? I mean the reason to hash a password is because if someone get into your database, they don't have the plain passwords and the salt make it much much harder to reverse the hash to get the password but but if I store the hash with the password, what is the point of the salt (my knowledge on hashing is every limited so I could be completely off base with my thinking).

My second question is what hashing method is the best one to use? I read that MD5 (which is what I have always used) is very simple to crack. I hear the bcrypt/sha512 are pretty good. Which one should use? I know that C# by default comes with the sha512 hashing. From what I can see, bcrypt is not included in the .NET library, are there any good libraries for C# and bcrypt?

Answer 1

there is no need to store the salt in a different location, you should always assume salt in known by an attacker anyway and its purpose is not to be an extra password!!!!

In .NET this API will do everything you need, it will create big crypto random salt as well as HMACSHA512 hashing and key stretching via byte swapping before each AES encryption pass :)

http://sourceforge.net/projects/pwdtknet/

Answer 2

Salting will increase the resistance against a rainbow/dictionary attack. A few security exploits that have occurred this year were because the web application's database contained passwords without a salt and they were done with md5. So a simple rainbow attack produced the password within seconds for a few users that used terrible passwords.

For providing user authentication with MVC 3, you should really use the framework for this sort of thing. Coming up with your own custom authentication provider could cause problems if you don't do it right.

Take a look at http://msdn.microsoft.com/en-us/library/ff398049%28v=VS.98%29.aspx and http://msdn.microsoft.com/en-us/library/yh26yfzy.aspx. If you use the .NET membership system, you don't need to do any low level database or password management. You just put the [Authorize] tags around the controller actions that need to be auth'd and your done.

Answer 3

Here's a nice C# implementation of bcrypt:

http://bcrypt.codeplex.com/

Answer 4

SHA512 is a good choice for hashing in .net and if you store the salt with the password it is a little bit pointless (but the "decrypting" still would need a longer time), but you could store the salt somewhere else, so the DB isn't enought:

• store the salt just somewhere else
• use always the same salt and e.g. hardcode it in the code or save it in the app-settings
• generate the salt for every user from some other information e.g. MD5 of the user-id
• generate the salt for all users from some system settings like hostname or similar

UPDATE:
As Mike already stated I am wrong with the "pointless" statement above. Even when the salt is known it will render Rainbow Table Attacks useless (or a lot more unlikely), so you should always use a salt even when storing the salt right next to the hash (linux for example does store the user passwords in the shadow file in a form of "$id$salt$hashed")!

Answer 5

I have allways used the following approach to store passwords

public static string MD5Hash(string value)
{
    return Convert.ToBase64String(new MD5CryptoServiceProvider().ComputeHash(new UTF8Encoding().GetBytes(value)));
}

It's has never been a question if it is possible to restore such hash to original password.

Answer 6

If they hacked into your security database to steal people's hashed password, then it is unlikely that they would really need the password at that point. They already have access to all the data in the database most likely. An MD5 hash is probably fine for the average website if it is something simple with data that is not valuable. Other more difficult hashing methods would be fine for data that is more likely to be valuable.