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