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.