This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Everywhere I keep reading "you should [almost] never have to use BMP with EJB 2+ [if you have a realational database]" or some version of that advice.
But I keep wondering, what if some application data is almost guaranteed to be encrypted in the persistent store, using either one- or two-way encryption? For example, MySQL's PASSWORD() function is a fairly common one-way encryption mechanism for passwords, and many other 2-way encryption algorithms can be used to cipher credit card numbers or other legally-sensitive information.
If I want an entity bean to represent objects with sensitive, more-than-likely-encrypted-in-the-persistent-store data fields, what's the best way to approach this? Use a BMP bean that harnesses the ease of using decryption methods in the actual SQL code? Or use a CMP bean wrapped with a session facade (like a DecryptorFactory of some sort) that can make sense out of the encrypted data?
What's the best way to do this and keep the ejb-jar portable across different database implementations? Is there any way to achieve one-way encryption with java? This has been bugging me for a long time. If anyone has any best practices or good ideas, please share, thanks!
You could encapsulate all required logic in your CMP EB. Eg,
As you can see in the example we decrypt the password extracted from db. Same could be done with storing the password into db (would be encrypting first and then saving into db)
Oh, yeh. In regards to one way encryption in java. Check out the following:
Hope it helps,
[ August 13, 2004: Message edited by: Alex Sharkoff ]
[ August 13, 2004: Message edited by: Alex Sharkoff ] [ August 13, 2004: Message edited by: Alex Sharkoff ]
Alex (SCJP 1.4, SCBCD 1.3, SCWCD 1.4, SCJD 1.4)
Joined: Jun 05, 2004
I found some other docs on doing the SHA and MD5 encryption using MessageDigest, and your above example works great if that's how the data is encrypted. I still think an environment entry might be necessary though, to be able to configure the encryption method at deployment time (one which would work with some kind of MessageDigestCryptionFactory) depending on the database.
However, what I'm looking for here is more of an answer to the portability issue. What if the persistent store uses an encryption algorithm other than SHA or MD5? Do I need to become a cipher expert if I want my CMP bean to work with several different database vendors, and work with existing data (that for example I, as the Bean Provider, cannot suggest encryption policies for)?