Hacker News Reader

Comment by ntpl | Hacker News Reader

It's one thing to decide not to store emails (sure, why not?) but account recovery shouldn't even require one to store email addresses.

Check the the email provided by user via the recovery form against a hash of the email saved during registration, if it matches send the reset link. This way when data is breached, figuring out what the original email should be hard (if not impossibly hard, depending on how they hash it).

Am I missing something here?

View on HN

You should not simply use a hash, but at least a salted hash, or even harder stuff like bcrypt. In other words, treat emails like passwords.

Apart from that, I don't see any issues with that approach. Not sure why project euler doesn't use that approach.

The irony here is that it's a site largely about computational complexity.

A salted hash would completely eliminate any ability to look up accounts by email address, since you would have to hasn't the email against the salt for every account in the database until you landed on the correct one.

A noob question I suppose, but couldn't the salt be generated deterministically from the email and still serve it's purpose?

Then it's just a more complicated hash function.

Ah of course. Thanks.

You could have one of two approaches. 1. Don't use a per user salt and just use a global salt. You can counteract this decrease (a bit) in security by increasing the key stretching part of your hashing algorithm. or 2. Require the user to submit their email address AND username and store the salt in the user's record.

I agree with someone up there that email address != password. It's refreshing to see someone that gives a crap about my privacy though.

I had a visceral reaction to "global salt" (I've always heard this called: "pepper") because it's so insecure for passwords, but I guess it's not as bad for email addresses. In the case of passwords, we find that a global salt is fairly ineffective because too many people use common (stupid) passwords like "password." If 10% of the hashes are the same, you can probably figure out what that hash means pretty quickly. We don't have this overlap problem with emails so it's less scary.

Still, simply storing the create time or a randomly generated salt right on the user table is more secure than using a global salt.

Right but in this case you would essentially have to use every salt from every user to hash the submitted email and say "aha user 123,456 has a salt and hashed email which matches the submitted email of foo@example.com" which is why I suggested method 2. I am user "Arnor" and my email is "foo@example.com". Ok, your salt is #@$%@#$%DGDFfdgdawer.

If your hashing algorithm is appropriately "expensive" the scan all user salts would not work.

A global salt is not a thing. Not is a pepper. The actual cryptographic construct is an HMAC and secret HMAC key.

.. can't you just use a few bits of hashing (via a second algorithm) the original email address for the salt?

Now you just have a different, slightly more complicated hashing function.

Ah, indeed.

A global salt is called 'pepper'.

This thread is dishearteningly full of cargo-culted cryptography. You would think HN would do better. A global salt is not a thing. It's a misapplication of a cryptographic component. The appropriate tool when you think you need something like this is an HMAC and a secret HMAC key.

I wasn't saying it was a good idea, just that the majority of people using one refer to it as a pepper.

Once again we are talking about having an email retrieval function while not storing the email address in plaintext. A "global salt" or "pepper" (as we are apparently calling it now) just prevents enormous pre-generated rainbow tables but admittedly in today's gpu dominated cracking environment it probably doesn't get you much.

Personally I think not having a password retrieval function while simultaneously forcing all of your users to reset their password is a pretty user unfriendly tactic for the protection of an ostensibly public piece of information.

Hello? Lets say you have 5 billion accounts, in salted sha1. According to openssl speed sha1, you'd take less than 38 minutes on my ancient desktop to look up an email, on average half that. If the shoe fits, send the email, if not don't?

Sure having another field to match on (eg: username) for locating the correct salt would be good -- but it's certainly not infeasible to do a brute force search (probably want to queue up password request requests, though). Now, if you went with bcrypt or scrypt -- things would, by design, break down a bit. I still think you'd be able to send a reset mail within 24 hours for most reasonable configurations and number of users...

Taking unnecessarily long to handle a lookup request might leave server very vulnerable to DDoS attacks leveraging this "account recovery" option, I think.

Even worse, an invalid email would take the longest possible time, every time.

And since this is only an email address we are talking about, a global salt + more stretching (like runamok mentioned above) could be secure enough while still providing faster lookups.

Of course, you could protect from the DDoS by maintaining a secondary application server which connects to a slave database. Then the requests for account recovery wouldn't impact the rest of the system. :)

That's why I suggested a queue, so you'd only ever need to have a maximum of <total number of accounts> pending. I missed the part about using this for login as well as recovery though (but also, note that numbers are for 5 billion accounts, an scales linearly with accounts -- so divide by 2000 for half a million accounts).

38 minutes to log into your account seems excessive. Remember, this isn't just for password resets — it's to look up an account in the database by email address.

Ah, fair point. So we agree they need a (possibly not unique) user name too. [edit: note this is for 5 billion accounts, on a 10 year old cpu. So for 500.000 accounts, it would be ~1 seconds (average 0.5). Still probably too long for log-in (or particularly log-in failure feedback)).]

If you have a username and emails aren't used for contacting users, why bother storing the email address to begin with?

To verify that a username matches a given email address, so that you can provide password resets?

The salt for the email could be a CRC, or a Fisher-Yates, or any of a dozen other novel one-way transformations.

You do not appear to understand the purpose of a salt. A salt should never be derived from the data it is to be used with. The entire purpose of a salt is to cause two identical inputs to a hash function to produce distinct outputs.

Right. Thanks for pointing this out. So at least an additional "lookup helper" such as a username would be needed.

Presumably they know their username, so a look up of that nature isn't needed unless they forgot that as well.

Right, which is why I said

> figuring out what the original email should be hard (if not impossibly hard, depending on how they hash it)

I mean, passwords are way more sensitive than emails, especially given that many people re-use them. So, how you hash passwords is more critical than how you hash emails (which is rarely done, I guess).

On the other hand, there is no reason to not have the same level of protection for emails, if you are already following best practices for passwords anyway (PBKDF2, bcrypt, scrypt etc.).

A little off topic, but is there any reason to still be talking about salted hashes when we have bcrypt and scrypt these days? Seems like an anachronism.

An attacker can pre-compute hashes of common passwords for common settings of bcrypt/scrypt. With a salt, they have to start from scratch every time.

bcrypt and scrypt are always salted (it's part of their algorithms - there is not such thing as unsalted bcrypt/scrypt)

No. No, they cannot.

Of course you're right, and I can't believe I didn't realize that. I think my point still stands that it's a bit silly to worry about storing emails, but you're right that you can even avoid that risk by encrypting them if desired.

(And "hash" is a bit misleading: http://codahale.com/how-to-safely-store-a-password/).

Reply on news.ycombinator.com