[
https://issues.apache.org/jira/browse/OFBIZ-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14041518#comment-14041518
]
Adam Heath commented on OFBIZ-5659:
-----------------------------------
This should all be fixed now, in svn revisions: 1604967, 1604968, 1604971, and
1604972,
During the investigation, it was discovered that support for encrypted fields
in the EntityCondition classes was completely non-fuinctional. Much work had
to be done to get it into a functional state. However, now there are test
cases, so this kind of breakage should not happen going forward.
The other issues have not yet been resolved against this series of changes.
> 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)
