So in a database many user fields could exist. Normally when I setup a database I go off of the security experts recommendations on what fields to encrypt, but I'm curious what is the most standard set of fields to encrypt? As far as I've seen it's usually the password(hashed), credit card(AES), and the phone number(AES), but the address, name, and other parts are left plaintext.

Since a lot of people here probably encrypt other fields as well, I'm curious what fields do you encrypt in your user databases?

  • I think it depends a lot on your database usage, if you'll do search on those fields or not... – woliveirajr Sep 25 '15 at 19:30
  • Well like I said, I usually just follow what I'm told to encrypt(for example one of my recent databases was a heavily referenced database without any credit card or social security information so we only encrypted the passwords) so I'm curious what people often times encrypt so I can get an idea on what should be, and shouldn't be encrypted. – Robert Mennell Sep 25 '15 at 19:49

Encryption is just a tool; it is applied for mostly three reasons:

  1. To achieve some confidentiality. This makes sense in contexts where the stored data (database contents) could be exposed to malicious third-parties, but some specific data element (the encryption key) could be kept hidden from the same malicious third-parties.

  2. To achieve compliance to some regulations. For instance, when dealing with credit card information, one more-or-less has to follow the prescriptions of PCI-DSS, including applying some encryption for some pieces of data.

  3. To give a feeling of security by sprinkling some crypto all over the place. This reason, of course, is not good; however, it is very common in practice.

For the first reason, this makes sense only relatively to an attack model where attackers cannot read the encryption key. The application which accesses the database must, by definition, be able to read the data contents, so it must know the decryption key. Consider, for instance, a comprehensive full-database encryption (what Microsoft and Oracle call TDE): this encrypts all the database contents; but the application that accesses the database must know the key, to decrypt the data on-the-fly, and sees the cleartext contents. If the attack model is about attackers who steal backup tapes or recover discarded hard disks, then TDE is the way to go: such an attacker will only see a big encrypted pile of data, with a key that he does not have. On the other hand, if the attack model is about SQL injections, then TDE offers no additional security since the injected SQL is interpreted in the context of the normal application, over the decrypted data.

For the second reason, encrypt that which is necessary to achieve compliance, and be done with it. That's the good thing about compliance: you do not have to think, only to follow the rules.

For the third reason, you need to invoke the crypto gods for every field that auditors / bosses / customers feel to be "important". Usually, people feel nervous about what they consider to be their identity, so names, email addresses, street addresses, phone numbers... should all be encrypted. Since this is only security theatre, you can most of the time achieve the same kind of psychological effect with an "encoding" that needs not be encryption properly said (e.g. Base64).

| improve this answer | |

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