On 4/20/2012 12:23 AM, Adam Heath wrote:
On 04/19/2012 06:13 PM, Scott Gray wrote:
On 20/04/2012, at 9:49 AM, Adam Heath wrote:
On 04/19/2012 04:28 PM, Jacques Le Roux wrote:
Looking forward for
https://issues.apache.org/jira/browse/OFBIZ-1151
https://issues.apache.org/jira/browse/OFBIZ-2729
https://issues.apache.org/jira/browse/OFBIZ-3006
2729 doesn't apply for what I am doing. Here's the list of things
that this solves:
1: salt-based UserLogin.currentPassword
(done, I have a fix for the recent issue locally)
2: salt-based CreditCard.cardNumber encrypted value
(s/b done tonight)
3: salt-based EntityKeyStore.keyText
(s/b done tonight)
4: key-encrypting-key for EntityKeyStore.keyText. The
key-encrypting-key will be available somewhere in ${ofbiz.home.dir}.
(need to read java security doco)
I've currently rewritten a bunch of EntityCrypto already to fix the
issues I posted into the jira issue. I'm now at the point I can start
adding new features.
This set of changes I currently have are rather straight forward, just
moving code around. When I finally get around to adding the new
features, then there is a very definate chance of breaking stuff.
Please just do your best to ensure backwards compatibility is maintained. I
can't imagine anything worse than doing an upgrade and discovering that all my
user passwords are no longer valid.
Sure, I've got things done as an array of handlers now(2 current, plus
1 new).
How do we feel about moving EntityKeyStore into a separate database?
It'd improve the security a little bit, and is rather simple to do
with ofbiz.
+1
I believe credit card companies split security-sensitive data across
databases in a similar way.
-Adrian
