Re: Storing passwords

[Jay Carlson <nop@...>]

On May 22, 2012, at 3:02 AM, William Ahern wrote:

> If you insist on using bare MD5, you should at least use HMAC-MD5, using the
> password as the secret key and the salt as the message.

This should be much better than concatenation.  See http://en.wikipedia.org/wiki/HMAC#Design_principles for the really short version.

> MD5 alone is
> effectively broken for all cryptograhic uses.

I think this is probably a bit strong for the reversibility case, although I would not use it for anything given a choice. The larger context is that, like string concatenation in SQL queries (see http://bobby-tables.com/ ), unsalted hashes have been involved in a lot of high-visibility Web attacks and people are trying to make them socially unacceptable. You can still implement salting poorly, and me not thinking HMAC is an example.

GI Joe[1] has good advice: "Math is hard--let's go shopping!" Let other people build your authentication mechanisms. If nothing else, you can blame them if it breaks. A modern Unix crypt() is not bad; although not obvious from some documentation, even the "md5" crypt is actually a thousand rounds.

I argue that designers who are aware of salt and the attack models it counters are more likely to remain afraid of the right things. But as you say, there is a temptation to leave a bad or incomplete implementation in place, especially if people think "hash" (or "salt") are magic. An example:

Apache Tomcat did not support salt in hashed password authentication until like 6.0 without source modification. One exception: the LDAP module had a special hack to interoperate with a particular LDAP server which stored salted passwords. So there was some awareness of this issue among committers, but this did not help. 

Jay

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