I'm looking for a way or best practise to store Userdata securely in a Database without encrypting the Database.

We’re talking about an Application Server connected to a Database-server. My approach was to encrypt the userdata at the Application Server(How?) and store the encrypted Data in the Database Server. If a User authenticates himself at the Application Server the encrypted Data has to be read from the App-Server, decrypted and served to the User...

Update: It's mandatory that the App-server can decrypt the userdata (for example name, surname, blood type, products they bought, other personal data, Not talking about passwords here) because the App-Server has to decrypt the stored data in the database to present the data to the customer.

Are there any tools/best practises for this scenario?

I guess a fully encrypted Database might be the better solution but are there any ways to secure this environment without fully encrypting the database?


I'll try to clarify the Usecase:

The Customer is running a Website where Users log in with their credentials (Username/Password). Appserver is tomcat, database is oracle afaik. There are no legal requirements (no PCI, Sox, HIPAA, etc.) involved for the stored data, however the customer wants to protect the data by encrypting it. The customer doesn’t want to encrypt the database because of license issues, performance issues, and the "issue" that the database admins might be able to decrypt the database... therefore the data has to be encrypted at the application server and then sent to the database server.

The software architects want to go with the Security by obscurity approach and develop their own "encrypting" technique (maybe rot14 or whatever :) ) and implement it at the application server layer. The customer is fully aware of the fact that all the Software architects might now be able to read the encrypted data stored in the Database but thats fine to him...

  • Hello, welcome to crypto :) For best practises, especially where user databases are concerned, security.se is the right place - don't worry, will move the question shortly :)
    – user2213
    Jun 18, 2012 at 14:48
  • Sounds like you might be storing PHI? I think the question is a little vague to answer properly. What kind of application server? What kind of database? Tools and best practices would depend on that, and there is a possibility that this question might be better suited for a different SE site. Also are there legal requirements for the security of your data, i.e. HIPAA or something like that?
    – Todd Dill
    Jun 18, 2012 at 16:31
  • 1
    Sounds to me like you aren't really wanting a traditional database in the sense that the benefits of having a relational database would be lost because the data wouldn't be sensible. There are a lot of questions to be answered. What sort of performance guarantees are you needing to have with your application. I think I need a lot more information before I could go one way or the other. There are quite a few ways to do what you are asking.
    – M15K
    Jun 18, 2012 at 18:43
  • THanks for the input guys! I did update the starting Question, maybe/hopefully this clarifys some things!
    – kekeria
    Jun 18, 2012 at 19:19
  • You need to mention if this is actual patent health information. If it contains a customer's blood type that would be health information. It actually sounds like encryption is not what you want ( at least not on its own ). Why can't you hash this data then encrypt before its being written to the datbase.
    – Ramhound
    Jun 19, 2012 at 16:18

2 Answers 2


The use case is still a little merky, but here are some thoughts I have reading through the above so far.

  1. Is it a requirement that the application does the decoding, or is the requirement that encryption not be performed in the database? You can have a intermediary server encrypt/decrypt or use a hardware security module, etc.
  2. Assuming that its not a requirement that the web application owner needs read access, you may be able to do a private-key encryption of the sensitive data (obviously not on child-parent table references and such). It's a pain, but its possible to assign end-users certificates for login and authentication and I believe you may be able to leverage that for encryption.
  3. If you just want data encrypted in storage and have reasonable trust of your developers (you shouldn't) you can have the application use its own private key for encryption in the application of the sensitive data and encrypt it before storing it in the database. You would also need to figure out how to protect the private key. You may be able to use a hardware module here as well.

Also, even if the organization doesn't think they have HIPAA requirements, it sure does sound like that. They might be a "business associate", which could still have some HIPAA implications. I would also wonder about the business model where they have a boat-load of data but don't want the ability to aggregate or data-mine; you can use all sorts of pseudonym referneces to tie things together at the individual level for a per-person processing (e.g., query all my blood test rows and do the aggregation when I load the page). Has the organization considered the impact of doing encryption at the application level, or perhaps this is only for a few key pieces of data?


You could use Oracle's Transparent Data Encryption (TDE) to secure the necessary columns.


This would allow you to encrypt the column and still be able to search it somewhat efficiently. Depending on your license arrangement with Oracle, there may be a license upgrade required for this feature.

Alternatively, you could use the java.security and javax.crypto packages in your application to encrypt your data before you send it to the database. A drawback to this would be possibly decreased performance should the encrypted data needed to be queried.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .