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

["Noam Eppel" <noameppel () hotmail com>]

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