Poul-Henning Kamp wrote:
In message <20020325130131.T20936@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