I've got a series of changes queued up to HashCrypt, and LoginServices.
The hashed passwords that ofbiz uses are a hexadecimal encoding of a
byte array. The set of characters used are [a-z0-9]. Because of
this, adding new encodings is possible to do in a backwards compatible
manner.
The format I have is based on crypt(3), a glibc manpage.
The system would function like this:
Read hashed password from the database.
If it starts with {, then it is the existing format.
If it starts with $, then it is the crypted format.
Otherwise, it's the very old format.
The existing format is "{hashmethod}value". The crypted format is
"$hashnumber$salt$value". The crypted format is compatible with
/etc/shadow, at least on a mostly superficial level.
I have the code modified to support this, and made certain all test
cases still run. Newly set passwords automatically have the new
crypted format, while existing database entries continue to be usable.
The event that started this was the jira intrustion issue. None of
the passwords have a salt at all, so I decided to implement such a
feature.
ps: The new crypted format changes the encoding of the value from hex,
to [a-zA-Z0-9./], which is 64 bits, instead of 16. I'd also like to
increase the size of the currentPassword field, so that SHA-512 could
be supported. It won't fit in 60 chars.
