2

If your running a web services with lots of users and you get hacked, you may be giving away users's plain text information like email and hashes like password hashes.

Is it worth storing email addresses as hashes too?

  • 7
    Not if you are using the email addresses to communicate with your users. – RubberStamp Jan 12 at 20:29
2

The first question you need to ask yourself is, does your service need the email address in the first place and what does it need that email address for?

If you don't need the email address, then don't store it.

If you need to know the email address, and if all of those needs can be satisfied by a hashed version, then it sounds like a good idea to store just a hash.

If you need to know the email address for purposes which cannot be satisfied by a hash, then it's not a good idea to store just a hash. If for example you need to send emails to your users, chances are you cannot do that with just a hash.

A realistic use case for hashed email address.

Imagine a site where users can log in using their email address and password. The user may also have a username, but that's outside the scope of this answer.

When the user logs in they type their email address and password. In order for you to find that email address in your database a hash value would be sufficient. You can simply store just a hash and before you do a lookup you hash the value provided by the user.

If you just did a plain unsalted hash, those values could still be compared across different sites (if for example multiple sites using this approach had data leaks). On the other hand hashing with a unique salt per user like is best practice for passwords wouldn't work either. It would simply be too inefficient to compare the user against every entry in your database.

Instead you can have a site-wide salt that you change infrequently (like once per year) such that each login can be tried with every salt value that you have ever used.

That way you can look up users in your database by email without ever needing to store that email address. Passwords you of course still store using a password hashing with a unique salt for every stored password.

Should you want a feature to send password reset emails, that's possible as well. When the user type in their email to receive a password reset email, you can look it up in the database the same way you'd do for a login.

If you also want the users email to be visible to the user while they are logged in, you can store a cookie in their browser with an encrypted version of their email address using the hash as key.

  • One situation where hashed email may make things difficult is customer support over phone. A hashed email would require that support reps type the exact email address the way the user typed them, including case and accents/unicode characters. With plain text email address, implementing case and accent insensitive and similarity based search would be a lot easier. – Lie Ryan Jan 14 at 3:26
  • 1
    @LieRyan True, it may be easier to do customer support if your support personal can look up the users based on a partial email. However that approach is potentially vulnerable to social engineering. – kasperd Jan 14 at 7:21
  • thank you for the specific use case. now seems obvious, but couldnt see how forgotten password would work before. is this the sort of thing web applications do usually, or would be advised? – benbyford Jan 14 at 7:40
  • 1
    @benbyford I don't know of anybody doing this. As far as I know they are pretty much all storing the email address in clear. – kasperd Jan 14 at 8:04
  • ok interesting. maybe more research to do here then. thanks – benbyford Jan 14 at 12:02
11

Generally speaking, you shouldn't ask and hold user data (especially PII) that you don't need, this is even more true now under GDPR (if it applies in your scenario) but it's always been the case in security. The lesser the data, the lesser the risk.

When you hash passwords, you lose knowledge about its plaintext version and the fact that you're asking whether it's worth hashing emails as well as passwords, makes me think that perhaps you don't really need that information in the first place.

That being said, if you do need emails (for other purposes than logging) then you can't hash them as you would lose that information by doing so. In that case I'd instead recommending encrypting/authenticating your data using AES/HMAC or Chacha20/Poly1305 or similar.

Another approach would be to use PAKE: no emails, no passwords and no need to transfer them over the Internet! An example of this can be SRP or OPAQUE.

  • Hmm. Would it change your answer if the question had read "username" rather than "email address" ? – Mike Ounsworth Jan 13 at 1:48
  • 1
    @MikeOunsworth In general, hashing is a 'destructive' operation: once if you hash X and get Y, you can't "unhash" Y and get X back. Usernames are usually meant for being displayed on the website/application, but if you store them in hashed form you can't do that. Probably best to encrypt that kind of data (but really any data). If you can encrypt it, encrypt it :-). – XCore Jan 13 at 2:02
  • So your answer hinges on whether or not the username / email / wtv needs to be used at a time other than login? Encrypting a db isn't a silver bullet either of course cause you get into the "Where do I store the key?" problem. – Mike Ounsworth Jan 13 at 2:04
  • @MikeOunsworth correct! Also, encryption is surely not a silver bullet: security is made up of multiple layers, encryption is just one of them and can help or even save you in some cases, but it still just a layer. Application-level encryption surely won't help you if your webservers are hacked (i.e. server access), but say that you take daily backups and store them in S3, then leave your bucket public - if encrypt everything and some gets your backups, that data is still safe. It's all about the threat model. – XCore Jan 13 at 2:50
  • 1
    @they the need to lookup makes it a bit difficult - there are a few ways though: paragonie.com/blog/2017/05/… or by using homomorphic encryption en.m.wikipedia.org/wiki/Homomorphic_encryption – XCore Jan 14 at 13:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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