U4-585 - Hash AND Salt Passwords

Created by Sebastiaan Janssen 19 Aug 2012, 14:54:47 Updated by Shannon Deminick 16 Feb 2014, 23:58:19

Passwords should be hashed AND salted

From OWASP: If each password is simply hashed, identical passwords will have the same hash. There are two drawbacks to hashing only the password:

  1. Due to the birthday paradox (http://en.wikipedia.org/wiki/Birthday_paradox), the attacker can detect if multiple users share the same password, especially if the number of passwords in the database is large.
  2. An attacker can also use a list of precomputed hashed values (http://en.wikipedia.org/wiki/Rainbow_table) to break passwords in seconds.

More details: https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet

''Originally created on CodePlex by [Myster|http://www.codeplex.com/site/users/view/Myster]'' on 6/21/2012 2:17:47 AM [Codeplex ID: 30855 - Codeplex Votes: 2]

Imported comments

''Comment by [leekelleher|http://www.codeplex.com/site/users/view/leekelleher] on 6/21/2012 2:40:21 PM:'' Umbraco uses HMACSHA1 to encrypt the passwords, using the password itself as the salt/key.

I am no security expert, so can't comment on how secure that actually is, but it does seem pretty secure.

Any suggestions on how to improve it?

''Comment by [Myster|http://www.codeplex.com/site/users/view/Myster] on 7/13/2012 9:48:53 AM:'' One reason for salting is to prevent the use of a rainbow table[1] to get passwords from the hash. Using the password as the salt would not mitigate that.

[1] http://en.wikipedia.org/wiki/Rainbow_table

''Comment by [Myster|http://www.codeplex.com/site/users/view/Myster] on 7/13/2012 10:10:30 AM:'' Here's a pod-cast covering some of the basics: http://dotnetrocks.com/default.aspx?showNum=735 because reading about security is deadly boring ;-)

Comments

Karl Kopp 02 Oct 2012, 22:20:59

A couple of articles from Troy Hunt - passwords and how they are hacked (http://www.troyhunt.com/2012/06/our-password-hashing-has-no-clothes.html) and the stronger password hashing options in .NET with MS universal providers (http://www.troyhunt.com/2012/07/stronger-password-hashing-in-net-with.html).


Murray Roke 03 Oct 2012, 00:26:12

Oh well, it was a good idea once upon a time.... now what?


Matthew Bliss 03 Oct 2012, 09:13:44

The article by Troy Hunt quoted above, suggests that even if the salt is changed an attacker can still break the passwords in minutes as opposed to seconds. Is there any benefit in changing this? If passwords can be cracked that quickly then surely the security of the database needs to be the priority - they can only crack passwords if they can get at the data in the first place.


Murray Roke 03 Oct 2012, 21:24:24

one suggestion is to have a app specific salt + a user specific salt, so the database and (wherever the app specific salt is stored) must both be compromised. Troy also mentions security is never going to be 100% ... or perhaps just an app specific salt (saves changing the schema)


Shannon Deminick 16 Feb 2014, 23:58:19

Passwords are properly salted when stored as hashes with the new membership providers in 6.2/7.1. The new providers also respect the hashing algorithm specified in the web.config - and in .net 4.5 the default algorithm is much stronger anyways (HMACSHA256). ... So in any case, it is much better than what it was before.


Priority: Normal

Type: Bug

State: Fixed

Assignee: Shannon Deminick

Difficulty: Normal

Category:

Backwards Compatible: True

Fix Submitted:

Affected versions:

Due in version: 7.1.0, 6.2.0

Sprint:

Story Points:

Cycle: