According to the OWASP Auth Guidelines, "An application should respond with a generic error message regardless of whether the user ID or password was incorrect. It should also give no indication to the status of an existing account."
However, I have found that many popular web apps violate this guideline by showing a message that the account does not exist.
So what is going on here? Are Google, Microsoft, and Slack doing something insecure or is the OWASP Guideline useless?
This is a consideration between security and usability, and therefore there is not really a right answer here. So here follows my opinion.
If you can keep usernames secret, then do so. In this case there is no way to figure out whether a username exists, and the login reacts the same whether a user exists or not. Note that this also means taking the same amount of time to return an error message.
This behavior may not be possible. For example if users can register themselves and choose their own username, you have to notify them when a username already exists in the system. If this is the case, make the login as easy to use as possible by providing the most detailed error message. If someone can figure out whether a user exists using the registration function, there is no use in hiding this at the login.
It's not the only OWASP guideline that is not followed by big players. OWASP often focuses on security and ignores usability. It can be a valid design choice if combined with a decent password policy, brute-force protection (lockout, captcha,..), MFA, monitoring failed login attempts, etc.
Take into account that user enumeration isn't just the problem of being able to guess user accounts which you can later brute-force for authentication. Some sites should protect the privacy of their users (adult, political parties, dating, ...). If I want to check if my boss is using an adult website I can misuse a user enumeration vulnerability to know what sites he is using.
If an attacker is targeting a specific individual, then a standard registration flow that confirms whether the account already exists or not is going to provide the same information, regardless of any lockout, captcha, etc.
– Nicholas Nov 02 '23 at 21:53A well designed registration will not reveal this information. Often the registration simply responds with some success message and if the account already exists, the e-mail you receive states this. The web app user can't distinguish a new from an existing account but the e-mail owner obviously can.
– Silver Nov 05 '23 at 11:21You just can't prevent it. (Unless you're ready to sacrifice a significant amount of usability.)
User enumeration can be undesirable and there are indeed potential security implications (e.g. if an attacker finds out there is a valid account named admin which they might try to access). But for large sites it's something you can't stop from happening.
Even if you don't reveal during login that a user doesn't exist, you will eventually have to warn new users when they attempt to register an already taken name or with an already used e-mail address.
There is no user-friendly way around this:
Safety is relative. It is slightly safer not to give out information about whether the account exists or not. But that doesn't mean that it is unsafe to give out that information. It is just less safe, and only very slightly so.
This is particularly true in the examples you give; there are other ways to find account names, so there is no gain in trying to hide whether or not the account exists.
As with any form of security by obscurity, hiding account names is a weak security control, and other controls are needed.
I agree with @Silver's answer, but want to expand. Keep in mind the context; the OWASP guidelines are meant as rules of thumb for developers who are not security experts. If a software development company has team of top-talent security architects, then they don't need to follow the rules of thumb blindly so long as they understand the intention behind the rules and are mitigating the risks in other ways.
Analogy: you are supposed to change your car's oil every 3 months or 5,000 km, but car mechanics often push it longer when they know their driving habits have been good. And that's perfectly ok.
As for the specifics here, I am not an expert in user enumeration vulns, nor am I privy to why Google and Microsoft made the decisions they did, but I presume they have rate-limiting and black-listing in place to prevent large-scale user enumeration attacks, and have otherwise decided that the user convenience is worth the added risk.
It's probably too hard to say they violate the OWASP guideline, because for applications and service like Google, Microsoft, they need to be as much as possible "user compliant".
Moreover, they all have or offer 2FA protocols.
The purpose of not disclosing the active user identifier is to prevent enumeration of a large number of the accounts.
Strictly speaking, you could protect against this by allowing duplicate accounts, but this is a terrible design and will lead you to all kinds of trouble.
Another way you can do this is to assign users an identifier - constructing one that is unused. But this is such a poor usability experience that it might not be worth it *.
The sensible way to mitigate the risk is to implement any anti-enumeration feature - for instance, a good quality captcha, to slow down any enumeration attempt. Then the design is reasonably safe.
The residual risk is then that you leave open the verification of one very high value account - for instance, barack.obama@gmail.com. Then you mitigate this risk by also implementing a control against password cracking attempts, etc.
* Salzer and Shroeder, The Protection of Information in Computer Systems, Section I.A.3)h) Psychological acceptability: It is essential that the human interface be designed for ease of use, so that users routinely and automatically apply the protection mechanisms correctly. Also, to the extent that the user's mental image of his protection goals matches the mechanisms he must use, mistakes will be minimized. If he must translate his image of his protection needs into a radically different specification language, he will make errors.
