3 ms·

Slightly unrelated: A great way to solve this specific email issue is to store hashes for emails only, similarly to passwords. When a user needs a password rese

by kaba0 3y ago

Slightly unrelated: A great way to solve this specific email issue is to store hashes for emails only, similarly to passwords. When a user needs a password reset, they should send an email to a specific address, the sender mail is hashed, and if it matches a user, a password reset link is replied. That way a data breach can’t expose user emails. (This is what Tildes use: https://tildes.net/settings/account_recovery https://tildes.net/settings/account_recovery , and I found it very genius)

misterS 3y ago
This works great for password resets. It does not work if you actually want to send emails, for instance notifications.
- kaba0 3y ago
  That’s true, though many websites would be much better off if they would properly evaluate the question of do they actually need to send those?
- coldtea 3y ago
  That's an added bonus to the user in most cases!
vbezhenar 3y ago
While it's better than storing emails in clear-text, nobody uses vvkcbrxrsewf@gmail.com. Brute-forcing emails is going to be pretty effective. And if you have another e-mail database (which are plenty available in the open wild), I bet that success rate will be huge. I like Apple's approach to generating random throwaway emails.
- kaba0 3y ago
  You don’t have to use the same salt for each email, right? You can hash each email with a separate, random salt and “brute force” upon password recovery. That way while individual emails can still be restored, you can’t easily get a database of emails to mass-spam, which is the point (emails are not really private completely, anyway). I also like apple’s method, but it is not either-or.
bloak 3y ago
This is probably worth doing, but one should be aware that a typical e-mail address does not contain enough entropy to not be guessable offline. Perhaps someone should deliberately leek a bogus database that contains the bcrypt hash of davey.jones.490@well-known-email-provider.com and see if that account starts receiving spam ... probably it won't. There is (almost certainly) no associated e-mail account, but the following is the SHA-256 hash of firstname.lastname.threedigits, something like "davey.jones.490". I'm half-expecting someone to reply with the solution, though I think there are about 36 bits of entropy in my choice: b8b6395265714064afb525f37e9969a7dbf09a4a2afa28812e917580be2dc667

by kaba0 3y ago

misterS 3y ago

This works great for password resets. It does not work if you actually want to send emails, for instance notifications.

kaba0 3y ago
That’s true, though many websites would be much better off if they would properly evaluate the question of do they actually need to send those?
coldtea 3y ago
That's an added bonus to the user in most cases!

vbezhenar 3y ago

While it's better than storing emails in clear-text, nobody uses vvkcbrxrsewf@gmail.com. Brute-forcing emails is going to be pretty effective. And if you have another e-mail database (which are plenty available in the open wild), I bet that success rate will be huge. I like Apple's approach to generating random throwaway emails.

kaba0 3y ago
You don’t have to use the same salt for each email, right? You can hash each email with a separate, random salt and “brute force” upon password recovery. That way while individual emails can still be restored, you can’t easily get a database of emails to mass-spam, which is the point (emails are not really private completely, anyway). I also like apple’s method, but it is not either-or.

bloak 3y ago

This is probably worth doing, but one should be aware that a typical e-mail address does not contain enough entropy to not be guessable offline. Perhaps someone should deliberately leek a bogus database that contains the bcrypt hash of davey.jones.490@well-known-email-provider.com and see if that account starts receiving spam ... probably it won't. There is (almost certainly) no associated e-mail account, but the following is the SHA-256 hash of firstname.lastname.threedigits, something like "davey.jones.490". I'm half-expecting someone to reply with the solution, though I think there are about 36 bits of entropy in my choice: b8b6395265714064afb525f37e9969a7dbf09a4a2afa28812e917580be2dc667