Live data from Hacker News

You might not need to store plaintext email addresses

blog.klungo.no

81–90 of 181 posts

Re: You might not need to store plaintext email addresses

#81

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

Re: You might not need to store plaintext email addresses

#82
post #75
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.

Its all about liability. With GDPR, you want to be compliant. Also see Schneier's 'data is a toxic asset' essay. Though I don't know about it being compliant I suppose Facebook Login (and other forms of SSO) shifts the reliability to Facebook.

Wouldn't the lack of means to contact all of your users, immediately and directly, create other compliance challenges? You would be unable to notify users of a data breech until their next login; former users might be left permanently in the dark. Similarly, being unable to push legally mandated notice of policy updates could be an impossible challenge. I can see how this proposed scheme could work day to day, but you would likely be well served to retain un-hashed emails in cold storage.

Re: You might not need to store plaintext email addresses

#83
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?

Re: You might not need to store plaintext email addresses

#84
post #17

Earlier quoted context omitted.

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.

Isn't this problem orthoganal to storing hashed email addresses? You'll always have access to the email address the user typed in when you want to send a transactional email so you can perform whatever sanitization needs to be done at that point. How does storing the email in plaintext get around issues involving sending emails to case-sensitive mailboxes?

Re: You might not need to store plaintext email addresses

#86
post #66
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.

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.

Re: You might not need to store plaintext email addresses

#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 following restricted space:

[top 200 first names][top 1000 surnames][digits from 0 - 999]@[top 5 email providers]

That would probably get me 75% of the emails - let the extortion games begin!

Re: You might not need to store plaintext email addresses

#88

One thing worth noting is that often, you don't even need to store passwords. If a user wishes to log in, you send them a link/code by email. That increases security dramatically, as most email services already have some more advanced protections built-in. You also don't have to worry about leaks that much, as there are just no passwords to be leaked.

Please don't do that. It makes me very angry when I'm trying to quickly get some information from a public/shared device and instead of getting logged in, I get a link on my device. (which I need to retype / send / ...) Most likely I don't care about the security of the account that much in that case. But my email login never goes anywhere close a device I don't own. Don't annoy users. Just let them log in.

To be fair, that scenario is increasing security.

Shared/public devices are not considered secure at all.

Re: You might not need to store plaintext email addresses

#89
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?

I tend to use aliases so I can filter/discover which exact service is perhaps selling my email.

ie +@gmail.com

That tag could be anything or everything.

Re: You might not need to store plaintext email addresses

#90
post #85

Don't forget to NOT store email server logs either. ;) Otherwise this exercise is kinda pointless.

... or if you do, make sure they are deleted pretty quickly afterwards (with logrotate or something comparable).

Having some logs in invaluable for debugging, but for example keeping them only for 14 days could be an acceptable compromise between debugability and privacy.

Post reply on HN