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

Tue, 29 Apr 2008 08:10:22 -0700 


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

Attachment: pwcryptAndAudit.patch.gz
Description: GNU Zip compressed data





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:[EMAIL PROTECTED]
Gesendet: Dienstag, 29. April 2008 14:23
An: [email protected]
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:[EMAIL PROTECTED]
Gesendet: Dienstag, 29. April 2008 04:12
An: [email protected]
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/
--

Reply via email to