While wealth (or rather, being "wealthy") is absolutely a success, it is not the only way to succeed nor is its definition "not being poor".
As such, I'd like to believe people at places like /r/povertyfinance would still consider themselves successful if they moved beyond their financial challenges through a ton of work even if they don't end up wealthy.
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).
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.
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.
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.
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)).]
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.
> 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.
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.
As such, I'd like to believe people at places like /r/povertyfinance would still consider themselves successful if they moved beyond their financial challenges through a ton of work even if they don't end up wealthy.