Jacques Le Roux wrote:
> From: "Adam Heath" <
[hidden email]>
>> 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.
>>
>
>
Locked
