That’s easy to do. You just check that the username exists. If someone enters a wrong username/password pair, you can still check that the username exists, but how do you know that the user intended to log in with that username? You would also have to check every other username to see if the password matches, and that can’t be done with a simple search because you need to compute a different hash for each user you check. Then if the username exists and the password also happens to match someone else’s password, then what do you report? Should you even report it? Because doing so reveals that someone had that specific password, and if the list of usernames is publicly available (which they often are, or could become public through a leak of some sort), then you can brute force over a small set of usernames to match them up.
I was having a chat about this with a UX guy. His argument for using a similar flow was that the username/email will have to be validated at the point of registration anyway so you might as well make it easier for the user when the email is wrong. I couldn’t really refute this logic.
If you throttle both login and registration, then surely the risk is minimised while keeping the user happy?
You see the registration problem in so many places. If the username is an email, the proper way to validate it without revealing if an account exists is to accept any email address and if it already exists say that in the registration email you would send anyway. With the appropriate throttling if needed.
Compared to login or password reset, you rarely see the email validate before register flow, especially for mobile apps etc. That makes it pretty hard to make the case that this needs to be actioned from a security perspective when even the big companies are not following it either.
I pretty much always recommend throttling. It’s a very low severity issue generally, but of course it depends on the product. There might be some products where it is a very big deal
Being able to determine if a username is valid without a valid password is a security flaw
Even something as simple as taking longer to validate the password when the username is a valid one can also lead to user enumeration
I keep hearing that, yet the websites will gladly tell you that the username is taken when trying to register
There are also a lot of websites where you first just enter a username and only when that is valid they ask for a password
That’s easy to do. You just check that the username exists. If someone enters a wrong username/password pair, you can still check that the username exists, but how do you know that the user intended to log in with that username? You would also have to check every other username to see if the password matches, and that can’t be done with a simple search because you need to compute a different hash for each user you check. Then if the username exists and the password also happens to match someone else’s password, then what do you report? Should you even report it? Because doing so reveals that someone had that specific password, and if the list of usernames is publicly available (which they often are, or could become public through a leak of some sort), then you can brute force over a small set of usernames to match them up.
I was having a chat about this with a UX guy. His argument for using a similar flow was that the username/email will have to be validated at the point of registration anyway so you might as well make it easier for the user when the email is wrong. I couldn’t really refute this logic.
If you throttle both login and registration, then surely the risk is minimised while keeping the user happy?
You see the registration problem in so many places. If the username is an email, the proper way to validate it without revealing if an account exists is to accept any email address and if it already exists say that in the registration email you would send anyway. With the appropriate throttling if needed.
Compared to login or password reset, you rarely see the email validate before register flow, especially for mobile apps etc. That makes it pretty hard to make the case that this needs to be actioned from a security perspective when even the big companies are not following it either.
I pretty much always recommend throttling. It’s a very low severity issue generally, but of course it depends on the product. There might be some products where it is a very big deal