[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Storing passwords
- From: Jay Carlson <nop@...>
- Date: Tue, 22 May 2012 13:58:02 -0400
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 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.