Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?


Update

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...

share|improve this question

migrated from crypto.stackexchange.com Jun 18 '12 at 14:49

This question came from our site for software developers, mathematicians and others interested in cryptography.

    
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 '12 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 '12 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 '12 at 18:43
    
THanks for the input guys! I did update the starting Question, maybe/hopefully this clarifys some things! –  kekeria Jun 18 '12 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 '12 at 16:18

3 Answers 3

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?

share|improve this answer

The database server could be set up in a way that it only accepts secure(encrypted) connections from the application server. Any other packets/connection request should be dropped. Such connections should be properly authenticated to ensure that they are coming from the application server.

Do not use accounts with root privileges to read/write data into the database. Instead, accounts with least needed access to perform the task should be used. It goes without saying that such accounts should have good, strong passwords assigned.

However, sensitive data SHOULD be encrypted. I do not see why encrypting the data would be an issue at all.

share|improve this answer
    
Hi Terry Chia, thanks for your answer, I'd like to encrypt the data, but I'd like to encrypt it at the application -server and store the encrypted data in the database. I'm looking for a solution/best practise which helps me to en/decrypt the data at the application server. –  kekeria Jun 18 '12 at 15:03
    
@kekeria Perhaps you could edit your question with the type of data you are hoping to store? I'm sure best practices differs in different situations. –  Terry Chia Jun 18 '12 at 15:06
    
thanks again for your input. I updated my Question. –  kekeria Jun 18 '12 at 15:17
    
@kekeria - Why do you want to do it at the application level, a level that is far more vulerable, and doesn't stop somebody from decrypting the information. –  Ramhound Jun 19 '12 at 16:19

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

http://www.oracle.com/technetwork/database/security/tde-faq-093689.html

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.