I agree with the core answer, but -1 for the first and third paragraphs. Unless you force random usernames, users will pick sensitive names, even to their detriment. This is a problem for privacy (which I do consider a security problem), and also attacks with reused passwords from other services.

@BoppreH: Your objections don‘t make much sense. First, if you agree with me that it‘s very difficult (or even completely impractical) to hide the usernames, then there‘s no way around the fact that usernames can be found out, no matter if we like it or not. So what are you suggesting? To actually use long random numbers as usernames? Good luck trying that. For many people, even just remembering their own passwords is a major challenge – not everybody uses a password manager. If you additionally force them to deal with some random username, this can quickly turn into a usability nightmare.

@BoppreH: Secondly, if somebody willingly puts sensitive information into their public username, that‘s not a privacy problem – it‘s their personal choice. Just like it was your choice to reuse your Stack Exchange name on GitHub, your personal website and whatnot. Are you saying you should not have been allowed to do that? Letting users pick their own name (as opposed to using the e-mail address, for example) means they can decide how much or how little they reveal. If they want to use a completely random name, they can do that.

@BoppreH: Third, it‘s naive to assume that password reuse isn‘t a problem (or is less of a problem) as long as the username stays hidden – if that‘s even possible. Once a password is leaked, attackers can try it on any account and any service they want. Sure, there‘s some extra work if the attacker cannot simply match a leaked username to a username within the target service, but that won‘t prevent them from looking for reused passwords across all accounts. It‘s not like they will give up just because a user is called “foo” in one service and “bar” in another.

(1) I'm not endorsing them for general use, but random "usernames" are in fact very common: phone numbers, bank accounts, passport numbers, license plates, etc. (2) Protecting usernames from timing attacks is probably a step too far, but I wouldn't call merely allowing arbitrary names to be "a more robust solution". Even here on SE I've seen sensitive questions under real names, only for the name to be changed shortly after. You can blame users, but under many threat models you have to help them against bad decisions, just like weak passwords are forbidden. (3) Maybe just add a caveat?

@BoppreH: You have a strange understanding of privacy if you think website owners should decide what users can and cannot do with their own data. Like I said, you’ve chosen to reuse your name on many different sites – who is to say this is a bad decision? Would you really like the Stack Exchange administrators to intervene and tell you to change your name for the sake of privacy?

@BoppreH: I’m generally not convinced that you can force users to make good decisions. Passwords are an excellent example: For decades, people have tried to “forbid” weak passwords with all kinds of rules and policies, but weak passwords are still all over the place. What seems much more promising is to encourage the use of password managers or passwordless authentication methods like WebAuthn. So instead of restricting usernames, I’d (1) stress that the name is public (2) let users choose whatever name they want (3) point out that password managers make it easy to securely store credentials.

@BoppreH No, random usernames are worthless. People will promptly forget their random username, and then they'll keep hitting the recover username function, so the end effect is to just use e-mail for login. If there is a public profile exposed, then decouple that from login with a changeable display name.

Having a timing difference between "user doesn't exist" and "wrong password" allows attackers to check which usernames exist on a system. This then allows them to focus their attacks, e.g. by only brute-forcing passwords for users known to exist, or even by more explicit targeting. That is a security problem.

@marcelm: Did you even read the answer? The idea that you can just hide all usernames is highly dubious. Complex applications leak timing information all over the place. People also leak information, either purposely by linking to websites they’re registered at, or unwillingly by reusing names or choosing obvious ones. Do you really believe that attackers who routinely find passwords (i.e., the one thing everybody agrees should be secret) will have any trouble figuring out usernames? By the way, your own username is visible for everybody here. Are you going to claim a security incident now?

There are various ways one can lead the execution down the exact same path, even if a user does not exist. One easy way: Create an additional example user in the database with a random hash - if a user does not exist, set the username variable to this example user and execute the login procedure with it.

@Ja1024 You keep claiming StackExchange usernames are public, but they're not. What you see is the Display Name. SE login usernames are emails, visible only to moderators and SE staff.

@Falco: You're forgetting about the query cache (and many other factors). If there's a fixed dummy account which is used whenever there's no real user account, then the database system will cache this data and not do any database lookups at all. So you haven't fixed the timing issue. Of course you can now create multiple dummy accounts and select one randomly. But I hope you realize this is a never-ending cat-and-mouse game.

@BoppreH: I know that. I‘m talking about the public username, display name or whatever you want to call it. My point is: You‘ve chosen this name yourself. You‘ve apparently decided to reuse it on several different platforms, which reveals information about you (including multiple e-mail addresses). This isn‘t a privacy or security issue of the Stack Exchange site. It‘s your own decision. So your whole argument that websites shouldn‘t allow users to choose an arbitrary username (because they might make bad decisions) is defeated by your own choices. You clearly did not use a random name here.

@BoppreH: And if you think the username doesn‘t lead to the e-mail address: Are you sure you haven‘t used any of the e-mail addresses that can be found with a simple Google search using your name? Did you really create a completely random address just for this site?

@Ja1024 you are right, this could make a difference, if the attacker generates a lot more login attempts than legitimate users. Since the DB will also cache the names of users who recently logged in legitimately. So you cannot be sure, if you have just hit an account with a recent login, or the dummy.

@Falco: Since the cache is limited, the attacker could fill it with irrelevant data to reduce (or even eliminate) the chance of running into a cached real account. At the same time, they can login multiple times with completely arbitrary names to make sure the dummy account is in the cache. The combination of both should allow them to reliably distinguish between (non-cached) real accounts and the (cached) dummy account.

@Ja1024 I read the answer, I just disagree. Allowing username enumeration is a form of unwanted information disclosure, and is widely considered a security issue. "Complex applications leak timing information all over the place." - While that is true, that's no reason to make that easy instead of hard for attackers. "By the way, your own username is visible for everybody here. Are you going to claim a security incident now?" - I'm not sure what you mean. My display name here cannot be used to log in. For that, you need my SE email address.

@ja1024 Unrelated; I noticed the tone of your comments is a bit aggressive. You keep using language like "... don't make much sense", "naive", "You have a strange understanding of", "Did you even read the answer?", etc. There's really no need to put others down like that.

@Ja1024 exactly - as I said you are right. It is just difficult since the attacker needs to reliably trigger more login attempts than legitimate users, which can be made harder by efficient rate limiting and the addition of random delays to all requests. With this the attacker would need a lot of things to work in their favor to generate a large enough sample to denoise the random delays, while also keeping the cache manipulated without crashing into the rate limit or getting the cache changed by legitimate logins.