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 might not need to store plaintext email addresses
81–90 of 181 posts
Re: You might not need to store plaintext email addresses
#82> 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.
Re: You might not need to store plaintext email addresses
#83I 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.
Re: You might not need to store plaintext email addresses
#84Earlier 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.
Re: You might not need to store plaintext email addresses
#85Re: You might not need to store plaintext email addresses
#86Good 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.
Re: You might not need to store plaintext email addresses
#87The 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
#88One 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.
Shared/public devices are not considered secure at all.
Re: You might not need to store plaintext email addresses
#89Earlier 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?
ie +@gmail.com
That tag could be anything or everything.
Re: You might not need to store plaintext email addresses
#90Don't forget to NOT store email server logs either. ;) Otherwise this exercise is kinda pointless.
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.