9

Today like many other times in the past, signed for a new service and got a common error message:

Your user name or password is invalid

This time I am wondering how useful it is to notify "invalid password OR user" versus a less common but more useful two message schema with the real problem: "unknown user", "invalid password"

My thought was that a system that does not specify if the user name is valid, could be more secure because it will not expose valid user names. However, how practical is this in real life? Although enabling the possibility of mining a list of user names. How much of a threat can that be? Is it really worth degrading a little bit the login user experience (ambiguous error) in exchange of hiding the list of users?

Right now the idea of exposing the list of valid user names seems like a very bad thing. However I am not really sure if it is just unjustified security paranoia that is not really practical. Even if an attacker might get a list of good user names that he could try to brute-force attack, but if the user names are made public (like in a forum), is it just paranoia avoiding to expose valid user names?

UPDATE:

In a forum for example, a web crawler would be far more efficient collecting user names than a user name generator brute force logger. I was wondering if there are valid cases where ambiguous logging errors are practical at all.

SystematicFrank
  • 315
  • 2
  • 9
  • 1
    I tend to just go with "Invalid Login Details" and leave it at that. –  Dec 20 '13 at 17:03
  • That is what I normally do, just wondering if it is security by superstition or practical security. – SystematicFrank Dec 20 '13 at 17:07
  • 3
    Think it through a little more. If the message says "Invalid password", you now know that the user name is valid. You've now verified half of the necessary information: you know you have a user name that's enrolled for the site, and all you have to do is work on the password. If the message says "it's one or the other", you have no confirmation that either of them is correct. –  Dec 20 '13 at 17:07
  • Exactly what Ken said. Thanks Ken, you saved me typing that! –  Dec 20 '13 at 17:09
  • 1
    off-topic.. belongs on [security.se] or [programmers.se] – Kermit Dec 20 '13 at 17:15
  • @KenWhite I am aware of the extra security of "it's one or the other". Just added an update to my question. – SystematicFrank Dec 20 '13 at 17:19
  • 2
    @FranciscoGarcia: User names here do not reflect login information. Those are done via totally different credentials via OpenID or another identity service. Having my SO user name is meaningless in trying to log in here. –  Dec 20 '13 at 17:24
  • ouch! my bad! but most forums are not as great as StackOverflow – SystematicFrank Dec 20 '13 at 17:26
  • Now considering OpenID logins, it seems that in any case, I learned a far more useful thing about security with this question! – SystematicFrank Dec 20 '13 at 17:29

3 Answers3

5

In a slow brute force attack, using a large zombie network, exposing this kind of information can help a attacker significantly.

Imaging 10,000 zombie computers trying to log in every once in a while first extracting usernames, when a list of users are 'detected' go for passwords.

Lets say the zombie tries once an hour, that's 240,000 tries a day. The internet is full of database dumps with email addresses and usernames to try.

Here some posts on this subject:

Community
  • 1
rdkleine
  • 186
  • 4
2

How bad is exposing valid usernames? If you allow the general public to register, it is unavoidable: an attacker wanting to check whether a username is taken can simply attempt to register with it. In this case, not telling users whether their username or their password was incorrect makes a negligible difference (aside from inconvenience to forgetful users), and you should go ahead and say which it was.

Blacklight Shining
  • 121
  • 4
  • 1
    I don't agree with this. Firstly, login and registration have different levels of complexity and frequency of use. Protecting each registration using a captcha or severally rate limiting them is fine, as people will only use them once. Login will be used frequently, and a captcha for each login will generally annoy people. – Cybergibbons Jan 16 '16 at 10:48
  • 1
    If you allow the public to register, require the email address first, and then allow a username to be created after it has been validated. It's all about adding layers of security. – Cybergibbons Jan 16 '16 at 10:49
  • @Cybergibbons Ratelimiting registrations and requiring captchas for them are good ideas, but I've never seen a service that validated my email address, and then prompted me to pick a username (just ones that used email addresses _as_ usernames). I wonder why? – Blacklight Shining Jan 17 '16 at 20:39
  • I have seen them, several times. Wish I could recall where. – Cybergibbons Jan 18 '16 at 13:01
  • @BlacklightShining A good use case could be registering for internet banking. I would expect in this case the bank would follow up with snailmail or better to provide the username. – Phil Lello Mar 23 '16 at 15:29
  • @PhilLello Making me wait for snailmail to get my username and not letting me pick my own username would both greatly annoy me as a user. Besides, snailmail is hardly secure. – Blacklight Shining Mar 27 '16 at 11:25
1

Security is about layers. It's reasonable to take this approach since it does not leak valid usernames. That said, security through obscurity shouldn't be your only means of security. It's just wise to take this approach to put up an additional road block (no matter how small it is). Just my humble opinion.

  • 1
    Look at my update on my question. I value security layers, however when it comes to valid user names, I wonder if it makes sense preventing one leak (valid user names) when there are easier and more efficient mechanisms to achieve the same goal. – SystematicFrank Dec 20 '13 at 17:24
  • Seems easy enough to have a single error message for a failed user and/or password match. Not sure why having two error messages (e.g. Invalid username and then Invalid Password) would be easier. In a security framework like Spring security you just simply have one error message for a failed authentication event. Logging failures, is an entirely separate issue and is very useful for locking accounts after a series of failed attempts during a time frame. I think it's a good question you raise, and is often overlooked. –  Dec 20 '13 at 17:28