Encrypting email addresses in php

Question

I'm building a website and am trying to figure out a way to encrypt the user's email addresses. It would be nice if, in case my database was stolen, the emails of my users weren't in plain text. I figured the user needs the email to login obviously, so if I encrypt it with their password as the key, or even the email itself, then I could still build a login function, that would work.

Problem comes with situation when I need the user's email address. For example, in a situation as a password reset or sending out a newsletter. I could have a second field in the database with the user's email address, encrypted with a key that I know.

Can I encrypt something, where two keys work? Like a master key..... or am I being stupid?

Answer 1

If you only need to verify the email when the user provides it, then hash it, like vidarlo suggests, in the same way you would hash a password. No need for encryption here. The flip side with this approach is that you can never recover the email, even if you really need it (e.g. to contact your users in case of a compromies, as suggested in comments).

If you need to be able retrieve the emails, then encrypt them once with a key you control. No need to encrypt the email twice for different purposes here - just do it once. The tricky part with this solution is where to store the key.

Answer 2

Do you really need the users e-mail address?

If you store e-mail address as hash(e-mail + salt):salt you can trivially verify the e-mail address supplied by the user. If the user requests a password reset, simply verify that the e-mail address matches, and send the e-mail to the user supplied e-mail.

If you want to allow lookups in the database based on e-mail address (username being e-mail for instance), this model will obviously not work. However, as pointed out by Conor Mancone, a global pepper for all addresses will work, but will somewhat reduce the security.

This removes the possibility for you to send newsletters, obviously. But it means that a database breach will not reveal the e-mail addresses.

Answer 3

An alternative to existing answers: put the emails on a separate machine & application and store only the hashes in your main application DB.

Use the hash for verifying the emails.

When you need to send an email your application will communicate with this other service passing on the hash + email message and the other application will send the email.

Obviously a hacker could hack the secondary machine and gain access to the emails but you are still adding security because:

1. The secondary machine need not be exposed to the internet
2. The secondary machine can be extremely minimal, it only has to expose a very limited API to your application and have a service to send emails
3. It can be locked down a lot since it does only a very specific thing

So the attack surface of the secondary machine can be way smaller than your application's.

Bonus points: you can apply the other answers to your secondary machine, increasing the security even more (although it wont ever be perfect if you assume you are already hacked...)

Answer 4

Logging in requires looking up the email address, which isn't scalable if they're hashed properly – with 10k users in your system, you'll have to hash a user's email on average 5k times on every login, due to salts.

May I question your premise?

"I figured the user needs the email to login obviously"

Why not issue them (or let them select) a username instead? This then won't tie back to their email unless they choose a username very close to their email.

Obviously you still need their email if you're doing a password reset, but you could not offer this, use a alternative method (e.g. a OTP code given at signup), or keep a separate DB of usernames to emails.