[capableweb]

It doesn't seem like the author is arguing that just because you can instead validate if the email exists on a platform via the signup page instead of the login page, the vague message can be removed, but rather that the signup page should remove the information leakage as well, so there is no leakage anywhere.

[selykg]

Depending on your particular service, there's a better alternative for not leaking the existing account. A service I worked on previously was super sensitive and we didn't want to leak the existence of an existing account. What we did instead was asked for the email on the first page of signup, we verified the email was active by sending an email and a link to continue signup. If they already have an account we'd inform them in that email that they already have an account.

This way, the attacker actually has to have access to the email in question to know that an existing account is present on the service.

If you do the whole signup process on a single page and validate the email there then yea, you're gonna have a rough time.

[joosters]

I think that the author is saying that it is very difficult not to disclose that a user exists, and so there is not much point obfuscating it. Validating an email address on signup is only one way to 'leak' usernames.

If you can obtain a user account on a system, then preventing checks for the existence of other users becomes much harder. e.g. if you have a login on a unix box, there are countless ways of discovering other usernames. Or a pathological case like reddit, where users have distinct URLs that are publicly visible.

Or a messaging system where you can 'friend' other users - if you allow friend requests, what do you do if someone tries to contact a mis-typed username? Do you inform them that the user doesn't exist, or silently pretend that their request is awaiting a response that will never come? That paranoia will lead to a worse user experience.

I think you can only really lock down the known user list on a very closed system, with few, trusted users, e.g. an admin control panel where you don't want to divulge who might have access to it in the first place. But that's a very different scenario to a service open to the public.

[michaelmior]

That was presented as an option, but explicitly not recommended.

> …you can make the signup process email based.…I don't recommend this, because of the context switches, though you can implement it.

[Xylakant]

practically all website that use an email as username nowadays require email confirmation, so already include the context switch. Because in the end, sending an email is the only way to verify that the email address is correct and you don't want an incorrect email address in your database if you rely on that communication channel.

Now, if you have accounts in places where email addresses are not required and usernames take the place, the calculus may change. But using the context switch as an argument here is just weak.