I've seen a security question/requirement that a website login return the same error message for invalid password as for non-existent user. The idea being that this it makes it impossible to discover valid usernames by scanning the error messages.

In cases where self-signup is available, does this make any difference? You can't allow signup with the same username twice, so an attacker could just attempt to sign up with usernames until a valid username is found.


  • 3
    With login you usually don't have any protection, but with registration you might add captcha, since its as important not to have bots on site, than have one user's password found.
    – Artjom Kurapov
    Commented Mar 24, 2012 at 18:21
  • well if thats the case you could log the ip address variable and set a limit that resets after a certain amount of time.
    – John B
    Commented Mar 24, 2012 at 18:23
  • Captcha, yes of course.
    – Paul
    Commented Mar 24, 2012 at 18:33
  • As a general comment: although it is wise to implement these measures to prevent username leakage, it still is security through obscurity. In other words, the passwords just need to be secure and if someone knows a username this should not be a problem. (Remind yourself that on many social networks your username is used in your profile link, which is just fine.)
    – Legolas
    Commented Mar 27, 2012 at 8:10
  • @Artjom, Login often has captcha too, when you have tried logging in 50 times. In fact, everything has captcha (or at least should). Even searching on Google can give you a captcha if you are spamming.
    – Pacerier
    Commented Nov 8, 2015 at 3:31

5 Answers 5


If there's at least one way to discover which user names are available on the site, it then means that you can try to brute-force/dictionary-attack/social engineer those specific accounts. In the case you described then it doesn't make any tangible security difference to try to hide the error reason on the login page, since it's trivial to discover the real reason otherwise.

Depending on what's more important to you, you can either make your login process more user (and attacker) friendly, or instead try to secure your registration (or any other) process that might reveal which accounts exist on your system.

When defending against such cases related to the the authentication process for a typical web application, you should normally take into account the following routes:

  • Signup/Registration - this can reveal which accounts are available as well as allow flooding your system with fake/stale accounts, name-squatting etc. Captcha can usually provide good protection, as well as timeouts, but won't stop manual, slower attacks. I would also suggest not giving hints about username availability or the success of the registration process. You can just say "Thanks for registering. A confirmation email will be sent shortly to confirm the account" (or something like that)
  • Login page - this is the obvious point, and where most applications already have fairly standard protection, including good-practice of non-revealing errors etc. Slowing down the login process, or monitoring abuse can also help. Lockout for failed logins is also a possibility, but then you're more prone to denial-of-service attacks.
  • Forgot password - this is often neglected when considering information leakage. When someone puts their email/username in the forgot password field, you should probably respond with the same message regardless if the email/account is known or not. Note that this might create support issues ("I put in my email and your system said it's sending me a reset email, but I didn't get anything...")
  • Account details/email changes - many applications allow you to, e.g. change your email address or even account name. This would also potentially leak out whether or not a given account or email address already exist or not. Same rules apply here.
  • +1 for "as long as interactions between users on the site are done with the username, Usernames remain public info". As for Google, it had made the explicit decision that usernames are public info. If you try logging in to Gmail with a wrong username, it would say "Sorry, Google doesn't recognize that email" even before you type a password.
    – Pacerier
    Commented Nov 8, 2015 at 3:38
  • @Pacerier Unless the screen name used for interactions among users differs from the username used for logging in. I've seen installations of Lithium forum software configured this way. Commented May 11, 2016 at 17:07

No, you have no choice for the signup process because the user name must be unique. However, to mitigate the attack you describe, your system should force a delay between attempts. For example, a 15-second delay will probably not be noticeable to humans (because it will take longer than that to choose a new user name), but an attacker is limited to 4 guesses per minute.

On a related note, there's an urban legend about a web site that required its uses to have unique passwords as well as unique user names. Needless to say, this did not enhance security. :-)

  • 2
    On that urban legend: thedailywtf.com/Articles/Really_Unique_Passwords.aspx
    – Legolas
    Commented Mar 27, 2012 at 8:06
  • 3
    -1. 15 second delay between attempts may be frustrating for user when he chooses username and sees that username(s) that he wants to choose are already chosen. Solution may be to block attempt only after non-chosen username Commented Apr 14, 2012 at 11:14

In addition to the very good points already mentioned by Yoav: IMO the only way to completely protect against information gathering during the registration is to use email addresses as usernames. This way you can send an email to the address used for registration w/o giving any feedback directly on the website. The content of the email could look like this:

  • "An account for [email protected] [with username xy] was just registered at $site. Click here to confirm."
  • "Somebody tried to register an account for [email protected] [with username xy] at $site, however this account already exist. If you forgot your password click here. If you did not initiate the registration please disregard this email."

This way, only the owner of the email address will be able to check if an account for the address has already been created.

The password reset functionality is as Yoav mentioned most of the time not hardened against information gathering. We just analysed the security of popular cloud storage providers, which all enabled information gathering at least through the password reset function.

  • +1 good point about using email addresses as user identifiers. Also interesting to find out many sites still leak this information. I have to say it's hard not to leak this information and still give your legitimate users good user-experience though. Users can easily mistype their email and then get frustrated when they don't get a reset email...
    – Yoav Aner
    Commented Apr 14, 2012 at 11:20

Yes, it does make a difference. I could scan the site testing for names until a valid name is found, then hammer that with a brute-force password attempt. Not knowing a valid username means I have to guess that any username might be valid, which increases my uncertainty and increases the number of test cases.

If I know what account I want to brute-force, then no, it doesn't matter that there is no difference in messages.


@Yoav said it very well.

Yes, it's important to protect your customers privacy and (probably) your customer list.

I think a good mitigation is to combine the answers from @Adam and @twobeers.

  1. Require an email verification step every time a username/email is created or changed. Don't reveal whether or not the account exists.
  2. Rate Limit any forms that can modify username/emails.

The combination of these two protects your customers identity and limits the email.

  • 1
    Rate Limit globally? by origin IP?
    – curiousguy
    Commented Sep 3, 2013 at 4:38
  • 1
    Rate limit per account.
    – Paul
    Commented Sep 3, 2013 at 9:42
  • @curiousguy You could rate limit the form, by ip, by session, or even specific rules for your application (One new question per new user on StackExchange)...etc, there are trade-offs for each. I like this article: codinghorror.com/blog/2009/02/…
    – Joe Zack
    Commented Sep 3, 2013 at 17:32

You must log in to answer this question.

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