4

The way I see it: there are two ways to encrypt data for a web app.

1) Store a single encryption key on the server, and use it to encrypt / decrypt data at runtime. The obvious issue here is that if a hacker does gain access to your server, it's only a matter of time until they find the encryption key and then all hope is lost.

2) Use a user's password as the encryption key. It seems like a bad idea to store their password in session information though, and it wouldn't work for collaborative apps. For collaboration, you could use a shared secret instead, but I've never seen a website ask you to remember two passwords (one that everyone in the organization knows).

So are we supposed to just go with method 1 and hope for the best? Or is it enough to just encrypt at the disk level? With that though again, if a hacker can gain access, they'll have no problem reading it. What's the standard here when dealing with sensitive data?

  • There is an other approach: you can send the encrypted data to the client and have the client use its private key to decrypt it. – Kasper van den Berg Jul 3 '15 at 13:11
  • True! But that still wouldn't work for a collaborative web app. Good point though. – Luke Sapan Jul 3 '15 at 13:13
  • You may want to read the paper "Structured Encryption and Controller Disclosure" by Melissa Chase and Seny Kamara eprint.iacr.org/2011/010 as published by Springer in Advances in Cryptology - ASIACRYPT 2010 Lecture Notes in Computer Science Volume 6477, 2010, pp 577-594. (Not sure if that helps in a collaborative web app, perhaps their method allows Diffie-Hellman or Elliptic Curves). – Kasper van den Berg Jul 3 '15 at 13:14
2

It depends on from which threats are you going to protect.

Encrypting data on database level is great protection, when you have so many IT employees, that you're able to divite them into teams responsible for each layer.

For example, banks and credit cards acquirers use PCI DSS security standard, which require such protection along with dividing IT staff into teams and restricting permission outside assigned layer (eg. internal network, or just border routers).

On the other hand, database-level data encryption gives you very little additional protection from outside threats, while causing rather huge application development overhead.

So if you don't care so much about protecting from inside threats, then disk level encryption should be just fine.

  • That makes perfect sense, thank you. I do have to wonder how much gain you really get from disk encryption as well. Let's say you're hosting with EC2, isn't disk encryption really just preventing an AWS employee from going rogue and stealing the drive with your data on it? – Luke Sapan Jul 3 '15 at 13:26
  • If you're using Xen container (EC2 or other), then you're practically not able to deploy device-level encryption. On the other hand, Amazon uses so high security requirements for its employees, that you shouldn't be afraid of them. – Tomasz Klim Jul 3 '15 at 13:30
  • I'd also add the requirement that you don't need to run queries on encrypted data. i.e credit card numbers. You likely wouldn't want to encrypt the name, card type, or expiration date as these are likely common things you might want to search on, but the card # and CVD could be encrypted. – Steve Sether Jul 3 '15 at 15:13
0

Nothing is futile, and there are no silver bullets. Everything depends.

There was a sidebar about using disk encryption. That is protecting against a different attack surface, so lets ignore it.

The question asks if it makes sense to encrypt data that is in a database, under the assumption that it needs to be plaintext for a web client. The presented choices are to use a master token (outside of the database) to decrypt the stored cryptotext, or to use a token provided by the user, with the observation that this is a bad idea and wouldn't work for collaboration.

If the concern is that someone might violate the confidentiality of the web server, say to hoover up that stored master token and the database, then indeed you are out of luck. The mitigation here is that often the violation of the database and the violation of the web configs are different, and one without the other isn't helpful. So it is protective in for example the classic example of a sql injection attack dumping the DB.

At that point, using a token provided by the user is very helpful, and I wouldn't call it a bad idea. Note that in theory this can still be useful in collaborative apps: the stored cryptotext can be encrypted using a stream cipher whose key is encrypted (e.g. via a PKI) against multiple people's keys. Now, the confidentiality of the server isn't a problem (assuming that they don't have access to runtime) -- no collection of information on the server can turn the cryptotext to plaintext without the user tokens.

But, if the integrity of the server is in question, then this solution fails. The plaintext is in the memory of the server, so its game over... the program can be reconfigured to persist the plaintext anywhere its desired, or even to change the messaging between the clients. That's where the third solution comes into play. If you have code running on the client machine that does the decryption of the passed information and encryption of any response, you are back in safe water. (Although of course now it is down to the opsec of the end clients, but then that is always the case.)

So evaluate the risks and costs of various cases of loss of integrity at the server, and make your choice.

Sidebar: if you really do care about this stuff, STOP USING PASSWORDS. If you don't, IMHO a master token is fine.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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