How would you deal with sensitive data in your database?

Question

In some project we have very that even our staff is not suppose to have access to. In theory, we have policies to ensure they don't. In practice, we are in Africa and policies don't mean a lot, no matter how strongly you enforce it.

I would like to know is there is a way to encrypt data in your database so:

• each user password encrypt and decrypt its own data, and its own data only;
• data is decrypted as late as possible in the process to ensure maximum security to the user. Ideally it would be on the client side I guess, but I'd love to hear that it's possible to do some crazy thing I don't know about on the server side.
• data is still searchable. Is that even possible?

My first idea was: "if a customer want THAT level of protection, then give him its own hosting on a virtual machine and encrypt the hardrive, then all maintenance must be done with it's allowance".

Answer 1

Hi,

I can't come up with a fancy strategy just how I've implemented this:

Keep in mind that you have to re-encrypt everything when the user changes his password. I'm using always the same encryption key but the key is encrypted using the user's plaintext password. So I just have to re-encrypt the key. The user's password is stored as a salted hash so nobody can decrypt the key and the data even if he sees the hash.

It works like this:

1. User enters his plaintext password

2. Create salted hash

3. Check if the generated hash matches the one in the database (authentication)

4. If yes, then decrypt the key for the data using his plaintext password

5. Decrypt stored data using the key

This won't give you 100% security but improves it.

Answer 2

Here are a few things I can think of:

You should encrypt data stored when it is stored in the and when you read it back. Use a solution that integrates at an RDBMS level rather than the data layer.

For the transport of data to and from the application, use HTTPS web services.

If you have a Desktop application, do not store any data and log files etc locally.

If it is a web app, make the app HTTPS as well.

Security is bound to make the app a little slower than using plain data, but that's the price you will pay.

Answer 3

It really depends on what and where (on the client or server) you are doing with the data.

For example, your application don't need to know the password itself to verify it during authentification. Best practice for this use case is to store only a cryptographic hash (e.g. sha1) of the password and a random salt. That is sufficient to verify it, but giving only the hash and salt, it would take a nearly infinte amount of time to figure out the plain password.

Encryption can be a soultion if you have to exchange data over unsecure channels. But keep in mind that in order to process the data you have to decrypt them. So if de- and encryption is done on the same machine, it's rather pointless. And if decryption is required it doesn't matter how late you are going to do it, because of the key must be given anyway.

You can use encryption to secure the communication between the server and the client, for example. You could even generate messages on the server that only the client will be able to read and vice versa using asynchronous encryption. So once the message was generated on the server and encrypted using the client's public key even the server isn't able to read the message anymore, because of the private key only the client knows is required for the decryption.

What you denfinetly can not solve by cryptography is, when you have data on the server, that the server should be able to read in order to process them but human users unrestricted with priveleages to this server shouldn't.