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

[Nicolas Malin (Jira)]

     [ 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)

[Adam Heath-2]

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)

[Adrian Crum-3]

In the past, the dev community has supported backporting changes like
this to the most recent release branch. It could be backported further,
but the farther you go back, the less compatible the code is - so merges
are more difficult.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 6/23/2014 5:32 PM, Adam Heath wrote:

> 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)
>

[Adam Heath-2]

In this case, it might be somewhat simple to backport; this area hasn't
been seeing changes that much.

On 06/23/2014 10:29 PM, Adrian Crum wrote:

> In the past, the dev community has supported backporting changes like
> this to the most recent release branch. It could be backported
> further, but the farther you go back, the less compatible the code is
> - so merges are more difficult.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 6/23/2014 5:32 PM, Adam Heath wrote:
>> 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.

[Jacques Le Roux]

I think R13.07 only is enough, if possible...

Jacques

Le 24/06/2014 05:29, Adrian Crum a écrit :

> In the past, the dev community has supported backporting changes like this to the most recent release branch. It could be backported further, but
> the farther you go back, the less compatible the code is - so merges are more difficult.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 6/23/2014 5:32 PM, Adam Heath wrote:
>> 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)
>>
>

--

[Jacques Le Roux]

Then if it's possible to R13.07 why not R12.04 indeed. R11.04 will no longer be supported "soon"...

Jacques

Le 24/06/2014 07:31, Adam Heath a écrit :

> In this case, it might be somewhat simple to backport; this area hasn't been seeing changes that much.
>
> On 06/23/2014 10:29 PM, Adrian Crum wrote:
>> In the past, the dev community has supported backporting changes like this to the most recent release branch. It could be backported further, but
>> the farther you go back, the less compatible the code is - so merges are more difficult.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 6/23/2014 5:32 PM, Adam Heath wrote:
>>> 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.
>
>

--

[Jacopo Cappellato-4]

We could backport all these changes to the 13.07 branch and postpone the release date of a few weeks to have some more time to test. I would probably not backport to 12.04, but we can consider this as well.

Jacopo

On Jun 24, 2014, at 9:15 AM, Jacques Le Roux <[hidden email]> wrote:

> Then if it's possible to R13.07 why not R12.04 indeed. R11.04 will no longer be supported "soon"...
>
> Jacques
>
> Le 24/06/2014 07:31, Adam Heath a écrit :
>> In this case, it might be somewhat simple to backport; this area hasn't been seeing changes that much.
>>
>> On 06/23/2014 10:29 PM, Adrian Crum wrote:
>>> In the past, the dev community has supported backporting changes like this to the most recent release branch. It could be backported further, but the farther you go back, the less compatible the code is - so merges are more difficult.
>>>
>>> Adrian Crum
>>> Sandglass Software
>>> www.sandglass-software.com
>>>
>>> On 6/23/2014 5:32 PM, Adam Heath wrote:
>>>> 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.
>>
>>
>
> --