[
https://issues.apache.org/jira/browse/OFBIZ-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14036842#comment-14036842
]
Vyom Jain commented on OFBIZ-5659:
----------------------------------
By "so this particular feature has been broken for a very long time. In fact,
at the time when this method was added, the code would have never had a chance
of running at all." do you mean FinAccountHelper.getFinAccountFromCode() never
worked earlier?
The method did work in earlier versions such as 09.04 & 10.04. It can be
checked by either following steps for manual testing or using the unit test
case in either of those versions.
In order to get this feature/ method to work once again in trunk, I had to use
a hack/ workaround which was to change all references of handlers[0] to
handlers[2] in framework/entity/src/org/ofbiz/entity/util/EntityCrypto.java.
While data was still encrypted and stored, this approach of course does not
have the advantage of kek implementation.
> 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)
