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

101–110 of 181 posts

Re: You might not need to store plaintext email addresses

#101

Post by TuringNYC »

mantap wrote: post #72
ajanuary wrote: post #52

Earlier quoted context omitted.

Says RFC 5321 [1]: "The local-part of a mailbox MUST BE treated as case sensitive." It _does_ recommend receivers treat it as case insensitive for maximum interoperability, so it is de facto insensitive, but something implementing it as case sensitive isn't broken. [1] https://tools.ietf.org/html/rfc5321

It does make it broken. Broken means not working. If your software refuses an email because it's in the wrong case then that software is broken. And quoting out of an RFC is not going to make users stop complaining. Email addresses are written i a variety of situations where preserving case is not possible. For instance on forms, or over the phone. If the IETF wants to ignore that then that's the IETF's problem, don'…

I think it is a fair point -- when a technical standard and/or convention so vastly disagrees with common user perception, perhaps the requirement should be broadened to account for both.

Re: You might not need to store plaintext email addresses

#102

Post by SahAssar »

medecau wrote: post #56
RobertoG wrote: post #10

Maybe this is not important in your user-case, but what if you have a database breach and you have to warm your users?

Article 34.3.a seems to disavow the data processor of such requirement. The communication to the data subject referred to in paragraph 1 shall not be required if any of the following conditions are met: (a) the controller has implemented appropriate technical and organisational protection measures, and those measures were applied to the personal data affected by the personal data breach, in particular those that rend…

I don't think hashing and encryption are considered equivalent in this case.

Re: You might not need to store plaintext email addresses

#103

Post by identity0 »

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.

Re: You might not need to store plaintext email addresses

#104

Post by gregoriol »

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.

Re: You might not need to store plaintext email addresses

#105

Post by raziel2p »

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.

Hah, when I wrote my comment above I didn't even consider the possibility of using the same salt everywhere.

I suppose the goal here is privacy, not information security, so it's okay.

Re: You might not need to store plaintext email addresses

#106

Post by renewiltord »

gfauchart wrote: post #81
ThePhysicist wrote: post #27

In most cases, encrypting sensitive information like e-mail addresses with a memory-resident key (e.g. injected using tools like Vault) in the application layer is a better strategy, at least if you need asynchronous access to that information (e.g. to send out weekly update e-mails). Most of the data leaks in the past were caused by compromised or misconfigured databases, not by compromised application server code.…

you need to reach your users in case of data breach, but what if you have zero “Personal Data” ? you could still hash the email I imagine

Well the hashed email is Personal Data. https://www.google.com/url?sa=t&source=web&rct=j&url=https:/...

Sorry for the Google link, I can't figure out how to copy the direct link on Android Chrome.

Re: You might not need to store plaintext email addresses

#107

Post by jimmyspice »

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 just do that anyway. I've seen spam email trying to extort people threatening to release indecent images of them (that they don't have. supposedly, they've been captured from the victims selfie cam).

In this case, you don't have to be accurate, you're just trying to call someones bluff, in the small case they've actually done said thing (and in addition believe you can prove it AND that payment will silence them)

Re: You might not need to store plaintext email addresses

#108

Post by jlcummings »

RobertoG wrote: post #10

Maybe this is not important in your user-case, but what if you have a database breach and you have to warm your users?

So far I haven’t seen a comment point this out or suggest similar, so let’s say that instead of trying to maintain an application level list of email addresses that is used in a breach (or for other reasons), rely on the exercising service (email) which by formerly sending a verification email, has a record of the destination at least in a log, and maybe during registration placed in a “verified member” list, all more or less managed within the mail service.

Re: You might not need to store plaintext email addresses

#109

Post by Piskvorrr »

scrollaway wrote: post #67
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."

You're trying to sound clever but it's not working, I don't think you understand what the logic actually is, if you are comparing those two. A lot of emails get casefolded no matter what. This is enough of an inconvenience that nobody in their right mind would operate a case sensitive mailbox you would be using for account signups.

A lot of people are still using that part of a regex no matter what - I still run into this regularly (and have been, for two decades now).

"There is some danger that common usage and widespread sloppy coding will establish a de facto standard for e-mail addresses that is more restrictive than the recorded formal standard."

This is EXACTLY it. Both in the local part, and in TLDs - nothing clever about people being too clever by half, and generating false negatives on their input side.

Re: You might not need to store plaintext email addresses

#110

Post by benlivengood »

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…

Depending on the size of the user database it might be cheap enough to try all random-salts+hashed emails (if it fits in RAM it's probably cheap enough).
Post reply on HN