In message <28945.1022163677@itojun.org>, itojun@iijlab.net writes:
>>In my opinion, there's no technical reason to do it.  If you want to 
>>add a new scheme, SHA512 would be a much better choice.  The only 
>>reason I can see is password file compatibility with OpenBSD.
>
>	did you check USENIX paper on openbsd $2$ password?  i'm guessing
>	you did, and am wondering why you reject their reasoning.  are there
>	any flaws in their logic?
>

The comparison against MD5 in the paper is somewhat flawed.  They take 
issue with the specific way md5crypt is instantiated in code, rather 
than with the concept of using MD5 (or some version of SHA) as the base 
for a secure password hash.  If one iterated MD5 some number of times, 
you could make it arbitrarily and tunably expensive to check a 
password, just as with their Blowfish-based scheme (which makes the 
number of rounds variable, i.e., it changes the inside of the 
algorithm, rather than the outside).

My suggested algorithm is this:

	s = salt;	/* or s = hmac_sha512(site-specific-string, salt); */
	for (i = 0; i < num_iterations; i++)
		s = hmac_sha512(password, s);

There is a proof of security for HMAC, based on the black box 
properties of the underlying hash function.  Both the salt and the key 
can be arbitrarily long (well, limited to 2^64 bits, I think).  The 
number of iterations is adjustable over time, just as with the Blowfish 
scheme.

The Blowfish-based scheme has one advantage:  it may be harder to build a 
massively-parallel hardware cracker.  I assert that if your threat 
model includes adversaries who can afford such systems and who have 
access to your hashed passwords, you're probably using token-based 
authentication.  Or at least, you should be...

The discussion of salt size has an important omission, too.  The 
authors note (correctly) that with too small a salt size, you can get 
collisions, and hence a speedup of (roughly) num-pws/num-salts.  They 
then go on to assert that 2^12 salts are too few.  That's far from 
clear -- how large is your password file?  Even if it's in the 10s of 
thousands, the speedup factor is a rather small integer.  While I 
wouldn't mind a larger salt, for most systems that use password files 
for authentication that factor is too small to be interesting.

So, as I said before:  Blowfish isn't a bad way to hash passwords; it's 
simply not designed for that purpose.  SHA512 matches the requirements 
much better.

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com ("Firewalls" book)