WG: SHA / SHA1 seed data and password encryption

[mwepper_zyres]

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 [phone] - 0
Fax [phone] - 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/
--

[jonwimp]

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 [phone] - 0
> Fax [phone] - 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/
> --
>
>
>
>

[mwepper_zyres]

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:[hidden email]]
> Gesendet: Dienstag, 29. April 2008 04:12
> An: [hidden email]
> 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 [phone] - 0
> > Fax [phone] - 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/
> > --
> >
> >
> >
> >

[David E Jones]

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:[hidden email]]
>> Gesendet: Dienstag, 29. April 2008 04:12
>> An: [hidden email]
>> 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 [phone] - 0
>>> Fax [phone] - 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/
>>> --
>>>
>>>
>>>
>>>
>
>

[jonwimp]

Martin,

Sorry, the chunk (below) I wrote in previous post is wrong.

There is no way to port passwords between systems unless they all use the standard hashes and
nothing else. Not even seeding.

Seeding is a form of mangling of the password hashes. osCommerce employs seeding, so the passwords
there cannot be ported over to OFBiz. Even if OFBiz correctly employs seeding, its passwords will
also not be portable to other systems.

The only way to port passwords between systems is to copy the mangling algo lock, stock, barrel.

And now, in response to your post.

 > it I understand it right we can not introduce other hashes to ofbiz without
 > introducing the algorithm used to encrypt these.

Absolutely right!

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

Hashes are one-way, so they qualify to serve in password security systems.

Mangling hashes in a fixed way (like OFBiz does) does not prevent dictionary attacks (a brute
force attack that is rather cheap to execute).

Mangling hashes in a random way (seeding/salting) makes dictionary attacks many times harder or
more expensive.

We can mangle hashes reversibly, but that would be pointless. What I had suggested (mangling
hashes and still recovering original hash) is wrong.

 > So other systems we introduce these ofbiz haches to may not use these
 > without the ofbiz encryption

Correct.

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

It's not bad, actually. That was my mistake for implying it is.

There is really no standard way to salt/seed a hash. Some may append the salt to the end; some to
front, some in middle. However, if there really is a standard way to do so, then yeah, portability
of passwords is possible. In that case, then yes, it's bad of OFBiz not to follow such a standard
(if it exists).

As such, the only way to port passwords is to port the mangling algo. OFBiz's only missing (or
not?) part in this is a "pluggable security architecture". It's not difficult to brute-force
replace OFBiz's security, anyway. I haven't found the need to create a generic "pluggable
architecture" for various security algos.

Jonathon

 >> 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().

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:[hidden email]]
>> Gesendet: Dienstag, 29. April 2008 04:12
>> An: [hidden email]
>> 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 [phone] - 0
>>> Fax [phone] - 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/
>>> --
>>>
>>>
>>>
>>>
>
>
>
>

[David E Jones]

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 - 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:[hidden email]]
>>> Gesendet: Dienstag, 29. April 2008 04:12
>>> An: [hidden email]
>>> 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 [phone] - 0
>>>> Fax [phone] - 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/
>>>> --
>>>>
>>>>
>>>>
>>>>
>>
>>
>

[Sebastian Schirmer]

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
<[hidden email]> 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:[hidden email]]
>>> Gesendet: Dienstag, 29. April 2008 04:12
>>> An: [hidden email]
>>> 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
>>>>
>>>>

[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 <[hidden email]
> > 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:[hidden email]]
>>>> Gesendet: Dienstag, 29. April 2008 04:12
>>>> An: [hidden email]
>>>> 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
>>>>>
>>>>>
>

[jonwimp]

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 - 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:[hidden email]]
>>>> Gesendet: Dienstag, 29. April 2008 04:12
>>>> An: [hidden email]
>>>> 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 [phone] - 0
>>>>> Fax [phone] - 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/
>>>>> --
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>
>
>

[mwepper_zyres]

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:[hidden email]]
> Gesendet: Dienstag, 29. April 2008 14:23
> An: [hidden email]
> 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 - 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:[hidden email]]
> >>>> Gesendet: Dienstag, 29. April 2008 04:12
> >>>> An: [hidden email]
> >>>> 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 [phone] - 0
> >>>>> Fax [phone] - 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/
> >>>>> --
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>
> >
> >
> >

[David E Jones]

Attached is the patch for the stuff I was working on last night.

Unfortunately it doesn't just have the password improvements, but  
instead also has the generic audit log feature that I recently added  
to the entity engine.

As has been mentioned a few times the ASF SVN repo is not open for  
commits, so those who want this or to get started with it can play  
with the attached patch (in a gzip file, BTW) until the SVN server is  
ready for commits again.

BTW, if the attachment doesn't make it through I'll try again in a  
minute.

-David






On Apr 29, 2008, at 6:38 AM, Martin Wepper wrote:

> 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:[hidden email]]
>> Gesendet: Dienstag, 29. April 2008 14:23
>> An: [hidden email]
>> 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 - 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:[hidden email]]
>>>>>> Gesendet: Dienstag, 29. April 2008 04:12
>>>>>> An: [hidden email]
>>>>>> 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 [phone] - 0
>>>>>>> Fax [phone] - 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/
>>>>>>> --
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>
>

[Sebastian Schirmer]

Hi David,

thanks for the new hash implementation. We are going to implement an auto
conversion method additionally.
This should write the new correct sha/md5 hash after login validation with
the old (funny) hash.

Is the keystore entity also affected to the new hash methods?

Kind regards
Sebastian


--On Dienstag, 29. April 2008 09:09 -0600 David E Jones
<[hidden email]> wrote:

>
> Attached is the patch for the stuff I was working on last night.
>
> Unfortunately it doesn't just have the password improvements, but instead
> also has the generic audit log feature that I recently added to the
> entity engine.
>
> As has been mentioned a few times the ASF SVN repo is not open for
> commits, so those who want this or to get started with it can play with
> the attached patch (in a gzip file, BTW) until the SVN server is ready
> for commits again.
>
> BTW, if the attachment doesn't make it through I'll try again in a minute.
>
> -David
>

--
 Sebastian Schirmer

 ZYRES digital media systems GmbH
 Eschersheimer Landstr. 5-7 60322 Frankfurt am Main
 Phone [phone] - 0
 Fax   [phone] - 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

[David E Jones]

On Apr 30, 2008, at 2:25 AM, Sebastian Schirmer wrote:
> Hi David,
>
> thanks for the new hash implementation. We are going to implement an  
> auto conversion method additionally.
> This should write the new correct sha/md5 hash after login  
> validation with the old (funny) hash.
>
> Is the keystore entity also affected to the new hash methods?

No, the keystore is only used for 2-way encryption.

BTW, on a side note, there is still no "salting" in this password  
encryption, not sure if that is something you guys have looked at or  
need but it is something that crossed my mind while looking at this  
again.

-David

> --On Dienstag, 29. April 2008 09:09 -0600 David E Jones <[hidden email]
> > wrote:
>
>>
>> Attached is the patch for the stuff I was working on last night.
>>
>> Unfortunately it doesn't just have the password improvements, but  
>> instead
>> also has the generic audit log feature that I recently added to the
>> entity engine.
>>
>> As has been mentioned a few times the ASF SVN repo is not open for
>> commits, so those who want this or to get started with it can play  
>> with
>> the attached patch (in a gzip file, BTW) until the SVN server is  
>> ready
>> for commits again.
>>
>> BTW, if the attachment doesn't make it through I'll try again in a  
>> minute.
>>
>> -David
>>
>
>
>
> --
> Sebastian Schirmer
>
> ZYRES digital media systems GmbH
> Eschersheimer Landstr. 5-7 60322 Frankfurt am Main
> Phone [phone] - 0
> Fax   [phone] - 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
>
>

[Jacques Le Roux]

BTW there are already Jira issues open about all that https://issues.apache.org/jira/browse/OFBIZ-1525
Precisely about this issue https://issues.apache.org/jira/browse/OFBIZ-1151

This discussion should be better in dev ML...

Thanks

Jacques

From: "David E Jones" <[hidden email]>

>
> On Apr 30, 2008, at 2:25 AM, Sebastian Schirmer wrote:
>> Hi David,
>>
>> thanks for the new hash implementation. We are going to implement an  auto conversion method additionally.
>> This should write the new correct sha/md5 hash after login  validation with the old (funny) hash.
>>
>> Is the keystore entity also affected to the new hash methods?
>
> No, the keystore is only used for 2-way encryption.
>
> BTW, on a side note, there is still no "salting" in this password  encryption, not sure if that is something you guys have looked
> at or  need but it is something that crossed my mind while looking at this  again.
>
> -David
>
>
>> --On Dienstag, 29. April 2008 09:09 -0600 David E Jones <[hidden email]
>> > wrote:
>>
>>>
>>> Attached is the patch for the stuff I was working on last night.
>>>
>>> Unfortunately it doesn't just have the password improvements, but  instead
>>> also has the generic audit log feature that I recently added to the
>>> entity engine.
>>>
>>> As has been mentioned a few times the ASF SVN repo is not open for
>>> commits, so those who want this or to get started with it can play  with
>>> the attached patch (in a gzip file, BTW) until the SVN server is  ready
>>> for commits again.
>>>
>>> BTW, if the attachment doesn't make it through I'll try again in a  minute.
>>>
>>> -David
>>>
>>
>>
>>
>> --
>> Sebastian Schirmer
>>
>> ZYRES digital media systems GmbH
>> Eschersheimer Landstr. 5-7 60322 Frankfurt am Main
>> Phone [phone] - 0
>> Fax   [phone] - 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
>>
>>
>
>

[Sebastian Schirmer]

Hi David,

--On Mittwoch, 30. April 2008 02:29 -0600 David E Jones
<[hidden email]> wrote:
>
> No, the keystore is only used for 2-way encryption.

It seems that old EntityKeyStore data are affected from the new hash
method. The keyName in the EntityKeyStore was hashed formerly by old hash
method?


regards
Sebastian