MD5 proposal

> Poul-Henning Kamp wrote:
> 
> > In message <20020325130131.T20936 at isnic.is>, Olafur Osvaldsson writes:
> > 
> > 
> >>>auth:             MD5-PW 4aabd3dbc0746c8a4b5467f99a4f8524
> >>>
> >>>
> >>Why not use md5 crypt wich is already used on many operating systems for
> >>passwords?
> >>
> >>auth:             MD5-PW $1$sD9e4pQn$1832L4.BxsZHusy0plg8i0
> >>
> > 
> > The source can be found here:
> > 
> >    http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libcrypt/crypt-md5.c
> >
> 
> 
> I agree that a salt makes dictionary attacks very hard if not 
> impossible. And this is good argument in favour of the Olafur's and 
> Poul-Henning's proposal.

   A reasonbly lengthy (and random) salt only makes pre-computed dictionary 
attacks impossible, but it does not prevent brute force
dictionary attacks.  John the Ripper (www.openwall.com/john) has support
for dictionary-based attacks on des-crypt, FreeBSD md5-crypt, and
OpenBSD bcrypt password hash functions.

> 
> My main concern here would be that basing the proposed method on an 
> implementation (md5-crypt), which may change or may be mixed with some 
> other implementation, rather than on the documented algorithm (md5 
> hash), which cannot, may cause confusion in the future.

   Changing an existing Unix password hash function would be a very
unlikely action as you would break portability of password hashes between
systems (speaking as a former sys-admin, this would be
a nightmare).  This is one reason for longevity of des-crypt (despite
it's documented weaknesses).

> 
> And, as a side question from a person far from cryptography, is it a 
> proved fact that iterative complexity of md5-crypt makes the hash better?
> 

    It's a combination of the salt and computational complexity that
makes md5-crypt significantly better than straight MD5.  OpenBSD's bcrypt
goes a step further than md5-crypt in computational intensity and also
allows one to specify the number of interation rounds in the hash to provide
further strength as computing power progresses.  One could argue that,
absent any mandatory password goodness/length requirements, the existing
des-crypt is better than straight MD5.

    Speaking from an RPSLng perspective, I'd like to see any new hashed
password based auth mechanism provide better support for keeping the
hash private.  While I'm not necessarily arguing this should be mandatory,
I believe it should at least be optional.  One way to provide better support
for this would be to include some sort of identifier with the hash.  This
could either be on the same auth: line as the hash, or the identifier could
be a key to a separate object that contains the actual hash (as is done
with PGPKEY based authentication).

 -Larry Blunk
  Merit


> Regards,
> 
> Andrei Robachevsky
> RIPE NCC