4

When signing into websites or mobile applications, if an incorrect username/email or password is entered, you are almost always notified only that "the username or password is incorrect." Why is it common practice to do this, instead of tell the user specifically whether it is the username/email or password that is incorrect?

My guess is it is security-driven to some extent, but if so, how big of a difference is provided in threat protection by ambiguously telling the user that some part of the supplied credentials was incorrect?

I've had plenty of instances - particularly with older or less-frequently visited websites - where I have no idea whether the incorrect part is my email, my password, or both.

1
  • Sadly, on Windows-based systems, it's easy to find out which: try the same username 3 or 4 times, and if you get locked out, the username is valid; if you don't then it's not valid (this may have changed in the last couple years; I haven't investigated). Mar 4, 2016 at 19:55

3 Answers 3

7

This has been addressed at the IT Security Stack Exchange site.

It's a lot harder for an attacker to guess valid username-password combinations than just passwords. Once the existence of an account is confirmed, it can be targeted (perhaps with some outside research on sites like Facebook).

It's also a lot more convenient for web sites to return a generic authentication failure if they query the database for both parts of the user's credentials (username and password hash) at the same time, or if the authentication layer is opaque and just returns whether the user is legit.

In general, it's not good to reveal more information than necessary. Some attackers might want to grab the list of ("enumerate") users, perhaps for phishing.

Also, what if a user mistypes the username to produce a different user's name but gets its own password (not the other user's password) right? Then the message would say "wrong password" even though the mistake was actually in the username.

4
  • How is "if they query the database for both parts of the user's credentials at the same time" supposed to be read? To me it sounds like you are assuming the password is stored in clear.
    – kasperd
    Mar 4, 2016 at 18:45
  • @kasperd If the server did something like select * from users where username='USERNAME HERE' and passhash='COMPUTED HASH HERE', it would either get zero or one results, and it wouldn't know which was wrong if it got none. (Example from one of the answers on that Sec.SE question.)
    – Ben N
    Mar 4, 2016 at 19:04
  • 1
    That would be better than storing the password in clear. But a secure password hash involves a salt, which will be different for each user. So the password hash cannot be computed without first looking up the salt in the database.
    – kasperd
    Mar 4, 2016 at 20:06
  • @kasperd Nobody is assuming the password is stored in the clear. By "query data database for both parts of the user's credentials at the same time", it means there an an opaque layer that handles both the Username and Password at the same time. For example: string expectedHash = ExecuteScalar("select hash from users where username = :username") return ArgonBPufferCrypt.CheckPassword(expectedHash, suppliedPassword); If the database contains no matching user, the expectedHash is empty, and the CheckPassword function returns false. You don't know if it was because user or password.
    – Ian Boyd
    Jul 16, 2020 at 15:07
10

Your guess is correct. Specifying that the username is incorrect is a form of Sensitive Data Exposure. Using just the login form, an attacker could determine if a specific email address/username has an account on the website.

5
  • Correct. If the attack you want to protect against is random trial and error of both password and username, this makes cracking/guessing double so hard.
    – Jan Doggen
    Mar 4, 2016 at 20:11
  • 2
    I seem to be missing something, why couldn't an attacker simply check whether an account exists by attempting to create one with the same name through a registration page?
    – Andrew Sun
    Mar 4, 2016 at 20:18
  • @AndrewSun, that is also a common vector for exploiting this vulnerability, and there are ways to mitigate it. See here
    – heavyd
    Mar 4, 2016 at 20:22
  • @heavyd I don't see anything in that page that mitigates the discovery of usernames (Note: usernames, not e-mail addresses). For example, i can see a username here on SuperUser called heavyd. If we want to prevent the discovery of usernames, what would be a way to prevent me from trying to create a new account called heavyd?
    – Ian Boyd
    Jul 16, 2020 at 15:16
  • @IanBoyd, I don't think SuperUser is a good example to use in this case. Usernames here are public, so it doesn't make sense to protect against username enumeration. You would typically implement this protected on a non-public system. Its much easier to implement these protections when the username is the e-mail address, because with just a username you don't have direct out-of-band communication with a user. The post I linked to discusses these issues in the sections "Username enumeration and the impact on anonymity" and "Resetting via username versus resetting via email address".
    – heavyd
    Jul 16, 2020 at 16:14
3

It is purely security and privacy driven... The privacy aspect is since most people use usernames in common across multiple sites, confirming the username exists gives away that an individual has account on that system, which may or may not be significant depending on the site or user, but still gives away some private information. The security aspect is fairly straightforward, if you attempt authentication of random usernames and passwords, telling them the username is correct cuts down the possible combinations for hacking, greatly reducing the time and increasing the chances of the hack. There are other implications, but these are the most significant.

2
  • 1
    Knowing the username doesn't just cut the search space in half. Suppose there are 10^8 possible usernames and 10^20 possible passwords. If the attacker can never figure out whether a user exists, there are 10^28 pairs to try. Once an attacker knows a user exists, there are only 10^20 pairs left - a reduction of eight orders of magnitude. (The probability is slightly more complicated because the big search space will have more than one hit, but you get the idea.)
    – Ben N
    Mar 4, 2016 at 17:09
  • 1
    True, my math may be incorrect but in general I stand by my statement
    – acejavelin
    Mar 4, 2016 at 17:40

Not the answer you're looking for? Browse other questions tagged .