Jacques Le Roux wrote: > 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
Hmm. Just did a grep+sed on all the data files, and there are a ton of matching hashed passwords. I'm going to hold off on my change for a bit, so that I can scan the code to see what the actual real passwords are, and then re-hash them all with salts. We'll still end up having hard-coded salt+hash values, but we'll still be better off. > > 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. >> > >
