[
https://issues.apache.org/jira/browse/OFBIZ-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14037572#comment-14037572 ]
Adam Heath commented on OFBIZ-5659:
-----------------------------------
It's not about which release is supported, but attempting to find when breakage occurred.
I use git to do ofbiz work, and I went and found the *old* repos, from before apache, and have 'grafted' them in, so I have history going all the way back to:
==
commit f72d331f855a71658e6dd2c564152cc0dbe38aa1
Author: (no author) <(no author)@deaff617-5be1-0310-a1b7-ec6878f92ba9>
Date: Fri Aug 8 16:35:42 2003 +0000
New repository initialized by cvs2svn.
git-svn-id:
http://svn.ofbiz.org/svn/ofbiz/trunk@2 deaff617-5be1-0310-a1b7-ec6878f92ba9
==
> Person.socialSecurityNumber can't be used for findByAnd
> -------------------------------------------------------
>
> Key: OFBIZ-5659
> URL:
https://issues.apache.org/jira/browse/OFBIZ-5659> Project: OFBiz
> Issue Type: Bug
> Components: framework
> Affects Versions: SVN trunk, Release Branch 12.04, Release Branch 13.07
> Reporter: Adam Heath
> Assignee: Adam Heath
>
> In EntityCrypto, a random salt of bytes, with a random length between 5 and 16 characters, is added to each to-be-encrypted list of bytes. This entire array is then encrypted, and stored.
> Because the salt prefix is random each time, including when subsequent findByAnd calls are used, the database has no chance to do an equality test, so never finds the record.
> This was done, so that the same exact value stored for different rows would encrypt to a different value; this was thought to be better for security. It's based on how one-way password hashes work.
> My planned fix, is simple enough. Just change the salt length to 0. This will allow newly stored values to be looked up(with = or !=, but not with LIKE). Existing values already stored will be fixed by iterating over all of them, then restoring in place.
> However, what I would really like to see, is this encrypted+salt feature configurable *per field*. That will take a bit more time.
> ps: There is *no* test on lookups for Person.socialSecurityNumber; not even a test for a lookup on an encrypted field. I'll obviously be adding that.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
Locked
