The website doesn't always know which one you got wrong, and assuming one way or the other just makes things worse.
That's a good point, but there is no way the website can detect that situation, and I suspect it is much less likely than typing your correct username and the wrong password.
> The website doesn't always know which one you got wrong, and assuming one way or the other just makes things worse.
If the website doesn't know which one you got wrong, then yes, it should just tell you so; the article is not arguing otherwise.
Why? The website can salt, hash, match your password against all the hashed passwords for all the closest usernames within a certain edit distance.
Not saying this is a good idea security-wise, but it's not impossible.
This is not a very big problem security-wise. It makes online attacks slightly easier, but you can limit online attempts pretty easily. It doesn't affect offline attempts at all.
The downvotes dheera got are extra inappropriate because they were just saying it's doable.
That could allow “bad username” if you got the password right!
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 make the signup process email based.…I don't recommend this, because of the context switches, though you can implement it.
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.
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.
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.
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.
Thank you for your comment, but I don't agree
"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.