0

It is a common recommendation to return "Username or password is incorrect" instead of "Username does not exist" when the given username does not exist and "Password is incorrect" when username exists but password is wrong.

The generally cited reason is that you don't want to provide an attacker with the knowledge that a username exists, to prevent online brute force attacks.

However, if username is used to login, it has to be unique, and therefore you will need to inform the user that a chosen username is taken while they are creating an account. So an attacker can easily determine if a username exists even if you only say "Username or password is incorrect" when logging in.

But even if no signup page exists, or other measures are taken to obscure the existence of usernames on registration, this recommendation still doesn't make sense. Usernames are not designed to be secret. Most people reuse usernames, and they are easy to find. And keeping them secret only improves security so far as it increases the total size of your secret, which can be achieved with longer required passwords.

And moreover, there are better ways to prevent online brute force attacks than longer secrets. Rate limiting users on login, which a properly slow password hashing algorithm like bcrypt already implicitly does, or providing a timeout after many incorrect attempts, solves this problem far better than a longer secret does.

Is there something else I'm missing? Even on this site I see people defending this practice, but I have yet to see a reason that isn't better solved with other methods.

Edit: As a follow-up, if this recommendation really isn't useful, why is it still common? And where did it come from?

JustinLovinger
  • 790
  • 1
  • 6
  • 8
  • 2
    FWIW I've seen a suggestion (can't remember where) that when using email addresses as usernames to always display a success message when trying to register, and if the email is already registered the system could just not bother sending a confirmation email, or send an email notifying the user that someone tried to register using their address. – AndrolGenhald Mar 09 '18 at 22:38
  • Usernames are easy to find? Can you explain that? – schroeder Mar 09 '18 at 22:41
  • 3
    You also have to consider that user enumeration isn't just a problem for attacking accounts, it could be a privacy issue. – AndrolGenhald Mar 09 '18 at 22:42
  • 1
    You seem to have skipped over some logic. If "measures are taken to obscure the existence of usernames on registration" then usernames are kept secret, thereby hiding the existence of the username. It's not all about brute force, but privacy is also an issue. – schroeder Mar 09 '18 at 22:43
  • @AndrolGenhald That question is definitely closely related, but the top answers either supported the obscuration of usernames without really touching on the other points raised in my question, or focused on technical limitations. I edited my question with a follow-up to better differentiate it. – JustinLovinger Mar 09 '18 at 22:48
  • @Schroeder Because usernames are frequently reused, and most forums and related sites display usernames publicly, you can easily find them. Some forums even provide a page that enumerates all usernames for you. – JustinLovinger Mar 09 '18 at 22:50
  • I'd go for "User does not exist", when someone enters a wrong password. – Konrad Gajewski Mar 09 '18 at 22:51
  • @PaintingInAir you still have a logic error. It's a general recommendation that applies to more than forums ... – schroeder Mar 09 '18 at 22:51
  • @Schroeder Regarding privacy. I'm not sure how it's a privacy issues if the username it not publicly tied to any other identifying information? Also, could you explain the advantage of obscuring usernames on sites other than forums? – JustinLovinger Mar 09 '18 at 22:55
  • 3
    @PaintingInAir as you said: if usernames are email addresses. Imagine having a user account on a porn site, or a political site, or ... – schroeder Mar 09 '18 at 23:13
  • @Schroeder Ok, I see that it can be useful for privacy on controversial sites. But that still doesn't explain why it is a common recommendation if it has a narrow use case, and why it is commonly cited as a defense against online brute force attacks without privacy mentioned at all. I feel like there is some history I'm missing, and that the original reason might be outdated. – JustinLovinger Mar 09 '18 at 23:27

2 Answers2

1

Sometimes there is a legitimate reason for such a protection. To give one example I've personally observed (details elided), the website for a medical provider that specializes in a particular kind of treatment (possibly something stigmatized, like sex reassignment or hormone replacement, suicide or drug addiction counseling, abortion, STI treatment, etc.) should definitely have such protections, because merely knowing whether somebody has an account with the provider constitutes a breach of patient confidentiality (in practice, whether or not in law).

Of course, you also need to protect the registration page, in that case - maybe the registration page just never shows an error, merely says "check your email for next steps" whether or not the user is in the system, or perhaps registration requires some private info in addition to the usual email address+password - and all the other avenues of detecting existent accounts (forgot password pages, etc.). That's totally doable, though.

The same principle can be applied to other things where privacy is desired. Online dating services, "adult" toy/movie stores, any kind of social site where users are always under pseudonyms, specialized legal services, any kind of problem-reporting or similar service where somebody might want to retaliate (for example, whistleblower sites), and so on.

When you get right down to it, there's relatively few scenarios where you wouldn't prefer to have such protections (an explicitly non-anonymous social networking/collaboration/etc. site is the only class that immediately comes to mind). For most sites, it's probably not that big of a deal, but in general, unless you have a reason to make it clear who all is using your site, you should try to avoid leaking usernames. Enough people prefer privacy that it's at least worth keeping in mind, and even though in theory it should be the user's job to ensure they aren't using usernames/email addresses traceable to them across multiple sites, in practice people are bad at / don't know how to do that.

EDIT: I didn't read all the comments first; @schroeder gets it.

CBHacking
  • 40,303
  • 3
  • 74
  • 98
  • It sounds like this is less a security (as in preventing unauthorized access to accounts) concern, as much as it is a privacy concern. And then, it is only effective when paired with similar protections on registration. Unfortunately, it sounds like you can only obscure the existence of a user on registration if email is used for login and usernames are non-unique, because you will need to inform the user that a username is taken if usernames must be unique. – JustinLovinger Mar 10 '18 at 23:42
  • Privacy is basically a subset of preventing information disclosure, which is itself a subset of security. There may be elements of privacy that are unrelated to security but I don't think this is one of them. As for uniqueness, you can absolutely still have unique usernames. Did you miss the part where I said `maybe the registration page just never shows an error, merely says "check your email for next steps" whether or not the user is in the system, or perhaps registration requires some private info in addition to the usual email address+password`? Unique IDs matter, and it's not that hard. – CBHacking Mar 11 '18 at 01:17
  • That is true, you can still use the email approach if usernames are used for login, but only if registration requires an email address. – JustinLovinger Mar 11 '18 at 03:35
  • Leaving aside the question of when you last registered for anything online that didn't require an email address, other forms of contact info (e.g. a phone number or postal address) would also work. – CBHacking Mar 11 '18 at 13:42
0

What you are missing is the crucial element to the "security theatre" definition: no improved security.

Saying that general guidelines provide no improved security in certain cases does not make the guideline is security theatre. As with any guideline, recommendation, best practice, suggestion, or opinion, there must be a risk assessment, which is what security theatre lacks.

If a guideline, like how to treat messaging for bad passwords, offers no improvement in a particular instance, then make that risk assessment. But if you go against an industry standard, then you must make sure that you have accounted for all the potential risks that you may not have considered (like privacy). If you have accounted for all the threats, then make your best decision.

The only problem I have with your concern about this particular general guideline is why you would not follow it. I'm not sure what is gained by not using this particular messaging. But, if you have a legitimate business case, and the risk assessment warrants it, then make your best decision.

schroeder
  • 123,438
  • 55
  • 284
  • 319