Hello Peter,
To clarify, for the purpose of brevity I didn't include any information
about including a random value (salt) into the hash equation.
Certainly, a straight hash is not recommended.
Regards,
Noam
From: Peter Watkins <peterw@usa.net>
To: Oleg Topchiy <edge@ua.fm>
CC: webappsec@securityfocus.com
Subject: Re: MD5 Password encoding, "straight" vs "salted" hashes
Date: Wed, 17 Aug 2005 12:55:47 -0400
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
