Threat Model / Scenario
I am concerned with a Thread Model, where certain sensitive data is stored in a database. Its not as sensitive as Credit Card information or passwords, but telephone numbers, email addresses and the like. Lets assume I fear a database leak, where an attacker somehow can read more information than allowed to him from the database. What can one as administrator do against that?

What I considered
Lets assume that we keep the software which organizes and dispenses the data up to date and patch every vulnerability as fast as a patch is available.

I considered that we may encrypt the sensitive data with for example the users password. (Not the stored hash in the database). The consensus however is that its not good practice to save encrypted data in a database. Furthermore the data would be lost if a user forgets her password.

I also considered encrypting all data with a key that is stored in the OS environment, but this would probably not help against leaks in the form of e.g. SQL-Injections, unless one keeps the data encrypted until a user logs in and then decrypts only the users portion of the data until she logs out again.

So my question is, what would be a sensible way to go about in the aforementioned scenario?

  • So, you mean reading the database through the app itself? That's your threat scenario?
    – schroeder
    May 10, 2017 at 17:03
  • To add on to @schroeder's point, if an attacker is able to compromise the database, and the database contains the user's hashed password, the attacker can just crack the users password, login using the stolen credentials, and see the exact same information (assuming you're not using 2FA) May 10, 2017 at 17:17
  • Yeah, either that or by otherwise acquiring the database.
    – WeGi
    May 10, 2017 at 18:08

1 Answer 1


The only reason not to encrypt data inside the database columns that I am aware of is performance/data duplication concerns. Are you going to be doing joins or lookups from the database based on the data in question? If you don't need to do that, feel free to encrypt the data in the database columns

I believe the proper way to do it would be to encrypt the columns in the database, and store the encryption key in a separate datastore, such in a file in the filesystem. The decryption should happen on the fly in the web application whenever the data is requested. That way if the database is ever compromised via SQL injection, the attacker will be able to retrieve encrypted data. Keep in mind that you if you do not have a unique key per user, it's possible for an attacker to determine two users which have the same phone number since the same plain text ciphered with the same encryption key will give the same cyphertext. Please keep proper key rotation in mind as well.

  • Thank you for your answer. This sounds reasonable. I imagine the second key database should be only accessible from the machine running the datastore to further add to security.
    – WeGi
    May 10, 2017 at 18:13
  • It doesn't have to be a database. It can be a file folder on the same server that the web server sites on. It just can't be accessible from the same database that stores the information per your threat model. Besides, even if it were on a separate server, if the an attacker compromised the main web server, he/she could just grab the decryption keys/the decrypted data from memory. May 10, 2017 at 19:55
  • What about searching and sorting? This is not a good answer May 10, 2017 at 20:47
  • @NeilMcGuigan I out searching and sorting in the first paragraph of my answer, and mentioned that this would only apply if you did not need to search or sort on that information. Given that caveat, would you agree that this is an acceptable answer? May 10, 2017 at 21:30

You must log in to answer this question.

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