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?
hash the email first and then check for same hash in db.
You might not need to store plaintext email addresses
51–60 of 181 posts
Re: You might not need to store plaintext email addresses
#52This 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.
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.
Re: You might not need to store plaintext email addresses
#53> 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.
I fully agree, so when I released the update with email/password registration, I also stopped allowing new account creations via Facebook. Now it's only supported for login for legacy reasons, and those users can disconnect their Facebook account after connecting an email.
Re: You might not need to store plaintext email addresses
#54Sounds unnecessary complicated for no real benefit with issues along the road.
And it does feel weird to use Facebook in this example.
If you don't care for an email address, and you are using the login only for maintaining that list, use an permalink. Thats probably easier and better.
One permalink for edit, one permalink for viewing.
Re: You might not need to store plaintext email addresses
#55One 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.
Re: You might not need to store plaintext email addresses
#56Maybe 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 render the personal data unintelligible to any person who is not authorised to access it, such as encryption;
Re: You might not need to store plaintext email addresses
#57Earlier quoted context omitted.
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.
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.
Re: You might not need to store plaintext email addresses
#58Sounds unnecessary complicated for no real benefit with issues along the road. And it does feel weird to use Facebook in this example. If you don't care for an email address, and you are using the login only for maintaining that list, use an permalink. Thats probably easier and better. One permalink for edit, one permalink for viewing.
Facebook is only mentioned in the context of how I did things previously, before I implemented the email/password registration.
Re: You might not need to store plaintext email addresses
#59Huh, considering the case (& Unicode) issue (that I wasn't aware of !), shouldn't using email addresses as logins be considered bad practice ?
Re: You might not need to store plaintext email addresses
#60One 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.