I just added some code to our app server to encrypt personal information before it's stored in the database. This was mostly done for compliance reasons, but how much of an actual security win is it?

I hear about database dumps all the time, but I'm not clear on how the attackers usually get the database. If it's by getting to a shell and being able to run arbitrary code, it seems fairly simple to go over to the app servers to find the encryption key being used.

I ask this because if it's a real security win, then we should probably encrypt more data before it reaches the database. On the other hand, if it's just theater, I'd rather spend our time improving security in a meaningful way.

(This is assuming the backups for the database are themselves encrypted).

  • 2
    Partial answer, but some ways to get dumps: Backups, SQL Injection, Open Ports with poor access rules or default passwords. Developer takes a snapshot and uses it locally with auth turned off.
    – nbering
    Commented Jul 24, 2018 at 0:57

2 Answers 2


Since there's not been an answer, I'll take a shot at this... but there are other questions about Database Encryption already, so you might want to check some of them out, as well.

As for how Database Dumps are acquired:

  • Backups
  • SQL Injection
  • Open Ports and the related terror of Default Passwords
  • Production Snapshots used in Development or Staging

While it's possible that an attacker could just acquire the encryption key from disk as you suggest... I cover some ways to mitigate that risk in a previous answer.

As for it's overall effectiveness... I wish I had some statistical resource to call on, but I don't. Intuitively, it would seem to protect your data with most static dump approaches. It increases the complexity requirement for an attacker - which is generally exactly what you want - since they will now need to breach your application layer to get the keys, in addition to the database layer.

The Patreon Breach is generally my favourite example of how Database Encryption helps to mitigate the fallout of a major incident.

  • Reading the Patreon breach, what I get is that the passwords are safe because the way Patreon hashed them would require too much time to be force bruted or even rainbow tabled. I don't see anything about generic encryption of things, which is way easier to reverse than a hash (by definition)
    – Xenos
    Commented Jul 24, 2018 at 12:24
  • Sorry... maybe I picked a bad link for that. They had also encrypted SIN numbers and a lot of other payment-related PII. It made a big difference in the long-run.
    – nbering
    Commented Jul 24, 2018 at 12:25
  • Here's an article that references the encryption of the tax information, and also how the attackers got in (looks like through a dev/staging environment). motherboard.vice.com/en_us/article/qkvgj3/…
    – nbering
    Commented Jul 24, 2018 at 12:29

Hard to answer in a generic way, because it depends on the real use case. So I will just give some hints and questions you could considere for making the choice.

  • is that database encryption required to meet some regulation or normative rules? If the answer is yes and it is enough to meet the requirement, do not worry for more.
  • have you done a risk analysis? if the answer is no, it should be considered before any other action
  • did the risk analysis conclude that you should avoid to be liable for a data leak at all costs? if the answer is yes, then you should considere a client side encryption solution: if you do not own the key, you cannot be liable for a data leak
  • did the risk analysis conclude that you must protect users from a possible key/password loss? if the answer is yes, client side encrytion is not an option

The problem when the encryption is done server side is that the key has to exist in a invertible form on the server. So it is not a magic bullet (like is client side encryption) but only an element of in depth defense. The attacker has to:

  • find an exploit on the server
  • use that exploit to gain access to the database
  • use that exploit to find the encryption key

Each phase is expected to take some time that you can use to repell the attack.

Regarding your question about database dumps, it is mainly a concern when the database is not inside the same datacenter, and could have a lower protection. It is also a concern as soon as you considere internal attacks. An admin connection to an application server to look for an encryption key is not a standard operation and could be noticed, while a connection to the database to extract a dump is often a standard maintenance operation so is likely to be unnoticed.

You must log in to answer this question.

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