According to the OWASP Auth Guidelines, "An application should respond with a generic error message regardless of whether the user ID or password was incorrect. It should also give no indication to the status of an existing account."

However, I have found that many popular web apps violate this guideline by showing a message that the account does not exist.




So what is going on here? Are Google, Microsoft, and Slack doing something insecure or is the OWASP Guideline useless?

  • 7
    Note that all of these only ask for your authentication credentials (e.g. password) after you have entered the username.
    – user
    Commented Apr 25, 2017 at 12:48
  • 10
    Correct. It seems they are being kind to the user who mistypes their account to let them know immediately, but it clearly violates the OWASP Guideline.
    – styfle
    Commented Apr 25, 2017 at 12:56
  • 16
    Variations on this question have been asked many times. There is even a tag for user-enumeration Commented Apr 25, 2017 at 14:24
  • 4
    "Tell the user when their email doesn't exist" Commented Apr 25, 2017 at 15:31
  • 3
    If you want to find out if an account exists, just try signing up with that username.
    – Jon
    Commented Apr 26, 2017 at 19:16

7 Answers 7


This is a consideration between security and usability, and therefore there is not really a right answer here. So here follows my opinion.

If you can keep usernames secret, then do so. In this case there is no way to figure out whether a username exists, and the login reacts the same whether a user exists or not. Note that this also means taking the same amount of time to return an error message.

This behavior may not be possible. For example if users can register themselves and choose their own username, you have to notify them when a username already exists in the system. If this is the case, make the login as easy to use as possible by providing the most detailed error message. If someone can figure out whether a user exists using the registration function, there is no use in hiding this at the login.

  • 41
    "If someone can figure out whether a user exists using the registration function, there is no use in hiding this at the login." - also you can do that by reset password feature, or from list of public profiles (Twitter), or by sending e-mail and possible getting "undeliverable message" error from mail server (Gmail)
    – user11153
    Commented Apr 25, 2017 at 14:36
  • 28
    " If someone can figure out whether a user exists using the registration function, there is no use in hiding this at the login" - unless registration is gated by a captcha and login isn't. Commented Apr 25, 2017 at 14:37
  • 26
    @JanDvorak Then that's a separate and rather serious issue with the login to begin with. If there isn't a way to limit login attempts, then you already have significantly more serious problems than just "figuring out usernames".
    – Nelson
    Commented Apr 25, 2017 at 15:40
  • 3
    @JanDvorak This is why most of those sites that do show you whether or not the account exists on login will start doing a captcha on login after a few failed attempts - so you get a couple tries where you might be able to harvest valid usernames, but after that are slowed by the captcha.
    – Grant
    Commented Apr 25, 2017 at 18:49
  • 6
    I'm accepting this answer because this line sums it up "If you can keep usernames secret, then do so". In some enterprise systems, the sign-up function is not available to the public so there are scenarios this is possible to follow OWASP. In the examples I gave above, those accounts could easily be found outside the login page.
    – styfle
    Commented Apr 26, 2017 at 13:26

It's not the only OWASP guideline that is not followed by big players. OWASP often focuses on security and ignores usability. It can be a valid design choice if combined with a decent password policy, brute-force protection (lockout, captcha,..), MFA, monitoring failed login attempts, etc.

Take into account that user enumeration isn't just the problem of being able to guess user accounts which you can later brute-force for authentication. Some sites should protect the privacy of their users (adult, political parties, dating, ...). If I want to check if my boss is using an adult website I can misuse a user enumeration vulnerability to know what sites he is using.

  • 6
    +1 for the second paragraph which raises a very good point once you know someone's login
    – WoJ
    Commented Sep 2, 2017 at 5:58
  • "If I want to check if my boss is using an adult website I can misuse a user enumeration vulnerability to know what sites he is using." - If an attacker is targeting a specific individual, then a standard registration flow that confirms whether the account already exists or not is going to provide the same information, regardless of any lockout, captcha, etc.
    – Nicholas
    Commented Nov 2, 2023 at 21:53
  • That's why use enumeration is not limited to login. A sensitive website should prevent user enumeration everywhere. A well designed registration will not reveal this information. Often the registration simply responds with some success message and if the account already exists, the e-mail you receive states this. The web app user can't distinguish a new from an existing account but the e-mail owner obviously can.
    – Silver
    Commented Nov 5, 2023 at 11:21

You just can't prevent it. (Unless you're ready to sacrifice a significant amount of usability.)

User enumeration can be undesirable and there are indeed potential security implications (e.g. if an attacker finds out there is a valid account named admin which they might try to access). But for large sites it's something you can't stop from happening.

Even if you don't reveal during login that a user doesn't exist, you will eventually have to warn new users when they attempt to register an already taken name or with an already used e-mail address.

There is no user-friendly way around this:

Create your Google Account

  • 2
    An already used e-mail address is surely not a problem if you just send an e-mail to the given address saying that someone has tried to set up an account, and whether there already is one for that address. But that won’t stop them finding out if the username is in use, though the e-mail would slow it down nicely. If you do not mind giving them random numeric suffixes to append to their names then they also cannot probe existing names.
    – PJTraill
    Commented Apr 25, 2017 at 16:46
  • 3
    It also depends on the service. On a Ashley Madison type portal you don't want to confirm if a email address is signed in or not. For a user name 'tom' this is less of a problem.
    – eckes
    Commented Apr 26, 2017 at 0:30
  • 1
    @grochmal That's why I said "no user-friendly way". My main point is that this issue shouldn't be a top priority for most applications. Allowing the enumeration of users and e-mail addresses in one way or another is accepted by all major platforms I know.
    – Arminius
    Commented Apr 26, 2017 at 20:13
  • 1
    @grochmal: That makes no sense at all. How are you going to send email to a person if someone else can acquire exactly the same email address?
    – user21820
    Commented Apr 27, 2017 at 10:36
  • 2
    @user21820 - I did not mention emails at all. It is just usernames and user IDs. The user then can or can not add an email to which he can be contacted for password resets and similar stuff. I saw this implemented (and it was still horrible).
    – grochmal
    Commented Apr 27, 2017 at 13:00

Safety is relative. It is slightly safer not to give out information about whether the account exists or not. But that doesn't mean that it is unsafe to give out that information. It is just less safe, and only very slightly so.

This is particularly true in the examples you give; there are other ways to find account names, so there is no gain in trying to hide whether or not the account exists.

As with any form of security by obscurity, hiding account names is a weak security control, and other controls are needed.


I agree with @Silver's answer, but want to expand. Keep in mind the context; the OWASP guidelines are meant as rules of thumb for developers who are not security experts. If a software development company has team of top-talent security architects, then they don't need to follow the rules of thumb blindly so long as they understand the intention behind the rules and are mitigating the risks in other ways.

Analogy: you are supposed to change your car's oil every 3 months or 5,000 km, but car mechanics often push it longer when they know their driving habits have been good. And that's perfectly ok.

As for the specifics here, I am not an expert in user enumeration vulns, nor am I privy to why Google and Microsoft made the decisions they did, but I presume they have rate-limiting and black-listing in place to prevent large-scale user enumeration attacks, and have otherwise decided that the user convenience is worth the added risk.


It's probably too hard to say they violate the OWASP guideline, because for applications and service like Google, Microsoft, they need to be as much as possible "user compliant".

Moreover, they all have or offer 2FA protocols.

  • 1
    It is probably too hard to speak about violation when it is a guideline only .)
    – eckes
    Commented Apr 26, 2017 at 0:28

The purpose of not disclosing the active user identifier is to prevent enumeration of a large number of the accounts.

Strictly speaking, you could protect against this by allowing duplicate accounts, but this is a terrible design and will lead you to all kinds of trouble.

Another way you can do this is to assign users an identifier - constructing one that is unused. But this is such a poor usability experience that it might not be worth it *.

The sensible way to mitigate the risk is to implement any anti-enumeration feature - for instance, a good quality captcha, to slow down any enumeration attempt. Then the design is reasonably safe.

The residual risk is then that you leave open the verification of one very high value account - for instance, [email protected]. Then you mitigate this risk by also implementing a control against password cracking attempts, etc.

* Salzer and Shroeder, The Protection of Information in Computer Systems, Section I.A.3)h) Psychological acceptability: It is essential that the human interface be designed for ease of use, so that users routinely and automatically apply the protection mechanisms correctly. Also, to the extent that the user's mental image of his protection goals matches the mechanisms he must use, mistakes will be minimized. If he must translate his image of his protection needs into a radically different specification language, he will make errors.

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