Thanks for your proposal ...in ldap no prefix means clear text pw -maybe we should stick to this. we are working on it already (concept/planning) and will hopefully introduce it in (few?) days.
Martin > -----Ursprüngliche Nachricht----- > Von: Jonathon -- Improov [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 29. April 2008 14:23 > An: user@ofbiz.apache.org > Betreff: Re: AW: WG: SHA / SHA1 seed data and password encryption > > That would immediately solve Martin's problem, and allow him to port in > passwords from other > softwares (that use standard hashing, period). Also, it wouldn't > disrupt existing OFBiz passwords. > > I'm guessing (not sure) it might be dangerous to hash it multiple ways > until we get a match, > though. Best to hash it a single way only, which way it is will depend > on the prefix. That is, the > hash itself declares the hashing algo it needs, and only that algo will > be hashed for that hash. > > No prefix (no declaration of hashing algo) will mean the default OFBiz > style. > > What do you think? > > Jonathon > > David E Jones wrote: > > > > I played with this a little bit while working on some other stuff... > > > > The best solution seems to use something "standard" like the Apache > > Commons Codex Hex class, which is an easier/better way to do the hex > > encoding there. > > > > The problem is if we change wholesale anyone who updates OFBiz will > > suddenly have a bunch of useless password data... so I've modified > the > > HashCrypt class to support doing it both ways, and changes the > userLogin > > service to try hashing it both ways to see if either matches. > > > > It seems to be working fine so if there are no complaints it'll be in > > soon... well as soon as the SVN server is up for commits again! > > > > -David > > > > > > On Apr 28, 2008, at 11:18 PM, David E Jones wrote: > >> > >> Martin, > >> > >> I agree that is odd, and not a good thing, and I'm really not sure > why > >> it is there or how it got there in the first place. > >> > >> It sounds like the proposal is to remove HashCrypt.java lines 52-53, > >> 82-84. > >> > >> Does that sound correct, and does it give more consistent results to > >> what you are seeing elsewhere? > >> > >> If so, let's get rid of 'em! > >> > >> -David > >> > >> > >> On Apr 28, 2008, at 10:51 PM, Martin Wepper wrote: > >>> Jonathon, > >>> > >>> Thanks for your comments. > >>> it I understand it right we can not introduce other hashes to ofbiz > >>> without > >>> introducing the algorithm used to encrypt these. > >>> Hashes are one way - so mangling them after being once created is > >>> -hopefully > >>> for sec reasons- impossible. Here we need the clear text pass > again. > >>> > >>> So other systems we introduce these ofbiz haches to may not use > these > >>> without the ofbiz encryption - thats bad - as it should comply to > the > >>> standard or clearly state thats its different/wrong as it seems > not > >>> to be > >>> sha1. > >>> > >>> Kind Regards > >>> Martin > >>> > >>> > >>> > >>>> -----Ursprüngliche Nachricht----- > >>>> Von: Jonathon -- Improov [mailto:[EMAIL PROTECTED] > >>>> Gesendet: Dienstag, 29. April 2008 04:12 > >>>> An: user@ofbiz.apache.org > >>>> Betreff: Re: WG: SHA / SHA1 seed data and password encryption > >>>> > >>>> Martin, > >>>> > >>>>> A brief analysis shows that the implementation might start here > >>>> being > >>>>> problematic: > >>>>> > >>>>> getDigestHash in > >>>> trunk/base/src/base/org/ofbiz/base/crypto/HashCrypt.java > >>>> > >>>> Yup. That's where the OFBiz-specific implementation (or rehashing) > is. > >>>> > >>>>> Conclusion: the hashes in customer dbs are not really compatible > >>>> with other > >>>>> sha1 implementations today, bad for SSO. > >>>>> Is there any impact on vulnerability of stored hashes created by > >>>> ofbiz? > >>>> > >>>> Impact on vulnerability? No. In fact, it's slightly more secure. > >>>> > >>>> However, the increase in security is only slight. Check out the > phrase > >>>> "security by obscurity". I > >>>> think I mentioned this some months back on the ML or JIRA. I can't > >>>> guess what other reason OFBiz > >>>> would have for making the hash different from the rest of the > world. > >>>> Seeding the password would be > >>>> a more appropriate strategy for increased security (see > >>>> https://issues.apache.org/jira/browse/OFBIZ-1151 ). > >>>> > >>>> The incompatibility may not pose a problem (I hope). You can still > >>>> migrate passwords from other > >>>> systems (not OFBiz, eg osCommerce) into OFBiz. The reason is that > OFBiz > >>>> does not mangle the > >>>> original SHA hash beyond recovery (I hope, but don't think so). > You > >>>> just have to take the SHA > >>>> hashes from other systems, pass it through OFBiz's mangling, and > you > >>>> have successfully ported > >>>> those passwords into OFBiz. Someone please correct me if I'm wrong > >>>> here; codes in > >>>> HashCrypt.getDigestHash() (package org.ofbiz.base.crypto). > >>>> > >>>> If OFBiz does mangle the original SHA hash beyond recovery, then > you > >>>> cannot migrate passwords to > >>>> and from OFBiz systems. Then this would be wrong, and needs to be > >>>> fixed. This does seem to be the > >>>> case in StringUtil.encodeInt(). > >>>> > >>>> We also talked about a "pluggable security system" to easily > replace > >>>> that OFBiz-specific chunk. > >>>> Not sure if this is done yet. > >>>> > >>>> Jonathon > >>>> > >>>> Martin Wepper wrote: > >>>>> Dear , > >>>>> > >>>>> hopefully I do miss a point, but ... > >>>>> today we are experiencing a quite annoying issue with sha > hashes: > >>>>> > >>>>> Please have a look at this: > >>>>> > >>>>> I'm simply listing hashes, let's start with the hash in > seed/demo > >>>> for > >>>>> "ofbiz": > >>>>> > >>>>> 47b56994cbc2b6d10aa1be30f70165adb305a41a = ofbiz hashed by > >>>> debian4/sha1sum > >>>>> 47b56994cbc2b6d10aa1be30f70165adb305a41a = ofbiz hashed by php > >>>>> 47b56994cbc2b6d10aa1be30f70165adb305a41a = ofbiz by java - > Jacksum > >>>> 1.7.0, > >>>>> algorithm=sha1 > >>>>> but: > >>>>> 47ca69ebb4bdc9ae0adec130880165d2cc05db1a = ofbiz password for > admin > >>>> in > >>>>> demo-seed-data > >>>>> __xx__xxxxxxxxxx xxxx xx____xxxx__xx__ here the ofbiz hash > >>>> differs to > >>>>> other sha1 implementations > >>>>> > >>>>> Other examples: > >>>>> xxxx________xxxxxx____xxxx__xx__________ > >>>>> 8cb2237d0679ca88db6464eac60da96345513964 = 12345 by "others" > >>>>> f3cd237d0679b5f7a4646495b90dd66345513964 = 12345 by ofbiz > >>>>> > >>>>> ______xxxx__xxxxxxx_______xxxx__xx______ > >>>>> 7c222fb2927d828af22f592134e8932480637c0d = 12345678 by others > >>>>> 7c222fcded7dfdf58d2f59213497ec24ff637c0d = 12345678 by ofbiz > >>>>> > >>>>> __xxxx____xxxx______xxxx__xx__xx____xx__ > >>>>> 2fb5e13419fc89246865e7a324f476ec624e8740 = abcdefg by others > >>>>> 2fca9e341983f624686598dc248b7693624ef840 = abcdefg by ofbiz > >>>>> > >>>>> > >>>>> A brief analysis shows that the implementation might start here > being > >>>>> problematic: > >>>>> > >>>>> getDigestHash in > >>>> trunk/base/src/base/org/ofbiz/base/crypto/HashCrypt.java > >>>>> > >>>>> ... > >>>>> int i1 = digestBytes[l]; > >>>>> if (i1 < 0) > >>>>> i1 = 127 + i1 * -1; > >>>>> StringUtil.encodeInt(i1, k, digestChars); > >>>>> ... > >>>>> > >>>>> The bit operations introduced in StringUtil.encodeInt do not > comply > >>>> to the > >>>>> way the int is calculated before. > >>>>> > >>>>> Example: > >>>>> Digest of -116 should result in 0x8c but in our ofbiz code it is > >>>> resulting > >>>>> in 0xf3 > >>>>> But: > >>>>> -116 = 0b10001100 = 0x8c - ok for sha1 > >>>>> 127 + -116*-1 = 243 = 0b11110011 = 0xf3 for obfiz-sha > >>>>> > >>>>> The digest is calculated properly, but when converting to hex > string > >>>> the > >>>>> function seems to fail on negative byte/int values, only. > >>>>> > >>>>> This has been introduced in 2004-09-09 21:06:36 UTC (rev 3317) > >>>>> > >>>>> Conclusion: the hashes in customer dbs are not really compatible > with > >>>> other > >>>>> sha1 implementations today, bad for SSO. > >>>>> Is there any impact on vulnerability of stored hashes created by > >>>> ofbiz? > >>>>> > >>>>> Martin > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Martin Wepper > >>>>> 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: Sebastian Schirmer, Martin Wepper > >>>>> http://www.zyres.com/ > >>>>> -- > >>>>> > >>>>> > >>>>> > >>>>> > >>> > >>> > >> > > > > > >
