Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You might not need to store plaintext email addresses

blog.klungo.no

Post reply on HN
Print view View original

11–20 of 181 posts

Re: You might not need to store plaintext email addresses

#11

Post by danielskogly »

cm2187 wrote: post #5

Good points. Though given how many emails have been leaked already, not sure sha256 with fixed salt achieves much. One can build a rainbow table with that salt fairly quickly. You might as well use bcrypt, scrypt and co.

Using something like bcrypt would definitively be better, but considering that the email is the identifier, I would have no way of retrieving the correct hash to check it against, so the salt must be fixed to allow for lookups.

I'm currently using SHA512 with a fixed salt. If someone gains access to only the database and not the salt, the emails are well protected. If someone gains access to both, then it's true that they could build a rainbow table to check if a given email exists in the database. What they _can't_ do is easily use all the emails in the database for spam/phishing/etc.

Either way, I'd argue it's better than nothing :)

Re: You might not need to store plaintext email addresses

#12

Post by inopinatus »

This scheme struggles in the face of email address case folding.

At the protocol level, email addresses are case-folded on the RHS but case-sensitive on the LHS. So it’s crucial that LHS case is preserved by delivery systems. Unfortunately most users then treat them as folded on both. So you can successfully verify one variant, store the downcased hash, and it’ll subsequently match but delivery bounces. Or, hash the exact original input but have many baffled users unable to access their accounts. Neither is a good outcome.

This is not an edge behaviour either, I have tons of users that mix up their email capitalisation from day to day.

Re: You might not need to store plaintext email addresses

#13

Post by opk »

webmobdev wrote: post #3

It's a good idea to protect user privacy. One drawback I can think of storing a hashed email is - What if the user forgets the username / email id and wants to know it? (This is a common use case). In such a case you have to collect additional unique data to help the user gain access to their account, but that defeats the original purpose - to protect user privacy.

People often forget usernames but not so often e-mails. The e-mail is usually the primary/only means of identifying users anyway so you're not going to provide it back on request anyway.

Re: You might not need to store plaintext email addresses

#14

Post by jeromenerf »

Storing email feels like a no-brainer for a system that needs to send messages to its customers. Some prefer phone numbers, which maybe provide stronger guarantees while being maybe not as long lasting.

As an individual, the issue is that "anon" or "throw-away" emails are not that commoditized. I heard that "login with Apple" meant to provide an email proxy, hiding your real email, but I have not seen it deployed, except on Reddit. As good as it can be, it’s Apple only.

I can always wildcard on a domain I rent and use klingo@domain as a mean to compartment identifiers but it is not low maintenance.

Still, it feels better that "login with faang".

Re: You might not need to store plaintext email addresses

#15

Post by BlackFly »

Vanit wrote: post #2

To support: Hey, I closed my Facebook account and would like you to delete my data for me? Oh...

There is either Personally Identifiable Information, or there is not.

If there is then identity can be confirmed and the account deleted.

If there is not then there is nothing that needs to be deleted.

Re: You might not need to store plaintext email addresses

#16

Post by toper-centage »

inopinatus wrote: post #12

This scheme struggles in the face of email address case folding. At the protocol level, email addresses are case-folded on the RHS but case-sensitive on the LHS. So it’s crucial that LHS case is preserved by delivery systems. Unfortunately most users then treat them as folded on both. So you can successfully verify one variant, store the downcased hash, and it’ll subsequently match but delivery bounces. Or, hash the…

Phone keyboards love to autocapitalize things. Also, once the keyboard. Memories your email as capitalised, it will sometimes autocorrect it.

Re: You might not need to store plaintext email addresses

#17

Post by opk »

inopinatus wrote: post #12

This scheme struggles in the face of email address case folding. At the protocol level, email addresses are case-folded on the RHS but case-sensitive on the LHS. So it’s crucial that LHS case is preserved by delivery systems. Unfortunately most users then treat them as folded on both. So you can successfully verify one variant, store the downcased hash, and it’ll subsequently match but delivery bounces. Or, hash the…

No it doesn't, convert the case when generating the hash – think of it as part of the hash function. But leave the case unchanged from whatever the user entered for any steps that involve sending an e-mail to the address.

Re: You might not need to store plaintext email addresses

#18

Post by cm2187 »

danielskogly wrote: post #11
cm2187 wrote: post #5

Good points. Though given how many emails have been leaked already, not sure sha256 with fixed salt achieves much. One can build a rainbow table with that salt fairly quickly. You might as well use bcrypt, scrypt and co.

Using something like bcrypt would definitively be better, but considering that the email is the identifier, I would have no way of retrieving the correct hash to check it against, so the salt must be fixed to allow for lookups. I'm currently using SHA512 with a fixed salt. If someone gains access to only the database and not the salt, the emails are well protected. If someone gains access to both, then it's true that…

Sorry, I missed the point about it being the identifier.

Though technically you can still use the bcrypt hash as your identifier, unless it has to be correlated to an external source of emails.

Re: You might not need to store plaintext email addresses

#19

Post by inopinatus »

opk wrote: post #17
inopinatus wrote: post #12

This scheme struggles in the face of email address case folding. At the protocol level, email addresses are case-folded on the RHS but case-sensitive on the LHS. So it’s crucial that LHS case is preserved by delivery systems. Unfortunately most users then treat them as folded on both. So you can successfully verify one variant, store the downcased hash, and it’ll subsequently match but delivery bounces. Or, hash the…

No it doesn't, convert the case when generating the hash – think of it as part of the hash function. But leave the case unchanged from whatever the user entered for any steps that involve sending an e-mail to the address.

That is what produces the first failure mode described, viz. bouncing email, when delivering to a case-sensitive mailbox.

Re: You might not need to store plaintext email addresses

#20

Post by cpach »

danielskogly wrote: post #6
Vanit wrote: post #2

To support: Hey, I closed my Facebook account and would like you to delete my data for me? Oh...

You're right that could be an issue, but hopefully anyone who registered via Facebook will take care to add an email/password to their account and disconnect Facebook before they delete their Facebook account.

I’m not sure I would trust all users to keep that in mind.
Post reply on HN