10 ms·

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 pro

by ntpl 12y ago

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?

vog 12y ago
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.
- seanp2k2 12y ago
  The irony here is that it's a site largely about computational complexity.
- ntpl 12y ago
  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.).
- stouset 12y ago
  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.
  - mden 12y ago
    A noob question I suppose, but couldn't the salt be generated deterministically from the email and still serve it's purpose?
    - pushrax 12y ago
      Then it's just a more complicated hash function.
      - mden 12y ago
        Ah of course. Thanks.
  - runamok 12y ago
    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.
    - Arnor 12y ago
      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.
      - runamok 12y ago
        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.
- SkyMarshal 12y ago
  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.
  - sp332 12y ago
    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.
    - jgeralnik 12y ago
      bcrypt and scrypt are always salted (it's part of their algorithms - there is not such thing as unsalted bcrypt/scrypt)
    - stouset 12y ago
      No. No, they cannot.
hyperpape 12y ago
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/ http://codahale.com/how-to-safely-store-a-password/).

by ntpl 12y ago

vog 12y ago

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.

seanp2k2 12y ago
The irony here is that it's a site largely about computational complexity.
ntpl 12y ago
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.).
stouset 12y ago
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.
- mden 12y ago
  A noob question I suppose, but couldn't the salt be generated deterministically from the email and still serve it's purpose?
  - pushrax 12y ago
    Then it's just a more complicated hash function.
    - mden 12y ago
      Ah of course. Thanks.
- runamok 12y ago
  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.
  - Arnor 12y ago
    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.
    - runamok 12y ago
      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.
SkyMarshal 12y ago
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.
- sp332 12y ago
  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.
  - jgeralnik 12y ago
    bcrypt and scrypt are always salted (it's part of their algorithms - there is not such thing as unsalted bcrypt/scrypt)
  - stouset 12y ago
    No. No, they cannot.

hyperpape 12y ago

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/ http://codahale.com/how-to-safely-store-a-password/).