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?
[deleted]
You might not need to store plaintext email addresses
41–50 of 181 posts
Re: You might not need to store plaintext email addresses
#42You 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?
Yes, exactly as you would do to check for an email address match.
Re: You might not need to store plaintext email addresses
#43This 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…
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."
Re: You might not need to store plaintext email addresses
#44Earlier 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…
> No — many accounts aren’t created by the people that use them
Can you elaborate on this? I can only think of 2 examples, but neither seem like good ones:
1- someone holds power of attorney over someone else, and register an account (email account?) in their name. But if there's PoA involved, the 2nd person isn't (probably ?) able to manage an email account on their own, so this doesn't seem a meaningful distinction to worry about. (though if it's not an untreatable condition, it's possible that they might resume using their email account themselves, I guess)
2- the account is created by your ISP when you register, and they "helpfully" choose a username for you. So from this point of view, you didn't truly "create the account"
Re: You might not need to store plaintext email addresses
#45In 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.…
Is that generalizaion true for other forms of data theft too? I feel that way about some wrongly public s3 buckets and document leaks.
Sure if you encrypt with an application-level key it makes it harder for any adversary to use your data, as he/she will need to not only get access to your data but also obtain the encryption key to do anything with it.
Encrypting data like this is easy and can drastically reduce your attack surface.
Re: You might not need to store plaintext email addresses
#46Earlier quoted context omitted.
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…
> No — many accounts aren’t created by the people that use them Can you elaborate on this? I can only think of 2 examples, but neither seem like good ones: 1- someone holds power of attorney over someone else, and register an account (email account?) in their name. But if there's PoA involved, the 2nd person isn't (probably ?) able to manage an email account on their own, so this doesn't seem a meaningful distinction…
3- Work e-mail is usually created by IT and users have no influence over it.
Re: You might not need to store plaintext email addresses
#47Earlier quoted context omitted.
As per the article, you only send them when the user requests an action, and ask them for their email at that time
Oh. I would be pretty annoyed if I had to re-enter my email address every time I perform an action that sends out a transactional email...
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.
Re: You might not need to store plaintext email addresses
#48Earlier quoted context omitted.
Using something like bcrypt would definitively be better, but considering that the email is the identifier, I would have no way of retrieving the correct hash to check it against, so the salt must be fixed to allow for lookups. I'm currently using SHA512 with a fixed salt. If someone gains access to only the database and not the salt, the emails are well protected. If someone gains access to both, then it's true that…
Use the password as the salt. Still need a fixed salt but that should help.
Doesn't that break account recovery requests?
Re: You might not need to store plaintext email addresses
#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.
Re: You might not need to store plaintext email addresses
#50This 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…
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.