[jira] [Closed] (OFBIZ-5659) Person.socialSecurityNumber can't be used for findByAnd

["Jacques Le Roux (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OFBIZ-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jacques Le Roux closed OFBIZ-5659.
----------------------------------
    Resolution: Abandoned

> 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: Release Branch 12.04, Release Branch 13.07, Trunk, Upcoming Branch
>            Reporter: Adam Heath
>            Assignee: Adam Heath
>            Priority: Major
>
> 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
(v8.20.1#820001)