Easy fix: Don’t complain about existing emails, simply convert the signup into a password reset email and if usernames aren’t public don’t complain or even ask for one until a confirmation mail has been received.
Username or Email disclosure can be very bad for privacy.
This just delays disclosure. Eventually, the sign up is gonna fail because the username/email exists. Even if you push it later after an email.
Not necessarily. The signup could only continue with access to the targets email service. The attacker doesn’t know if the attack succeeded or not unless they have access to the email address. If that is the case, the entire point is moot anyway since you can click “reset password”.
Let’s say I’m an attacker. I sign up on lobste.rs at firstname.lastname@example.org, sign up works and I get a confirmation email. I then sign up on lobste.rs with the email email@example.com. Because your account exists already, I don’t get an email. The difference, even if it’s something not happening, tells me what I wanted to know.
Yeah but you don’t know if you get an email for firstname.lastname@example.org since you don’t have access to that account.
You wouldn’t get an email if the account existed or not.
I do know though. I know I didn’t get an email for email@example.com. That tells me just as much about the account’s existence if I had got the email.
If you get that mail that implies you have control over firstname.lastname@example.org, in which case the entire method doesn’t do anything. But it’s also not valid to say the entire method is therefore flawed.
You just gained access to my mail account, you can click “reset password”. Or signup for real. Or just check the emails in the archive folder.
If you do not have access to tscs37@gmail then you cannot tell if the email had signed up because you don’t get the email
Ah I see what you’re saying now. Yeah that might work, it wouldn’t work for sites that have usernames, users could only be identified/login with email addresses.
It can work with sites that have usernames, but only for display purposes.
So you can still be shown as “travisjeffery” or “ilikedeepthreads” or whatever rather than showing your email all over the place, but thats all it is - display text.
This also takes the step of validating that an email address is active during signup, instead of after signup, which is a huge win, in and of itself.
It tells you that somebody already registered that email address. It does not tell you if that somebody also has a lobsters account.
You didn’t get any email because you don’t control the email account to be able to check it.
Lobsters isn’t a good example for average case because it has a list of usernames. So, you can tell if the name is there. You might not know if it’s the target individual, though. Then, clicking on the profile may or may not tell you more about the individual. You can also social engineer users to find out identity information you might not get from a commercial service without more work and risk.
I do agree with you that it’s pointless to hide the username on a site where (a) you can see if it’s take and critically (b) username has something like email that uniquely identifies an individual. Other examples might be their Facebook or Twitter accounts. I’d still default on hiding it in the likely-reusable implementation of login since I can’t know ahead of time whether or not they’ll leak information like that. Secure by default.
If email address was used for login (and usernames only for display) there’d be minimal attack surface there.
This is definitely a good way to prevent those issues. For several times I thought about using this method on some projects.
http://stash.cool/ - the personal finance mobile tool. Digging deep into d3.js.
Working on Stash, the personal finance tool. Currently reading Tutfe and thinking about how to design the UI.