Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
7  
For websites which offer a different way to see if a user exists, there is no security gain. They're just being annoying. –  CodesInChaos Jul 30 '12 at 11:47
23  
One totally non-security related reason is that it's possible the provider doesn't know which was wrong. E.g. if bob1@provider.com mistypes his user name as bob2@provider.com and there really is another user bob2@provider.com. –  Mark Beadles Jul 30 '12 at 14:24
9  
1. BOB1@PROVIDER.COM mistypes id as "BOB2@PROVIDER.COM" 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 Jul 30 '12 at 14:54
5  
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 Jul 30 '12 at 18:57
5  
@JoãoPortela, but the creation screen is guarded by captcha. Thats the difference. –  user606723 Jul 30 '12 at 20:18
show 15 more comments

11 Answers

up vote 109 down vote accepted

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.

share|improve this answer
1  
Very good answer, thank you. –  bobble14988 Jul 30 '12 at 11:08
5  
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 Jul 30 '12 at 12:55
1  
Wouldn't it make sense for a website to state that every possible userid is valid and offer a made-up recovery email address as well? Would this help thwart malicious behavior by making hackers wast time on userids that in fact actually don't exist and have no passwords to crack? –  lazfish Jul 30 '12 at 19:11
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 Jul 30 '12 at 20:12
2  
He can just attack the sign up page, silly. –  SalmanPK Jul 31 '12 at 1:25
show 8 more comments

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.

share|improve this answer
1  
I love the idea of the coded false username/password to more quickly identify hacking IP addresses. –  David Navarre Jul 30 '12 at 14:06
1  
+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 Jul 31 '12 at 0:00
1  
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 Jul 31 '12 at 4:14
    
I don't see the value of the second and third paragraphs in relation to the question asked. –  Adam Lynch Aug 1 '12 at 11:24
add comment

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 inputed 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 secuirty 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.

share|improve this answer
    
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 Mar 28 '13 at 3:38
add comment

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.

share|improve this answer
1  
I have made login prompts that responded with the phrase for this exact reason! –  monoceres Jul 30 '12 at 23:49
4  
@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 Jul 31 '12 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 Jul 31 '12 at 4:19
    
Yes, but this has been in school projects and hobby projects, so no need to worry :) –  monoceres Jul 31 '12 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 Aug 1 '12 at 11:28
show 3 more comments

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

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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
    http://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.

share|improve this answer
add comment

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 :)

share|improve this answer
add comment

protected by Hendrik Brummermann Jul 31 '12 at 8:09

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.