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

111–120 of 181 posts

Re: You might not need to store plaintext email addresses

#111

Post by Piskvorrr »

naniwaduni wrote: post #91
Piskvorrr wrote: post #43

Earlier quoted context omitted.

By that logic, \.[a-z]{2,4}$ is still the correct way to match the TLD of an e-mail: "meh, it's obviously wrong, but everyone has to adapt."

Pretty close to true in practice, actually. Yes, some of us have funky domains that we take email at, but it's not like we don't have backup plans.

"Funky"? These things are two decades old by now. There have been multiple generations of communication protocols since this became standard - and yet still people consider this some weird aberration, even the 4-letter TLDs.

Indeed, fallback is still necessary - but it doesn't follow "meh, just go back to the 3-letter maximum, because a lot of people still live in 1999."

Re: You might not need to store plaintext email addresses

#113

Post by benlivengood »

wccrawford wrote: post #80
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?

I think the others are missing the fact that if you use the same salt for every row, it's less secure. So you'll be storing the email more securely, but still not as securely as you should be storing the password. To do it any more securely would require pulling up every single record for its salt, and hashing the login with that salt and checking it. It's virtually impossible at any real scale.

It's pretty scalable. 10 billion email addresses times 16+32+4 bytes of salt, SHA512/256, and ID is 520GB of RAM; available in a single (big) machine and searchable in under a second with a few cores.

Shard it into multiple machines for higher QPS.

Re: You might not need to store plaintext email addresses

#114

Post by naniwaduni »

Piskvorrr wrote: post #111
naniwaduni wrote: post #91

Earlier quoted context omitted.

Pretty close to true in practice, actually. Yes, some of us have funky domains that we take email at, but it's not like we don't have backup plans.

"Funky"? These things are two decades old by now. There have been multiple generations of communication protocols since this became standard - and yet still people consider this some weird aberration, even the 4-letter TLDs. Indeed, fallback is still necessary - but it doesn't follow "meh, just go back to the 3-letter maximum, because a lot of people still live in 1999."

I have a 3.2 domain on a ccTLD and even that gets shot down regularly enough that I wouldn't consider using it as a primary address. There should be no excuse for that, ccTLDs are older than a good chunk of the people writing the code excluding them, and yet here we are.

Dealing with systems in the wild sucks.

Re: You might not need to store plaintext email addresses

#115

Post by speedgoose »

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…

You could compute a very slow hash on the client, using bcrypt or argon2id. Then your attack is still possible but a bit more expensive.

Re: You might not need to store plaintext email addresses

#116

Post by robertlagrant »

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.

> any serious/useful service

Sigh.

Re: You might not need to store plaintext email addresses

#117

Post by danaris »

trengorilla wrote: post #68
Hitton wrote: post #35

Earlier quoted context omitted.

They won't forget the email, but they might easily forget with which email they registered (happened to me).

How many e-mails could you possibly have that makes trial and error not a good solution in this scenario?

Well, first of all, I have 5 email accounts that I regularly use.

One of those uses multiple domains (it's an iCloud account that I registered way back in the iTools days, so it supports @mac.com, @me.com, and @icloud.com....possibly even @itools.com, not sure about that one).

I regularly use a + extension to the addresses that support it when I'm signing up somewhere that I don't 100% trust, and that allows arbitrary additions to the address. And I don't always remember what version of a site's name I will have used (eg, user+hn@example.com, user+hackernews@example.com, user+ycombinator@example.com, etc).

I recognize that I'm an outlier, but trial and error is completely infeasible in this scenario.

Re: You might not need to store plaintext email addresses

#118

Post by cortesoft »

cm2187 wrote: post #18
danielskogly wrote: post #11

Earlier quoted context omitted.

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.

You cant, really... bcrypt hashes are not consistent... you run bcrypt on the same email, you are going to get two different hashes. You can't search your DB for the matching hash, you would have to iterate through every entry to compare.

Re: You might not need to store plaintext email addresses

#119

Post by [deleted] »

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.

[deleted]

Re: You might not need to store plaintext email addresses

#120

Post by kordlessagain »

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, or in fact no need to email users if they aren't using the system.

Further, if a "password recovery" flow is modified slightly, it can be repurposed for password-less logins by using strong tokens sent to user email, as they request them. A simplified 2FA flow can be established as well, where a token is texted the user after verifying email address. A second layer of security to texting tokens can be achieved using Google Authenticator.

To use such a system, the user will need to be OK with sending their email address each time they need email from the system AND be OK with having their phone handy to login. Of course not every use case requires security, or can be used with this proposed security system.

Post reply on HN