Is it worth encrypting email addresses in the database?

Question

I\'m already using salted hashing to store passwords in my database, which means that I should be immune to rainbow table attacks.

I had a thought, though: what if s

Answer 1

Don't accidentally conflate encryption with obfuscation. We commonly obfuscate emails to prevent spam. Lots of web sites will have "webmaster _at_ mysite.com" to slow down crawlers from parsing the email address as a potential spam target. That should be done in the HTML templates -- there's no value to doing this in persistent database storage.

We don't encrypt anything unless we need to keep it secret during transmission. When and where will your data being transmitted?

1. The SQL statements are transmitted from client to server; is that on the same box or over a secure connection?

2. If your server is compromised, you have an unintentional transmission. If you're worried about this, then you should perhaps be securing your server. You have external threats as well as internal threats. Are ALL users (external and internal) properly authenticated and authorized?

3. During backups you have an intentional transmission to backup media; is this done using a secure backup strategy that encrypts as it goes?

Answer 2

A copy of my answer at What is the best and safest way to store user email addresses in the database?, just for the sake of the search...

---

In general I agree with others saying it's not worth the effort. However, I disagree that anyone who can access your database can probably also get your keys. That's certainly not true for SQL Injection, and may not be true for backup copies that are somehow lost or forgotten about. And I feel an email address is a personal detail, so I wouldn't care about spam but about the personal consequences when the addresses are revealed.

Of course, when you're afraid of SQL Injection then you should make sure such injection is prohibited. And backup copies should be encrypted themselves.

Still, for some online communities the members might definitely not want others to know that they are a member (like related to mental healthcare, financial help, medical and sexual advice, adult entertainment, politics, ...). In those cases, storing as few personal details as possible and encrypting those that are required (note that database-level encryption does not prevent the details from showing using SQL Injection), might not be such a bad idea. Again: treat an email address as such personal detail.

For many sites the above is probably not the case, and you should focus on prohibiting SELECT * FROM through SQL Injection, and making sure visitors cannot somehow get to someone else's personal profile or order information by changing the URL.

Answer 3

Both SQL Server and Oracle (and I believe also others DBs) support encryption of data at the database level. If you want to encrypt something why don't simply abstract the access to the data that could be encrypted on the database server side and left the user choose if use the encrypted data (in this case the SQL command will be different) or not. If the user want to user encrypted data then it can configure the database server and all the maintenance work connected with key management is made using standard DBA tool, made from the DB vendor and not from you.

Answer 4

@Roo

I somewhat agree to what you are saying but isn't it worth encrypting the data just to make it a little more difficult for someone to get it?

With your reasoning, it would be useless to have locks or alarms in your house, because they can also easily be compromised.

My reply:

I would say that if you have sensitive data that you don't want to fall in the wrong hands, you should probably do it as hard as you can for a hacker to get it, even if it's not 100% fool proof.

Answer 5

I realize this is a dead topic, but I agree with Arjan's logic behind this. There are a few things I'd like to point out:

Someone can retrieve data from your database without retrieving your source code (i.e. SQL injection, third-party db's). With this in mind, it's reasonable to consider using an encryption with a key. Albeit, this is only an added measure of security, not the security...this is for someone who wants to keep the email more private than plaintext, In the off chance something is overlooked during an update, or an attacker manages to retrieve the emails.

IMO: If you plan on encrypting an email, store a salted hash of it as well. Then you can use the hash for validation, and spare the overhead of constantly using encryption to find a massive string of data. Then have a separate private function to retrieve and decrypt your emails when you need to use one.

Answer 6

In common with most security requirements, you need to understand the level of threat.

What damage can be done if the email addresses are compromised?

What's the chance of it happening?

The damage done if email addresses are REPLACED could be much greater than if they're EXPOSED. Especially if you're, for example, using the email address to verify password resets to a secure system.

The chance of the passwords being either replaced or exposed is much reduced if you hash them, but it depends what other controls you have in place.