On 04/19/2012 04:28 PM, Jacques Le Roux wrote:
> Looking forward for
> https://issues.apache.org/jira/browse/OFBIZ-1151
> https://issues.apache.org/jira/browse/OFBIZ-2729
> https://issues.apache.org/jira/browse/OFBIZ-3006
2729 doesn't apply for what I am doing. Here's the list of things
that this solves:
1: salt-based UserLogin.currentPassword
(done, I have a fix for the recent issue locally)
2: salt-based CreditCard.cardNumber encrypted value
(s/b done tonight)
3: salt-based EntityKeyStore.keyText
(s/b done tonight)
4: key-encrypting-key for EntityKeyStore.keyText. The
key-encrypting-key will be available somewhere in ${ofbiz.home.dir}.
(need to read java security doco)
I've currently rewritten a bunch of EntityCrypto already to fix the
issues I posted into the jira issue. I'm now at the point I can start
adding new features.
This set of changes I currently have are rather straight forward, just
moving code around. When I finally get around to adding the new
features, then there is a very definate chance of breaking stuff.
>
> Jacques
>
> From: "Adam Heath" <doo...@brainfood.com>
>> As some may have noticed, I recently changed the way ofbiz creates
>> password hashes when it stores them in the database. Each time a new
>> password is created, a bit of randomness is used, to create a
>> random-length, random-content salt. This is placed at the beginning
>> of the hashed password, stored along with it in the database.
>>
>> Then, when it comes time to compare passwords, the salt is extracted,
>> and used to re-hash.
>>
>> If someone continously changes their password to the same value,
>> you'll end up getting different raw hashed values in the database. It
>> also increases the workload for crackers, and makes rainbow tables
>> much less fruitful.
>>
>> I wrote this change over 2 years ago, in direct response to the jira
>> intrusion that happened.
