On 2002-01-28 at 09:33 +0000, Philip Hazel wrote: > > courier 'userdb' md5 hashed string:
> > $1$eYrvxTAm$Wz4Wkxe5exy/5VhkuTnYH0
>
> That is neither base-64 nor hex, being 34 characters long. So I don't
> know what it might be I'm afraid.
Warning: I'm about to vent -- search for the two blank lines for info.
It's the poxing stupid "Let's-all-overload-crypt-with-other-semantics"
crypt()-like MD5 checksum.
See, in BSD-land (which I normally very much like living in), someone
had this bright idea. crypt() is _always_ just used for system
passwords, right? So, overload it. crypt() doesn't mean the old normal
crypt() algorithm if the salt-string looks like it starts with some
special magic.
All would be wonderful if it worked reliably. Some old FreeBSD releases
got it badly wrong. Hence some authentication libraries I have here,
lug around their own fcrypt-derived crypt() implementation, just to
reliably be able to perform a crypt() function. You know, the thing
which is 13 chars long, two chars salt, 11 hash.
This doesn't even touch the programs which assume that crypt() is, well,
crypt() and produces 13 chars of output, always. Because that's the old
_definition_ of crypt. So, to safe moving to a new function which
handled the storage space and separated the usage from the
implementation, a truly grotesque hack (which keeps breaking) was born.
So, what you're looking at above is a password-field from a BSD system.
The "$1" means MD5. On OpenBSD, "$2" means Blowfish. The following '$'
separates the algorithm-indicator from the data. You then have salt, up
until the third '$', and then the hashed password, base-64 encoded, in
the final 22 characters.
--
In 1998 more than three times as many people in the US were killed
by incompetent physicians than were killed by handguns, yet the
President of the A.M.A. is adopting "gun safety" as his platform.
