112

Lets say a user is logging into a typical site, entering their username and password, and they mistype one of their inputs. I have noticed that most, if not all, sites show the same message (something along the lines of, "Invalid username or password") despite only one input being wrong.

To me, it seems easy enough to notify the user of which input was wrong and this got me wondering why sites do not do it. So, is there a security reason for this or is it just something that has become the norm?

Improve this question
20
  • 10
    For websites which offer a different way to see if a user exists, there is no security gain. They're just being annoying.
    – CodesInChaos
    Commented Jul 30, 2012 at 11:47
  • 30
    One totally non-security related reason is that it's possible the provider doesn't know which was wrong. E.g. if [email protected] mistypes his user name as [email protected] and there really is another user [email protected].
    – Mark Beadles
    Commented Jul 30, 2012 at 14:24
  • 13
    1. [email protected] mistypes id as "[email protected]" and types his (own) password correctly 2. A user BOB2 exists in the user store 3. logon entity thinks that BOB2 mistypes his password, when in reality BOB1 mistyped his username.
    – Mark Beadles
    Commented Jul 30, 2012 at 14:54
  • 6
    I would agree that it is for security reasons. I don't know any website where the username is supposed to be secret. As an example: Google does the "Username and/or Password Invalid" thing but you can still find out if a username exists (by trying to register it).
    – João Portela
    Commented Jul 30, 2012 at 18:57
  • 8
    @JoãoPortela, but the creation screen is guarded by captcha. Thats the difference.
    – user606723
    Commented Jul 30, 2012 at 20:18

11 Answers 11

Reset to default
132

If a malicious user starts attacking a website by guessing common username/password combinations like admin/admin, the attacker would know that the username is valid is it returns a message of "Password invalid" instead of "Username or password invalid".

If an attacker knows the username is valid, he could concentrate his efforts on that particular account using techniques like SQL injections or bruteforcing the password.

Improve this answer
13
  • 9
    Doesn't this assume that figuring out the username by other means is as difficult as guessing the password? As @CodesInChaos points out, if you can validate the username by other means, it's really pointless to obfuscate it in this one interface.
    – kojiro
    Commented Jul 30, 2012 at 12:55
  • 3
    @lazfish but then you could just show the usual "username or password wrong" message and call it a day, it's pretty much the same.
    – Mahn
    Commented Jul 30, 2012 at 20:12
  • 8
    He can just attack the sign up page, silly.
    – Salman
    Commented Jul 31, 2012 at 1:25
  • 4
    Malicious user can find out if the username is taken as part of registration.. you would not allow two users to register with the same username. Therefore, obscuring the login failure message is meaningless.
    – Gajus
    Commented Mar 9, 2014 at 21:46
  • 2
    @Gajus not all websites give registration forms. In some SaaS websites admin needs to add users.
    – pinkpanther
    Commented Feb 14, 2017 at 8:55
26

As others have mentioned, we don't want you to know whether or not it was the username or password that was wrong so that we are not as susceptible to brute-force or dictionary attacks..

If some websites wanted to let their users know which one failed while still being in the green security-wise, they could implement "honeypot" usernames (such as Administrator, admin, etc.) that would alert website admins that someone is snooping around their website. You could even setup some logic to ban their IP address if they were to attempt to login with one of those "honeypot" usernames. I know one person who actually had a website and put in their source code an HTML comment such as "Since you keep forgetting Richard: Username: cheese Password: Burger123" near the login box with the intent to monitor any IP address that attempted to use that username/password. Adding monitoring logic like that is a lot of fun when you're developing a website.

Of course, logging invalid login attempts and adding appropriate logic to deal with those IP addresses works too. I know some would disagree with me, but depending on the type of website, I don't think it is too big of a deal to let the user know as long as you add additional security measures in preventing different kinds of attacks.

Improve this answer
4
  • 3
    I love the idea of the coded false username/password to more quickly identify hacking IP addresses.
    – David Navarre
    Commented Jul 30, 2012 at 14:06
  • 2
    +1 for the mention of honeypot usernames, though you should make absolutely sure legitimate users cannot create accounts with the same name as the honeypots!
    – Moses
    Commented Jul 31, 2012 at 0:00
  • 6
    Eh; some legitimate users may look at the html code for legitimate reasons (how's the form implemented; or is that an image?); and be like serious; there's a password in the page and just try it out.
    – dr jimbob
    Commented Jul 31, 2012 at 4:14
  • 1
    I don't see the value of the second and third paragraphs in relation to the question asked.
    – Adam Lynch
    Commented Aug 1, 2012 at 11:24
20

My favorite secure implementation of this is done by a bank I use. If I type in my username correctly, it will say "Welcome Jimbob!" and then prompts me to answer security questions (if I have never logged in from this browser on this computer), wait for me to answer the security questions correctly, and then will let me see my security image/caption and input my password. If I type in the wrong username, I will see something like "Welcome Bessie/Kareem/Randal!" where the displayed name is very uncommon — though you will always be the same name for a same username (I'm usually not sure between one or two usernames; and the wrong one consistently calls me Frenshelia). I assume its implemented as some sort of non-cryptographic hash applied to any inputted username that uniquely map to one username on a long list of fairly uncommon names. This lets legitimate users know if they typed in the wrong username (as even if you have an uncommon name like Bessie; its very unlikely that the wrong username you randomly guessed maps back to your specific uncommon name), without making it obvious to people trying to find random accounts that the username doesn't exist.

As an aside: I'm not particularly fond of the security questions/security image part, which seems to border on security theater. A sophisticated attacker doing a man-in-the-middle (MITM) attack (e.g., after installing fake certificates in your web-browser; and DNS/ARP spoofing to point yourbank.com to their IP address) could wait until you try logging into the site, then have an automated script sign in on their computer to the real site, get the security questions, display the chosen security questions back to you, send back the answers to the site themselves from their browser, wait to get the security image, serve back the security image to you, and then wait for you to input the password from their end at which point they use the password to log in as you and do malicious things. Granted the questions+image makes the process more difficult than having all the time in the world to collect all the security images for a variety of attacked usernames by turning it into an attack that must be done in real-time and possibly leaves a suspicious signature.

Improve this answer
2
  • 1
    Yes, but if they don't do that, how are hackers supposed to get into people's other accounts without needing the password? (Those security questions bug me, too- especially when they're mandatory, from a set list, and answering them doesn't just get a link sent. A person who didn't know the user's favorite book in third grade now does, and because some admins are idiots, that information is a hell of a lot more useful than the perfectly secure password...)
    – root
    Commented Mar 28, 2013 at 3:38
  • Sometimes passwords are hashed over the wire. Server sends a salt, you combine your password with the salt and then you hash it, you then send your hash to the server. The attacker may gain access to that particular session, but he will not know your password for future sessions. If there's a cleverer scheme, I'd love to hear.
    – Hello World
    Commented Jun 11, 2014 at 8:29
13

Other answers provide good insight on security reasons behind this behavior. Although they are correct, I'm pretty sure that at least some websites just have the authorization routine programmed the way it's impossible to tell what was wrong - login or password.

Sample query:

SELECT COUNT(*) FROM users WHERE login = 'john' AND hash = '2bbfcdf3f09ae8d700402f36913515cd'

This will return 1 on successful logging attempt and 0 if there is no user with such name or this user has different password. There is no way to tell which part of the condition failed. So when it comes to displaying error message programmer just honestly tells you that something is wrong and he isn't really sure what exactly it is.

I personally saw similar queries in few PHP-based websites so I'm pretty sure that part of the reason comes from the way the authentication process is coded, really.

Improve this answer
8
  • 1
    I have made login prompts that responded with the phrase for this exact reason!
    – monoceres
    Commented Jul 30, 2012 at 23:49
  • 9
    @monoceres In that case, you're most likely doing it wrong. Either your passwords aren't salted, or they're all salted with the same value.
    – kba
    Commented Jul 31, 2012 at 0:14
  • And to continue kba's point, using the same salt on all values, sometimes called a pepper is basically equivalent to using no salt at all; as all accounts can be attacked in parallel. Furthermore, you always should be careful to do constant time comparison of strings, which SQL will not do; even if they are hashed (especially if the hashing is being done client-side). Otherwise timing attacks can be used.
    – dr jimbob
    Commented Jul 31, 2012 at 4:19
  • Yes, but this has been in school projects and hobby projects, so no need to worry :)
    – monoceres
    Commented Jul 31, 2012 at 16:05
  • 1
    I think this has come after the realization/consensus of the ambiguous login error. I don't think this egg came before that chicken. Some developers cut corners here because they know they aren't required to (and shouldn't) tell the user whether it was the email or password that was incorrect.
    – Adam Lynch
    Commented Aug 1, 2012 at 11:28
9

There is, however, another interesting technique that can be applied to perform a user enumeration attack (and more). It's called a Timing attack. The attacker simply measures the response time for the authentication request and how it differs between a valid and an invalid login.

  1. Nanosecond Scale Remote Timing Attacks On PHP Applications: Time To Take Them Seriously?
    http://blog.astrumfutura.com/2010/10/nanosecond-scale-remote-timing-attacks-on-php-applications-time-to-take-them-seriously/

  2. A lesson in timing attacks
    http://codahale.com/a-lesson-in-timing-attacks/

  3. Constant time string comparision in PHP to prevent timing attacks
    https://codereview.stackexchange.com/questions/13512/constant-time-string-comparision-in-php-to-prevent-timing-attacks

My point being that such a message is not enough if you want to secure your application against this kind of threat.

Improve this answer
5

The security reason behind it is otherwise it becomes a lot easier to find valid usernames.

Improve this answer
5

In addition to all great answers already given, there's a generic security principle which says you shouldn't provide unsolicited information to unauthorized users. I.e. if you have a choice to answer either "your authentication data is not valid" or explaining which part is not valid - you should always choose the former. Some very nasty cryptographic attacks are based on the tiniest amount of error information provided by implementation trying to be "helpful" - see Padding oracle attack. So it is a good idea to always opt for the littlest possible bit of information disclosed to the unauthorized entity - i.e., if his username/password combo is not good, you always answer "username/password not good", and never disclose any more data. Even if in a specific case (like gmail where username is public) it's not important, it's a good practice to adopt by default.

Improve this answer
4

Let's say you enter a random username and an equally random password(just note what password you enter ). Now the passwords can be common among the n users. So, if the website says the password is correct... then you know what follows next.. mayhem among the genuine users as getting login names are quite easy.

Improve this answer
4

Providing ambiguous answer is useful to prevent user enumeration attack.

In some cases attacker doesn't need to compromise user account. Information that user has account is sufficient without any other action. For example it's valuable information for commerce that their customer has account on competitive web shop.

Improve this answer
4

I appreciate various answers above as they say the most but sometimes Applications are also unaware what is wrong UserName or Password. In case of a token based authentication specially to implement SSO (Single Sign On) e.g. IBM Tivoli Access Manager your application either receives a successful token or gets an error back.

Improve this answer
3

if the login is an email address, it's easy to find out that a person is registered at a website - I might not want that >> Sometimes people use email account real password for websites they register when they use email id as login id :)

Improve this answer

You must log in to answer this question.

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