Re: AW: WG: SHA / SHA1 seed data and password encryption

[David E Jones]

The prefix is not a bad idea... I'm adding that to the new default  
scheme while I'm at it, and adding support to try the default  
configured hash, the old funny hex encode hash, and a hash based on  
the hash type in the prefix in the database/datasource.

-David


On Apr 29, 2008, at 1:50 AM, Sebastian Schirmer wrote:
Hi Martin,

we should replace the code with a proved method. The apache commons http://commons.apache.org/codec/apidocs/org/apache/commons/codec/digest/DigestUtils.html 
 is good for a proved method. But our problems are still exists with  
existing productive data. We need the old hash methods still  
coexisting with the new hash methods. During a customer login a  
validation against the old hash must be possible.

the used password digest should be also mentioned in front of the  
hash. For example
{sha}xxxxxxxxxxxxxxxxxxxxxxxxxxx
{sha256}xxxxxxxxxxxxxxxxxxxxxxxx
{md5}xxxxxxxxxxxxxxxxxxxxxxxxxxx
{ofbiz}xxxxxxxxxxxxxxxxxxxxxxxxxx <-- (ofbiz brocken hash)


This stucture is used im many applications, like openldap and others  
und give us a way using more than one hash method at the same time.

Kind regards
Sebastian


--On Montag, 28. April 2008 23:18 -0600 David E Jones <[EMAIL PROTECTED] 
> 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 - that's bad - as it should comply to  
the
standard or clearly state that's 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