The series of changes required to get this seemingly simple feature to
work were rather complex. I'm not certain if this should be targetted
to the previous branches; this feature has *not* worked since at least
2005, so it's not like there was a breakage of a working feature.
On 06/23/2014 07:30 PM, Adam Heath (JIRA) wrote:
[
https://issues.apache.org/jira/browse/OFBIZ-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Heath updated OFBIZ-5659:
------------------------------
Fix Version/s: SVN trunk
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
Fix For: SVN trunk
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)
