17

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.

Thanks

AviD
  • 72,708
  • 22
  • 137
  • 218
Paul
  • 483
  • 3
  • 9
  • well if thats the case you could log the ip address variable and set a limit that resets after a certain amount of time. –  Mar 24 '12 at 18:23
  • 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. –  Mar 24 '12 at 18:21
  • Captcha, yes of course. –  Mar 24 '12 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](http://en.wikipedia.org/wiki/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 Mar 27 '12 at 08: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 Nov 08 '15 at 03:31

5 Answers5

10

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.
Yoav Aner
  • 5,329
  • 3
  • 25
  • 37
  • +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 Nov 08 '15 at 03: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. – Damian Yerrick May 11 '16 at 17:07
7

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

Adam Liss
  • 179
  • 2
  • 2
    On that urban legend: http://thedailywtf.com/Articles/Really_Unique_Passwords.aspx – Legolas Mar 27 '12 at 08: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 – Andrei Botalov Apr 14 '12 at 11:14
4

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 a@b.c [with username xy] was just registered at $site. Click here to confirm."
  • "Somebody tried to register an account for a@b.c [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.

twobeers
  • 1,079
  • 5
  • 10
  • +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 Apr 14 '12 at 11:20
2

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.

schroeder
  • 125,553
  • 55
  • 289
  • 326
  • The elephant in the room is that you could obtain valid usernames in a vast amount of ways. Elaboration at http://security.stackexchange.com/questions/13079/is-there-any-reason-to-show-the-same-message-for-invalid-username-as-password#comment183188_13090 – Pacerier Nov 08 '15 at 03:39
0

@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.

Joe Zack
  • 101
  • 2
  • 1
    Rate Limit globally? by origin IP? – curiousguy Sep 03 '13 at 04:38
  • 1
    Rate limit per account. – Paul Sep 03 '13 at 09: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: http://www.codinghorror.com/blog/2009/02/rate-limiting-and-velocity-checking.html – Joe Zack Sep 03 '13 at 17:32