[
https://issues.apache.org/jira/browse/OFBIZ-1406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543028
]
Jonathon Wong commented on OFBIZ-1406:
--------------------------------------
Scott Gray said:
> Who said I was talking about you? :-P
Oops. Too late, I volunteered my time, you manipulator!
Anyway, it's confirmed. The Java MD5 implementation is correct. There is some
deliberate translation when converting the byte array to hex string. Something
like a "mangling algo" that mangles the original MD5 (SHA, in OFBiz's case?)
when converting from byte array to hex string.
Scott Gray said:
> 1. OSCommerce is but one system people might migrate from, do we want code
> for each of them applied in this manner?
I think it was Hans who advised someone on ML to use a plug-in architecture
approach to replace the existing "password generating and handling" algo in
OFBiz?
That's the best way.
The original plug-in will use HashCrypt. The osCommerce plug-in will not.
Scott Gray said:
> 2. If we change the current byte array to hex method, won't that break
> existing passwords?
Definitely. Have 2 plug-ins (or algos), 1 for OFBiz passwords and the other for
osCommerce passwords.
Scott Gray said:
> Can we make it backwards compatible somehow?
No need to. Just don't remove the original OFBiz "password generating and
handling" algo.
Scott Gray said:
> Since the byte to hex conversion is reversible perhaps we could provide a
> service to correct the stored password hashes?
I think the original purpose was to convert all osCommerce password hashes into
OFBiz password hashes. That's simple enough, if OFBiz receives the plain
password. It does.
Once OFBiz receives the plain password, it'll:
1. Look at the stored password hash
2. Check the password (use the correct algo, depending on whether hash is
osCommerce-format or not).
3. Convert password hash into OFBiz format if it isn't in that format already.
How to convert password into OFBiz format? Just use HashCrypt!
Scott Gray said:
> Perhaps an incorrect hex value is a security feature in itself?
It's not an effective security. It's what we usually call "security by
obscurity", because we will be hoping no one gets the "mangling algo" that
mangles the original MD5 (SHA, actually) digest when converting from byte array
to hex string.
Note that a dictionary attack is still perfectly feasible. All the attacker has
to do is to get a computer to generate the dictionary using the *exact*
mangling algo. A random salt for every single password hash is an effective way
to defeat dictionary attacks, this "security by obscurity" approach is not.
> make ofbiz recognize OSCommerce generated and imported encrypted passwords
> under Linux
> --------------------------------------------------------------------------------------
>
> Key: OFBIZ-1406
> URL: https://issues.apache.org/jira/browse/OFBIZ-1406
> Project: OFBiz
> Issue Type: New Feature
> Components: party
> Affects Versions: SVN trunk
> Reporter: Hans Bakker
> Priority: Minor
> Fix For: SVN trunk
>
> Attachments: password.diff
>
>
> If company replaces their OSCommerce systems with ofbiz, they would like to
> have the customer records imported including the OSCommerce generated
> encrypted passwords.
> This patch will make ofbiz recognize these passwords and let OSCommerce users
> login to ofbiz successfully This patch is however linux based because it is
> making use of the Linux operating system command 'md5sum' which operates
> exactly the same as the php md5 'C' program.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
