From: "Adam Heath" <[email protected]>
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.
Great, I expected someone will saw the breach (from the Jira attack) and will tackle it. The related existing issues are https://issues.apache.org/jira/browse/OFBIZ-1151 https://issues.apache.org/jira/browse/OFBIZ-3006 At https://issues.apache.org/jira/browse/OFBIZ-1151?focusedCommentId=12542952&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12542952 Michael Jensen suggested something like your solution Thanks Jacques
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.
