109

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?

bobble14988
  • 1,355
  • 3
  • 9
  • 12
  • 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 Jul 30 '12 at 11:47
  • Non security reason: If the database contains salted and hashed passwords, determining that the password matches an existing one would require hashing the password provided with every salt (1 per user, we hope) in the database. – Matt Jul 30 '12 at 14:14
  • 30
    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
  • @MarkBeadles ... the logon entity won't know if the username is valid? You might have to explain that one more... – schroeder Jul 30 '12 at 14:37
  • 13
    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
  • 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 Jul 30 '12 at 18:57
  • 8
    @JoãoPortela, but the creation screen is guarded by captcha. Thats the difference. – user606723 Jul 30 '12 at 20:18
  • 3
    Occam's Razor says: Programmers are lazy. :) – Affe Jul 30 '12 at 20:20
  • 1
    @JoãoPortela not all systems allow you to self-register automatically. – Bruno Jul 30 '12 at 20:47
  • Because hackers can easily hack the accounts if they know any one thing correctly – Venkatesh S Jul 31 '12 at 07:24
  • 1
    @user606723 fair point (I had forgotten about that). Still: your username is your email, which makes it very much public. – João Portela Jul 31 '12 at 09:29
  • @Affe yes, but you still see this behavior in systems with public usernames where the "it's for security" reasoning does not apply. As such there must be another reason... Maybe it's just because everyone else is doing it. – João Portela Jul 31 '12 at 09:30
  • Even if system allows to check if account exists in some other way, this would still slow down bruteforcing by amount of those requests. – Oleg V. Volkov Jul 31 '12 at 14:55
  • 2
    @JoãoPortela, consider this: If gmail allowed you to figure out if a userid exists without captcha, they'd allow spammers a way to harvest legit email accounts. And you're right, if there are cases where userid's are completely public, then it's likely by convention. Why should your website code not support both occurrences? – user606723 Jul 31 '12 at 17:23
  • @user606723 In the mean time I read [ExpectoPatronum](http://security.stackexchange.com/a/17857/2304) and similar ones and it makes a lot more sense. I just wasn't buying the whole: "after they know the username they just have to guess the password" thing. – João Portela Jul 31 '12 at 17:28
  • 2
    @user606723 In the case of Google, the captcha is there for signing up (like submitting the form), the validation is done via AJAX. You can see the URL, and the POST parameters, and the headers, so the hidden usernames are not the issue. – jadkik94 Jul 31 '12 at 18:09
  • @MarkBeadles The possibility of the user mistyping the username and submitting is extremely rare. Divide it by a billion and get the possibility of the mistyped username matching the one of another user. However, when the user base is huge (like Google's or Yahoo's) the possibility of this happening is higher. But even then, when bob1 mistypes bob2, without knowing he's actually bob1, the site could say "Password invalid for bob2" and the user will get the problem. – Zippo Jul 31 '12 at 21:37
  • 1
    Some sites will tell you if the email address you've given already exists in their system when registering (sometimes pointing you towards the password reset function). Can anyone shed some light on how this isn't giving a malicious user another way to discover valid usernames? (I'm not talking about informative JavaScript prompts, etc. solely here) – Adam Lynch Aug 01 '12 at 11:30
  • Just adding more to the fire: facebook actually tells you when the username does not exist. :) – João Portela Aug 02 '12 at 17:51
  • So does Microsoft: "*That Microsoft account doesn't exist. Enter a different email address or get a new account.*" / "*That password is incorrect. Be sure you're using the password for your Microsoft account.*" – bwDraco Apr 29 '13 at 01:16

11 Answers11

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.

  • 8
    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
  • @kojiro Yes, it does assume that. But, that is not a bad assumption. – schroeder Jul 30 '12 at 14:39
  • @kojiro: I think it's not uncommon that accounts that can be used to administer the website are not published in any publicly viewable username list. – Lie Ryan Jul 30 '12 at 15:36
  • @schroeder I disagree, for most widely known websites (gmail, facebook, twitter...) the username is very much public. – João Portela Jul 30 '12 at 19:02
  • 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? – gooddadmike 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
  • @lazfish, no, because any intelligent user would be able to tell thats a fake message. I agree with Mahn. – user606723 Jul 30 '12 at 20:16
  • It would be effectively the same thing but it would work in environments with validation on each item as well. – gooddadmike Jul 30 '12 at 22:25
  • 1
    @JoãoPortela I did not say that it is a valid assumption for all cases, I said that it is not a bad assumption. Of course some sites have very public usernames, and in that case, if you know a valid username, all you need to do is to guess the password, but as a general case for a designer, it is better to assume that the username is not known. – schroeder Jul 30 '12 at 23:07
  • 6
    He can just attack the sign up page, silly. – Salman von Abbas Jul 31 '12 at 01:25
  • Just view it in another perspective, let's say the hacker is bruteforcing only the passwords as there are people who have pretty weak passwords. He would find a valid password, the system has for example 1000 users, he writes a simple script to scrap the usernames from the website and then he just have to try all the usernames, which is 1000 attempts in this case. This method is faster as the attacker is using the *easiest* password. – HamZa May 13 '13 at 12:53
  • 3
    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 Mar 09 '14 at 21:46
  • 2
    @Gajus not all websites give registration forms. In some SaaS websites admin needs to add users. – pinkpanther Feb 14 '17 at 08:55
25

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.

Gaff
  • 351
  • 3
  • 5
  • 3
    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
  • 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 Jul 31 '12 at 00: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 Jul 31 '12 at 04:14
  • 1
    I don't see the value of the second and third paragraphs in relation to the question asked. – Adam Lynch Aug 01 '12 at 11:24
19

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.

Ploni
  • 157
  • 7
dr jimbob
  • 38,768
  • 8
  • 92
  • 161
  • 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 Mar 28 '13 at 03: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 Jun 11 '14 at 08: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.

Rory Alsop
  • 61,367
  • 12
  • 115
  • 320
Dyppl
  • 231
  • 2
  • 4
  • 1
    I have made login prompts that responded with the phrase for this exact reason! – monoceres Jul 30 '12 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 Jul 31 '12 at 00: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 04:19
  • Yes, but this has been in school projects and hobby projects, so no need to worry :) – monoceres Jul 31 '12 at 16:05
  • Just to be clear, I'm saying that this practice exists. Of course it is a bad one. – Dyppl Jul 31 '12 at 17:21
  • @kba What if your query is something like: "SELECT COUNT(*) FROM users WHERE username = '_USER_' AND hash = HASHFUNC(_PEPPER_ + _PASSWORD_ + salt);". Wouldn't this be a perfectly legitimate query which wouldn't let you know which was wrong? – Zeta Two Aug 01 '12 at 08:42
  • @ZetaTwo: it would, but it requires hashing functions to be built in the particular SQL dialect – Dyppl Aug 01 '12 at 11:25
  • 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 01 '12 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.

Community
  • 1
Charlie Rudenstål
  • 191
  • 2
5

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

Lucas Kauffman
  • 54,169
  • 17
  • 112
  • 196
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.

StasM
  • 1,841
  • 2
  • 15
  • 23
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.

aayush anand
  • 41
  • 1
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.

Jakub Šturc
  • 141
  • 2
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.

Niks
  • 41
  • 1
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 :)

Community
  • 1
Verena Haunschmid
  • 131
  • 4