Password hash patch

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Password hash patch

Sebastian Schirmer
Hi David,

as recently reported we found out that the password hash implementation in
ofbiz was odd. We have implemented a workaround to qualify existing
accounts with an old funny hashed password to a real sha /md5 hash after
log on.

The function is configurable with password.autoconvert.hash.type=true
in framework/security/config/security.properties


Other cryped data like credit card also affected form the password hash
algo. We are using the old funny hash for this fields because of production
compatibility.

We are currently working with an ofbiz revision 651887. The attached patch
works against this revision.

Feel free to use or merge our changes against the current trunk. I have no
write access to the repository.

kind regrads
Sebastian

--
 Sebastian Schirmer

 ZYRES digital media systems GmbH
 Eschersheimer Landstr. 5-7 60322 Frankfurt am Main
 Phone +49 (0)69 98 55 99 - 0
 Fax   +49 (0)69 98 55 99 - 11

 Firmensitz: Eschersheimer Landstr. 5-7 60322 Frankfurt am Main
 Registergericht: Amtsgericht Frankfurt am Main, HRB 76374
 Geschäftsführer: Martin Wepper, Sebastian Schirmer

 http://www.zyres.com/

-- RFC|1855|2.1.1

Reply | Threaded
Open this post in threaded view
|

Re: Password hash patch

Tim Ruppert
There is no attachment here Sebastian. Please make a JIRA issue out of  
it, post the patch there, and then feel free to send a link to the  
list letting everyone know this has happened.

Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com

o:801.649.6594
f:801.649.6595


On Jun 16, 2008, at 6:05 AM, Sebastian Schirmer wrote:

> Hi David,
>
> as recently reported we found out that the password hash  
> implementation in ofbiz was odd. We have implemented a workaround to  
> qualify existing accounts with an old funny hashed password to a  
> real sha /md5 hash after log on.
>
> The function is configurable with password.autoconvert.hash.type=true
> in framework/security/config/security.properties
>
>
> Other cryped data like credit card also affected form the password  
> hash algo. We are using the old funny hash for this fields because  
> of production compatibility.
>
> We are currently working with an ofbiz revision 651887. The attached  
> patch works against this revision.
>
> Feel free to use or merge our changes against the current trunk. I  
> have no write access to the repository.
>
> kind regrads
> Sebastian
>
> --
> Sebastian Schirmer
>
> ZYRES digital media systems GmbH
> Eschersheimer Landstr. 5-7 60322 Frankfurt am Main
> Phone +49 (0)69 98 55 99 - 0
> Fax   +49 (0)69 98 55 99 - 11
>
> Firmensitz: Eschersheimer Landstr. 5-7 60322 Frankfurt am Main
> Registergericht: Amtsgericht Frankfurt am Main, HRB 76374
> Geschäftsführer: Martin Wepper, Sebastian Schirmer
>
> http://www.zyres.com/
>
> -- RFC|1855|2.1.1
>


smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Password hash patch

David E Jones
In reply to this post by Sebastian Schirmer

Sebastian,

Please take a look at the current code base. I believe the same  
problem you are looking at was fixed a few weeks ago. The current code  
supports the bad hex encoding as well as proper hex encoding (both use  
the same hashing, which was fine), and it supports a prefix to specify  
the encryption type (MD5, SHA, etc).

-David


On Jun 16, 2008, at 6:05 AM, Sebastian Schirmer wrote:

> Hi David,
>
> as recently reported we found out that the password hash  
> implementation in ofbiz was odd. We have implemented a workaround to  
> qualify existing accounts with an old funny hashed password to a  
> real sha /md5 hash after log on.
>
> The function is configurable with password.autoconvert.hash.type=true
> in framework/security/config/security.properties
>
>
> Other cryped data like credit card also affected form the password  
> hash algo. We are using the old funny hash for this fields because  
> of production compatibility.
>
> We are currently working with an ofbiz revision 651887. The attached  
> patch works against this revision.
>
> Feel free to use or merge our changes against the current trunk. I  
> have no write access to the repository.
>
> kind regrads
> Sebastian
>
> --
> Sebastian Schirmer
>
> ZYRES digital media systems GmbH
> Eschersheimer Landstr. 5-7 60322 Frankfurt am Main
> Phone +49 (0)69 98 55 99 - 0
> Fax   +49 (0)69 98 55 99 - 11
>
> Firmensitz: Eschersheimer Landstr. 5-7 60322 Frankfurt am Main
> Registergericht: Amtsgericht Frankfurt am Main, HRB 76374
> Geschäftsführer: Martin Wepper, Sebastian Schirmer
>
> http://www.zyres.com/
>
> -- RFC|1855|2.1.1
>

Reply | Threaded
Open this post in threaded view
|

Re: Password hash patch

Sebastian Schirmer
Yes, I have seen the changes in current codebase. The fixes in the current
trunk are working with a fresh project but not against an older production
database eg. credit card fields is not decrypded any more. Our patch solve
this.

kind Regards
Sebastian



--On Montag, 16. Juni 2008 10:18 -0600 David E Jones
<[hidden email]> wrote:

>
> Sebastian,
>
> Please take a look at the current code base. I believe the same problem
> you are looking at was fixed a few weeks ago. The current code supports
> the bad hex encoding as well as proper hex encoding (both use the same
> hashing, which was fine), and it supports a prefix to specify the
> encryption type (MD5, SHA, etc).
>
> -David
>
>
> On Jun 16, 2008, at 6:05 AM, Sebastian Schirmer wrote:
>
>> Hi David,
>>
>> as recently reported we found out that the password hash
>> implementation in ofbiz was odd. We have implemented a workaround to
>> qualify existing accounts with an old funny hashed password to a
>> real sha /md5 hash after log on.
>>
>> The function is configurable with password.autoconvert.hash.type=true
>> in framework/security/config/security.properties
>>
>>
>> Other cryped data like credit card also affected form the password
>> hash algo. We are using the old funny hash for this fields because
>> of production compatibility.
>>
>> We are currently working with an ofbiz revision 651887. The attached
>> patch works against this revision.
>>
>> Feel free to use or merge our changes against the current trunk. I
>> have no write access to the repository.
>>
>> kind regrads
>> Sebastian
>>
>> --
>> Sebastian Schirmer
>>
>> ZYRES digital media systems GmbH
>> Eschersheimer Landstr. 5-7 60322 Frankfurt am Main
>> Phone +49 (0)69 98 55 99 - 0
>> Fax   +49 (0)69 98 55 99 - 11
>>
>> Firmensitz: Eschersheimer Landstr. 5-7 60322 Frankfurt am Main
>> Registergericht: Amtsgericht Frankfurt am Main, HRB 76374
>> Geschäftsführer: Martin Wepper, Sebastian Schirmer
>>
>> http://www.zyres.com/
>>
>> -- RFC|1855|2.1.1
>>
>




Reply | Threaded
Open this post in threaded view
|

Re: Password hash patch

David E Jones

Are you saying that this patch should be used instead of the previous  
changes, or does it work along with them? I'm planning to look into  
this soon, but I thought I'd ask first.

-David


On Jun 16, 2008, at 11:01 AM, Sebastian Schirmer wrote:

> Yes, I have seen the changes in current codebase. The fixes in the  
> current trunk are working with a fresh project but not against an  
> older production database eg. credit card fields is not decrypded  
> any more. Our patch solve this.
>
> kind Regards
> Sebastian
>
>
>
> --On Montag, 16. Juni 2008 10:18 -0600 David E Jones <[hidden email]
> > wrote:
>
>>
>> Sebastian,
>>
>> Please take a look at the current code base. I believe the same  
>> problem
>> you are looking at was fixed a few weeks ago. The current code  
>> supports
>> the bad hex encoding as well as proper hex encoding (both use the  
>> same
>> hashing, which was fine), and it supports a prefix to specify the
>> encryption type (MD5, SHA, etc).
>>
>> -David
>>
>>
>> On Jun 16, 2008, at 6:05 AM, Sebastian Schirmer wrote:
>>
>>> Hi David,
>>>
>>> as recently reported we found out that the password hash
>>> implementation in ofbiz was odd. We have implemented a workaround to
>>> qualify existing accounts with an old funny hashed password to a
>>> real sha /md5 hash after log on.
>>>
>>> The function is configurable with  
>>> password.autoconvert.hash.type=true
>>> in framework/security/config/security.properties
>>>
>>>
>>> Other cryped data like credit card also affected form the password
>>> hash algo. We are using the old funny hash for this fields because
>>> of production compatibility.
>>>
>>> We are currently working with an ofbiz revision 651887. The attached
>>> patch works against this revision.
>>>
>>> Feel free to use or merge our changes against the current trunk. I
>>> have no write access to the repository.
>>>
>>> kind regrads
>>> Sebastian
>>>
>>> --
>>> Sebastian Schirmer
>>>
>>> ZYRES digital media systems GmbH
>>> Eschersheimer Landstr. 5-7 60322 Frankfurt am Main
>>> Phone +49 (0)69 98 55 99 - 0
>>> Fax   +49 (0)69 98 55 99 - 11
>>>
>>> Firmensitz: Eschersheimer Landstr. 5-7 60322 Frankfurt am Main
>>> Registergericht: Amtsgericht Frankfurt am Main, HRB 76374
>>> Geschäftsführer: Martin Wepper, Sebastian Schirmer
>>>
>>> http://www.zyres.com/
>>>
>>> -- RFC|1855|2.1.1
>>>
>>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Password hash patch

Sebastian Schirmer
I should be used instead of the previous changes.

kind regards
Sebastian

--On Montag, 16. Juni 2008 12:02 -0600 David E Jones
<[hidden email]> wrote:

>
> Are you saying that this patch should be used instead of the previous
> changes, or does it work along with them? I'm planning to look into this
> soon, but I thought I'd ask first.
>
> -David
>
>
> On Jun 16, 2008, at 11:01 AM, Sebastian Schirmer wrote:
>
>> Yes, I have seen the changes in current codebase. The fixes in the
>> current trunk are working with a fresh project but not against an
>> older production database eg. credit card fields is not decrypded
>> any more. Our patch solve this.
>>
>> kind Regards
>> Sebastian
>>
>>
>>
>> --On Montag, 16. Juni 2008 10:18 -0600 David E Jones
>> <[hidden email]
>> > wrote:
>>
>>>
>>> Sebastian,
>>>
>>> Please take a look at the current code base. I believe the same
>>> problem
>>> you are looking at was fixed a few weeks ago. The current code
>>> supports
>>> the bad hex encoding as well as proper hex encoding (both use the
>>> same
>>> hashing, which was fine), and it supports a prefix to specify the
>>> encryption type (MD5, SHA, etc).
>>>
>>> -David
>>>
>>>
>>> On Jun 16, 2008, at 6:05 AM, Sebastian Schirmer wrote:
>>>
>>>> Hi David,
>>>>
>>>> as recently reported we found out that the password hash
>>>> implementation in ofbiz was odd. We have implemented a workaround to
>>>> qualify existing accounts with an old funny hashed password to a
>>>> real sha /md5 hash after log on.
>>>>
>>>> The function is configurable with
>>>> password.autoconvert.hash.type=true
>>>> in framework/security/config/security.properties
>>>>
>>>>
>>>> Other cryped data like credit card also affected form the password
>>>> hash algo. We are using the old funny hash for this fields because
>>>> of production compatibility.
>>>>
>>>> We are currently working with an ofbiz revision 651887. The attached
>>>> patch works against this revision.
>>>>
>>>> Feel free to use or merge our changes against the current trunk. I
>>>> have no write access to the repository.
>>>>
>>>> kind regrads
>>>> Sebastian
>>>>