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/ > > -- > > > > > > > >
