Is it a good idea to store Email addresses as hash only?

Question

I am currently building a web service at http://write-math.com similar to http://detexify.kirelabs.org/ that should help users to get LaTeX code from drawn formulae. It is part of my bachelors thesis and a main goal of this project is to make it easier to do research in the field of on-line handwriting recognition. That means I want to share all data I get from users.

The easiest way to do so would be to simply dump the database. This way I could do my back-up copy and a dump for researchers in one step.

There are only two pieces where I hesitate to share it with the public as soon as other users use my system: Email addresses and passwords.

Passwords

The password is stored hashed and salted (that means I store md5($userpass.$salt) and $salt which is an 8 character random string with characters from A-Za-z0-9 - the salt is generated for each user). Is that enough so that it would be ok to make this public?

The main part of the question is about the Email address: At the moment, I store it as plain text. But I am thinking about storing a hash of the Email address only. This hash could not be salted, because my login function works as follows:

The user enters $email and $password. Both get sent as plain text to the server. Then the server does (as pseudocode):

$pwdb, $salt = query(SELECT password, salt FROM users WHERE email = :email)
if (md5($password.$salt) == $pwdb) {
   Logged in
} else {
   Wrong password
}

Email addresses

It does not matter if :email is $email or md5($email) or md5($email.$applicationwide_random_str). But I can't make a new salt for each user without having to go through each user (which would probably be not too bad when I think I will never have more than 10,000 users).

Questions

• How long would it take to "unhash" one Email (e.g. info@martin-thoma.de or mexplex@gmail.com) which has a random salt of 8 characters attached (e.g. FHCJ81ru) with "standard" hardware (< $1000) when you don't know the random string? Is it a matter of seconds, minutes, hours or days?
• Is it bad if people can do that? I mean they could also simply send Emails and look what they get back. In my service, there is not much personal data involved:
  • handwritten symbols and formulae
  • eventually handedness
  • eventually when / where the person learned writing
  • eventually the language of the user
• Why does no service hash the Email address (ok, I don't know if there are no services that do so, but I have never read that - hashing passwords is common, but hashing Email addresses? Never heard that.)
• Is it a good idea to hash Emails if you want to use the Email only if the user has lost his password and to sign in? (I though about using OpenID, but most people don't know what it is)

Answer 1

In the end, there are two questions: what you should store, and what you should share.

What you should store

Storing the email address has the advantage that you can contact users. A lot of sites do want to be able to contact users who are not currently logged in. For example, merchant sites want to be able to notify users that their order has been dispatched or that their payment bounced. A lot of sites have configurable email notifications. Sites may want to inform users of a privacy or security breach — people tend to prefer being notified privately than learning it in the news. And that's not counting all the nefarious purposes (sendind ---spam--- “promotional offers”).

If you decide that you never need to contact users, store (slow and salted! Not MD5 or SHA-2, but PBKDF2 or bcrypt or scrypt.) hashes of emails. But be aware of the limitations.

I assume that you'll be using email addresses as user unique identifiers. This has a downside: sometimes people change emails. For example, in the academic world (which a lot of users are likely to belong to), people often use their email from their current institution, and then the next year this email becomes unusable. This can cut them off from accounts that are too strongly tied to an email address. Be sure to allow a way to transition (which can be tricky if you require access to the old email address to add a new one).

What you should share

Brute-forcing a salting hash requires enumerating all the possibilities. The time it takes to try one possibility is a configuration parameter of a slow hash — you should make it as slow as your server supports, but no slower. So the answer to “How long would it take to "unhash" one Email” is literally “whatever you choose”.

How long it takes to brute-force your email database is not really the decisive question anyway. Verifying that an email is in your database is obviously practical — your server will be doing it all the time — and this allows someone who knows the hashes to answer the question “does Bob have an account?”. This is already a privacy breach.

The same goes for the password: even allowing third parties to check their guesses of Bob's password is bad. Not as bad as revealing Bob's password, but still bad.

So the simple answer is: do not communicate email addresses or passwords, nor hashes of them, to third parties. If you accidentally leak even hashes, this is a privacy breach. When you share data, use meaningless identifiers for user accounts, for example sequential IDs or random UUIDs.

Also beware of scope creep in your database. If you store too much information about a user, this can allow identification and making connections. This is a common problem with medical databases — if you happen to know that Alice was at Riverside Hospital from 1997-02-25 to 1997-03-03 and from 2001-07-21 to 2001-07-28, and there is a single patient record who was admitted Riverside Hospital in February 1997, left in March, and was admitted again in July 2001 — Alice has been identified even if her name was never exposed. This isn't likely to be a concern with the information you're planning to store now, but keep it in mind.

Answer 2

Never export any user data, even in hashed form, chances are someone will figure out a way to break the encryption/hashing.

So only export the relevant data tables, not the user table. You will have foreign key references in your data, so you know which items belong to the same user, but it will be an anonymous number account to whoever is using the dumped data.