[ https://issues.apache.org/jira/browse/OFBIZ-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14036045#comment-14036045 ]
Vyom Jain commented on OFBIZ-5659: ---------------------------------- Similar issue https://issues.apache.org/jira/browse/OFBIZ-5565 should get fixed by your change for this one. > 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)