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 |
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 |
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 > |
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 >> > |
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 >>> >> > > > > |
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 >>>> |
Free forum by Nabble | Edit this page |