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.
You might not need to store plaintext email addresses
71–80 of 181 posts
Re: You might not need to store plaintext email addresses
#72Earlier quoted context omitted.
Says who? Email addresses are case insensitive. If email software treats emails as case sensitive then it is broken. People have to write email addresses on paper forms, in all caps.
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't make it yours too.
Re: You might not need to store plaintext email addresses
#73Storing email feels like a no-brainer for a system that needs to send messages to its customers. Some prefer phone numbers, which maybe provide stronger guarantees while being maybe not as long lasting. As an individual, the issue is that "anon" or "throw-away" emails are not that commoditized. I heard that "login with Apple" meant to provide an email proxy, hiding your real email, but I have not seen it deployed, ex…
I use wildcards and they're extremely low maintenance. Literally no maintenance required since I set them up.
Steps to reproduce: 1. register a domain name 2. register that domain with your email service provider of choice (I use Protonmail) 3. create an email address on that domain 4. set that address up as a catch-all address for the domain 5. profit
Re: You might not need to store plaintext email addresses
#74That might be in breach of the GDPR. In the event of a personal data breach, you need to tell the data subjects about the breach [0]. You can’t just put a notice on your page, since someone might not be using your service any more, but you still have their data. And GDPR aside, it is very short-sighted to assume you will never ever need to e-mail users on your own. [0]: https://gdpr-info.eu/art-34-gdpr/
You comment was dead, I vouched for it as it's a valid assumption that you have to notice users on breach. But in this case, it seems like the following applies (34.3.A from your link):
> The communication to the data subject referred to in paragraph 1 shall not be required if any of the following conditions are met:
> 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 render the personal data unintelligible to any person who is not authorised to access it, such as encryption;
With emphasis on the "in particular those that render the personal data unintelligible". Since the email is no longer an email, it should not be counted as personal data, it's just random characters, and no notification needed.
IANAL, but that's how I understand it.
Re: You might not need to store plaintext email addresses
#75> 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
#76Earlier quoted context omitted.
On this website, this only happens for actions that require entering your email address anyway. > For every transactional email I need to send out - registration, account recovery, and email change verification - the user always initiates this by submitting their email, and it will at that time be available to the backend to perform the needed action.
So this only works if you only use the email as a username. No way to notify the user of things like ToS changes, security issues, notifications from the service, etc.
Some services don't have the desire (or need!) to send out generic service notifications.
For ToS changes, it's often enough to display them to the user when they first log in after the change. That's how many mobiel apps handle it already.
The security notification thing could be an issue though. Doesn't seem to be necessary per the GDPA but it's probably a good idea to communicate security breaches.
Re: You might not need to store plaintext email addresses
#77Earlier quoted context omitted.
You're right that could be an issue, but hopefully anyone who registered via Facebook will take care to add an email/password to their account and disconnect Facebook before they delete their Facebook account.
I’m not sure I would trust all users to keep that in mind.
I'm sure I would trust users to not keep that in mind. Most user's aren't very good an this stuff.
Re: You might not need to store plaintext email addresses
#78I 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
#79In 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.…
This kind of encryption-at-rest scheme becomes an absolute necessity when cryptographic secrets have to be stored, such as 2FA TOTP secret keys or recovery codes. Encrypting the email addresses and any Personally Identifiable Information on your users may also be a good practice, to limit which eyes can actually see the plaintext data (database provider, former developers without rotated credentials, an old backup le…
You could also use convergent encryption (https://www.vaultproject.io/docs/secrets/transit#convergent-...) to do this with only one field.
Re: You might not need to store plaintext email addresses
#80You 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.