Support of 'salt' based password schemes - IMPLEMENTED

[Adam Heath <do...@brainfood.com>]

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.

Re: Support of 'salt' based password schemes - IMPLEMENTED

[Adam Heath <do...@brainfood.com>]

Jacques Le Roux wrote:
> From: "Adam Heath" <do...@brainfood.com>
>> 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.
>>
> 
> 

Re: Support of 'salt' based password schemes - IMPLEMENTED

[Jacques Le Roux <ja...@les7arts.com>]

From: "Adam Heath" <do...@brainfood.com>
> 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.
>