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.

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

share|improve this question
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 Mar 24 '12 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 Mar 24 '12 at 18:23
    
Captcha, yes of course. –  Paul 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. 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 8:10
add comment

migrated from stackoverflow.com Mar 26 '12 at 16:35

This question came from our site for professional and enthusiast programmers.

5 Answers

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.
share|improve this answer
add comment

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

share|improve this answer
1  
On that urban legend: thedailywtf.com/Articles/Really_Unique_Passwords.aspx –  Legolas Mar 27 '12 at 8:06
2  
-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 –  Andrey Botalov Apr 14 '12 at 11:14
add comment

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.

share|improve this answer
    
+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
add comment

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.

share|improve this answer
add comment

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

share|improve this answer
1  
Rate Limit globally? by origin IP? –  curiousguy Sep 3 '13 at 4:38
1  
Rate limit per account. –  Paul Sep 3 '13 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 Sep 3 '13 at 17:32
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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