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?

Solution 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/

Solution 2

Here's a nice C# implementation of bcrypt:

http://bcrypt.codeplex.com/

Solution 3

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")!

Solution 4

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.

View more solutions

Comments

[mattypiper]

If you really want to dig into the internals of your hashing method, here is a good article on this. aspheute.com/english/20040105.asp

[Tails]

MD5 is a very weak hash and can be brute forced relatively quickly using modern PCs. You should give this post a read: stackoverflow.com/questions/1756188/…

[Anubis]

I have read this post and i can assume that 1) if someone will store the database he/she can brutforde the passwords in case of using crypto method without a secret key. From this point of view MD5 and SHA256 and SHA1 have identical strength for brute force. 2) the only way to have a really strong passwords is using the hash method width a secret key that will be stored in application (not in database). Then if the database will be stolen noone brute force can crack your passwords.

[Mike Cole]

There is a whole lotta bad advice in this post. Here's a better source: crackstation.net/hashing-security.htm

[Anne]

+1 for the nice answer, especially "you should always assume salt in known by an attacker".

[Jim Birchall]

Good answer. All the salt is there to do is to make the act of creating rainbow tables more difficult for example if you have one salt for all users (or no salt) then to crack 1000 passwords you would only need 1 rainbow table. When you store random salt with the password you need 1000 rainbow tables to crack 1000 passwords.