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

121–130 of 181 posts

Re: You might not need to store plaintext email addresses

#121

Post by simcop2387 »

adrianmonk wrote: post #100
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…

I thought email addresses were case folded on the right hand side and site dependent on the left hand side. The right hand side is more or less forced by the rules of DNS. As for the left hand side, if I run the email for a site, can't I decide whether to deliver ABC@ and abc@ both to the same mailbox or to different mailboxes? And can't someone else make a different decision for their site? If a site administrator d…

site dependent means that when given an address you must treat the lhs as case sensitive. To do otherwise will mean that you've potentially broken the address and can no longer properly use it.

Re: You might not need to store plaintext email addresses

#122

Post by NiceWayToDoIT »

stjo wrote: post #97
dastx wrote: post #83

Earlier quoted context omitted.

How would you check for duplicate entries if you use a different salt per entry?

Check every previously generated salt with the currently received email for collision.

Lets imagine that a@exam.com and b@exam.com have same hash, so you use different salt so that they are different. How do you know which one is which? Which salt belongs to what email?

Re: You might not need to store plaintext email addresses

#123

Post by crazygringo »

Sidenote, but I find this post maddening to understand, because the author seems to be using the word "e-mail" to mean both "e-mail address" and "e-mail message", and then uses ambiguous pronouns to boot:

> In conclusion, if you only use emails for transactional emails, you might be able to only store hashed versions of them.

HUH?

The most obvious way to interpret this sentence is as storing hashed versions of transaction e-mail messages. Which makes no sense and isn't what the author means, but wow this is some confusing writing.

Re: You might not need to store plaintext email addresses

#124

Post by toyg »

gregoriol wrote: post #104

This would not work for any serious/useful service: e-mails are not only for marketing, there are many good reasons to send one like (user requested) notifications, invoicing, ... and also screw-ups! If your service had a problem (security, broken data, invoicing again, long downtime, ...), you better contact your users before they find out on hackernews.

Even just a very thin encryption layer would probably do a decent job. Attackers are typically going at it from an infrastructure perspective: they make a hole, poke around for basic configuration info, locate the database, and siphon it out. They may or may not have enough time and knowledge to reverse-engineer a basic column-specific symmetric scheme.

The only drawback is that such scheme must then be made available to any system that consumes the database, possibly from multiple languages.

Re: You might not need to store plaintext email addresses

#125

Post by AndrewStephens »

identity0 wrote: post #103
AndrewStephens wrote: post #87

This is a clever idea but limited in applicability. It is probably fine for a low security web app or game, but could still leak personal information if the db got hacked. The problem is that the salt has to be the same for each record and that emails present a limited search space. Imagine I stole the database for blackmailable-fetish.com. All the emails are hashed with the same salt so I can brute-force the followi…

Not sure why you're bringing this up. If you stored them in plaintext it gives hackers 100% of the emails with zero effort required.

True, but I maintain that if you are worried that hackers may steal your email database then a much better approach is to encrypt the emails with an external key.

Re: You might not need to store plaintext email addresses

#126

Post by minitech »

identity0 wrote: post #103
AndrewStephens wrote: post #87

This is a clever idea but limited in applicability. It is probably fine for a low security web app or game, but could still leak personal information if the db got hacked. The problem is that the salt has to be the same for each record and that emails present a limited search space. Imagine I stole the database for blackmailable-fetish.com. All the emails are hashed with the same salt so I can brute-force the followi…

Not sure why you're bringing this up. If you stored them in plaintext it gives hackers 100% of the emails with zero effort required.

Because it gives the false appearance of security. With this scheme, you always need to act as if the e-mail addresses are plaintext anyway. It should not be used.

Re: You might not need to store plaintext email addresses

#127

Post by kevincox »

kordlessagain wrote: post #120
gregoriol wrote: post #104

This would not work for any serious/useful service: e-mails are not only for marketing, there are many good reasons to send one like (user requested) notifications, invoicing, ... and also screw-ups! If your service had a problem (security, broken data, invoicing again, long downtime, ...), you better contact your users before they find out on hackernews.

Plaintext email could be stored client side in a cookie and may be submitted to the server when use of the email is required, and if it validates. If the user logs in and the site is down, a backup system could email them about the issue. This is the backup system, primary systems are down. Please contact support if you need more information. No need to email users who aren't using the system currently about downtime…

But how do you contact users if they aren't on the site? What if you have a data breach and need to notify them or need to remove their account because they are inactive and want to give them a heads up.

Re: You might not need to store plaintext email addresses

#128

Post by pc86 »

crazygringo wrote: post #123

Sidenote, but I find this post maddening to understand, because the author seems to be using the word "e-mail" to mean both "e-mail address" and "e-mail message", and then uses ambiguous pronouns to boot: > In conclusion, if you only use emails for transactional emails, you might be able to only store hashed versions of them. HUH? The most obvious way to interpret this sentence is as storing hashed versions of transa…

"Most obvious" only if you make the conscious decision to ignore the context of the entire article, maybe. The author isn't a native English speaker.

Re: You might not need to store plaintext email addresses

#129

Post by wtetzner »

akmittal wrote: post #51
raziel2p wrote: post #39

You use email+password for login. Does this mean that on every login attempt, you iterate through every row in the database to check for a hash match?

hash the email first and then check for same hash in db.

But don't you need to know which salt to use?

Re: You might not need to store plaintext email addresses

#130

Post by danielskogly »

crazygringo wrote: post #123

Sidenote, but I find this post maddening to understand, because the author seems to be using the word "e-mail" to mean both "e-mail address" and "e-mail message", and then uses ambiguous pronouns to boot: > In conclusion, if you only use emails for transactional emails, you might be able to only store hashed versions of them. HUH? The most obvious way to interpret this sentence is as storing hashed versions of transa…

Thank you for this! I realize now how confusing that is. An updated version should be up any second :)
Post reply on HN