Re: MD5 Password encoding, "straight" vs "salted" hashes

[Peter Watkins <peterw () usa net>]

On Wed, Aug 17, 2005 at 10:54:20AM +0300, Oleg Topchiy wrote:

> Wednesday, August 17, 2005, 7:52:15 AM, you wrote:

> > If you are implementing a one-way hash correctly, there should be no need to
> > store the plaintext passwords. All that should be stored is the resulting
> > hash of each password.
>
> > For example, if the plaintext password is, "secretpassword" the MD5 hash of
> > that password would be, "31435008693ce6976f45dedc5532e2c1".
>
> > That hash can be stored in the user database instead of a password. The
> > advantage of this is that if the confidentiality of that database is
> > compromised, no passwords will be revealed. There is no feasible way to
> > reverse a one-way hash function to reveal the plaintext password.

> It's true, but if the whole database is comporomised, there is a good
> chance that vast number of the passwords won't stand against even
> dictionary attack, leave alone bruteforce. Although this method
> provides best balance between complexity and security.

"Best" balance? Noam suggested a "straight" hash of the password. Don't do
that. If you're going to store hashes of passwords (good idea), use "salted"
hashes, whether a common standard like BSD's MD5-based crypt() routine, or
something else that at least uses significantly long random salts, if not 
also some fairly time-consuming algorithm.

Dictionary attacks against straight hashes are relatively feasible, as only
one hashed value is needed in the attack dictionary for any given password.

Straight hashes also allow attackers to ascertain which accounts have the
same cleartext (MD5 hex of "secretpassword" is always the same value, but
there are 64^8 possible BSD MD5 crypt() encodings of "secretpassword")
-- crack or socially engineer the password for one account, and the 
attacker can use the others, too.

Finally, since it's expensive to convert "straight" hashes to "salted"
hashes -- you either have to crack each straight hash or wait for the
user to provide the cleartext [e.g., log in] to determine a valid salted
hash for each straight hash you've recorded -- you don't want to start 
with straight hashes for any new systems. Use somebody else's time-tested
salted crypt() routine for storing passwords if you expect the users to
supply cleartext passwords to aythenticate themselves.

Here are sources of relatively free implementations of Poul-Henning Kamp's
BSD MD5 salted crypt that I've had good luck with:

C/ original MD5/salted crypt.c  -  http://people.freebsd.org/~phk/
a CPAN Perl module port         -  http://search.cpan.org/dist/Crypt-PasswdMD5/
and a Java port                 -  ftp://ftp.arlut.utexas.edu/pub/md5/
  // note: the Java port should use SecureRandom for better security

-Peter