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

91–100 of 181 posts

Re: You might not need to store plaintext email addresses

#91

Post by naniwaduni »

Piskvorrr wrote: post #43
gpvos wrote: post #24

Earlier quoted context omitted.

True. But since so many websites (e.g. all aviation companies I've encountered) case-smash the LHS of the email address and can get away with it since all other email software has had to adapt, this is a rather minor concern by now.

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.

Re: You might not need to store plaintext email addresses

#92

Post by DarkWiiPlayer »

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…

If extortion is a possibility, use a separate email address. This is still a good extra layer of protection though.

Re: You might not need to store plaintext email addresses

#93

Post by ryanlol »

cm2187 wrote: post #86
ryanlol wrote: post #66

Earlier quoted context omitted.

This is not a reasonable use case for rainbow tables.

Why? You can churn sha256 hashes pretty quickly. There are probably less email addresses out there than there are passwords.

Why would you build a rainbow table you’re only going to use once? You’d just use hashcat for this.

Re: You might not need to store plaintext email addresses

#94

Post by jmnicolas »

markvdb wrote: post #49

> Earlier this year, when I went from having only Facebook-login [...] to allow registrations with email and password, one of my concerns was how to implement this is a way that protects the data and privacy of my users. Any privacy effort is laudable. Then again, if you're serious about protecting your users' data and privacy, Facebook login is the elephant in the room.

Why would you go to the trouble of not enabling Facebook login (as long as you provide other logins methods of course)? If someone is using Facebook & Facebook login they clearly don't mind being tracked by Facebook.

I don't have a FB account fwiw.

Re: You might not need to store plaintext email addresses

#95

Post by conception »

jmnicolas wrote: post #94
markvdb wrote: post #49

> Earlier this year, when I went from having only Facebook-login [...] to allow registrations with email and password, one of my concerns was how to implement this is a way that protects the data and privacy of my users. Any privacy effort is laudable. Then again, if you're serious about protecting your users' data and privacy, Facebook login is the elephant in the room.

Why would you go to the trouble of not enabling Facebook login (as long as you provide other logins methods of course)? If someone is using Facebook & Facebook login they clearly don't mind being tracked by Facebook. I don't have a FB account fwiw.

To not enable Facebook greater power?

Re: You might not need to store plaintext email addresses

#97

Post by stjo »

dastx wrote: post #83
stjo wrote: post #78

I admire your dedication to keeping your users data secure, anonymous and private. > For Wishy.gift I use SHA512 with a fixed salt Just a FIY in case you don’t know: if you want to allow different accounts with the same email, in case of a data breach it would be obvious by the duplicate hash this has occurred. Salting with a different nonce for every row is not much harder and would protect in that case.

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.

Re: You might not need to store plaintext email addresses

#98

Post by feoren »

inopinatus wrote: post #29
laszlokorte wrote: post #25

Earlier quoted context omitted.

But wouldnt the user face this issue all the time if they have a case sensitive mailbox but type their own address in the wrong case? So the assumption may be that a user with a case sensitive mail box is used to typing in the correct address?

No — many accounts aren’t created by the people that use them, and in any case we shouldn’t be relying on correct repeated string input and then blaming the user for a fulfilment process failure due to a typo from hours ago that we silently accepted at the time, and (worse) we can’t even distinguish between a capitalisation error and a discontinued recipient, even if it was previously verified. As designers/developer…

Wait a second. Back up. Let's be clear here: the case you are talking about is the user entering their own email address incorrectly, and you're saying we as designers/developers should make a system that knows this and sends it to the correct email? What? Huh? If Person@place.com and person@place.com are two different recipients, how the hell is my application supposed to know which one you actually mean!?

Re: You might not need to store plaintext email addresses

#99

Post by cblconfederate »

mischanix wrote: post #71

The more important takeaway from this article for me is that sites should be hashing the Facebook user ID, since it's often far more personally-identifiable information than an email address.

Id is already hashed per-app from facebook's side

Re: You might not need to store plaintext email addresses

#100

Post by adrianmonk »

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 does not have the prerogative to decide this, what rule prevents them? (And if there is such a rule, can you rely on it being enforced?)

Post reply on HN