17

It's clear to everyone (I hope) that storing passwords without at least salting/hashing them is a terrible idea.

What about emails? Let's say you keep the subscription email address, if you encrypt it properly it may not be usable to send emails to the users. On the other hand, if you don't encrypt it and the database gets stolen, all your users risk a potential spam.

This question is not about law-specific issues (although they may be given, they remain country-dependent) or about encrypting the database itself.

2
  • Think one should keep all PII (personal identifiable information) in a secured manner. That is encrypt data that the application should need (i.e. send some verification email) and hash/salt data used for authentication (i.e. password). Plus, of course, securing the data base is mandatory in this case. Feb 1, 2015 at 7:59
  • You could setup a separate application which stores only email + passwords (+other private data) for example. You could use that to send emails by calling it, for example with a internal rest api: localEmailServer/sendInvite/123 where 123 = user id. You can do the same for login, post to localEmailServer/login which can return true or false. That way your application can get hacked but still they won't have the e-mailaddresses. If you limit the amount of requests to this service it's more protected because you are not vulnerable to things like SQL injections on this part. Feb 1, 2015 at 8:59

2 Answers 2

10

Storing a salted hash of the email addresses could be on option if you keep those records just for account confirmation / authentication.

In other cases, it seems to me that encrypting the emails would make the job of maintaining the database harder while gaining little in return.

Probably securing the access of the database itself is a better choice: usually there are a lot of other information in the database that you wouldn't like to be gathered.


A similar question on Stackoverflow: Is it worth encrypting email addresses in the database?

3
  • Didn't see that question! For the record, it's an old question but I believe it should now belong to programmers.SE. Jan 28, 2015 at 11:00
  • 3
    @PierreArlaud: Actually, the whole thing would be better over on Information Security since it doesn't really have anything to do with programming.
    – Blrfl
    Jan 28, 2015 at 12:51
  • There is a return on encrypting emails indeed. If you don't store the keys in the same compromised database, you deprive the the bad guy from using the emails. Remember an email is heavily used for activation of accounts and change of credentials.
    – NoChance
    Jan 24, 2017 at 2:21
3

I think that you already said it all.

The only thing I can think of is not to use a one way hash filter like SHA1 to store the email addresses. Use some (reversible) public key encryption in your application and be sure that your private key is nowhere near to the database, so that they can't be "stolen" together.

That way, you can still unencrypt the email addresses to send emails,

5
  • 8
    And? And? The suspense is killing me :) Jan 28, 2015 at 11:00
  • And what? What is suspenseful? Encrypt (decryptably) in your app before storing in the database means no worries if the database is stolen, hacked, etc. But, when you want to send emails you can decrypt the email addressees from the database.Isn't that what you wanted? Am I missing something? Jan 28, 2015 at 13:21
  • 4
    Just a comment on the last character of your answer :D Jan 28, 2015 at 13:25
  • I'm trying to find what your answer says that manlio's didn't. Basically, the idea is to have a reversible hash of the email, such as a salted hash. Or perhaps you had something completely different in mind? Jan 28, 2015 at 13:26
  • 1
    Sorry, I guess we submitted at much the same time. Jan 28, 2015 at 14:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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