You can provide a more helpful error message by explicitly informing the user that the username they typed exists but they haven't offered the correct password for it.
Unless the site searches to find out which username the entered password actually corresponds to (which is a whole new, terribly dangerous, can of worms), it can't do better than that
Because any malicious player can easily check whether usernames exist, so hiding that data point is not much good for security.
> You can provide a more helpful error message by explicitly informing the user that the username they typed exists but they haven't offered the correct password for it.
The parent poster already addressed that though:
“If you mistype your username, you might have entered another, existing username. Just telling the user 'wrong password' will mean they are less likely to check that the username was correct.”
If you inform the user the username they typed exists, the chance of them not thinking about double-checking they didn’t mistype their own username increases.
"telling the user that the username they typed exists, but they haven't offered the correct password for it" - is extremely different from Just telling the user 'wrong password'. It's different because it provides more information
>If you inform the user the username they typed exists, the chance of them not thinking about double-checking they didn’t mistype their own username increases.
That seems to be a user problem first of all, because it's based on the user's mistaken belief about the uniqueness of usernames. If possible, it would be best to help the user understand this.
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.
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.
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.
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.
Unless the site searches to find out which username the entered password actually corresponds to (which is a whole new, terribly dangerous, can of worms), it can't do better than that
Because any malicious player can easily check whether usernames exist, so hiding that data point is not much good for security.