“Invalid Username or Password”: a useless security measure (2014)

This is useful when you have multiple methods to authenticate.

Maybe this user should be redirected to an oauth2 identity provider or maybe they should enter a password.

Good implementations of this will have a hidden password field for password managers to fill along with the username. You'll still need to press enter twice though.

Usually it is to detect the user is registered to (or their domain is mapped to) an account with SSO or Social Auth and prompt them for that login mechanism. If the user is being required to go via the SSO provider, it makes sense to ask for the email first before they input their password so that they can be redirected it neccesary.

> Unfortunately this assumes that there's no other way for an attacker to discover whether a username/email address is registered for a service. This assumption is incorrect.

Security is never perfect, it is always about making it annoying enough that people don't bother. So yes, there are other ways to see if someone has an account. But odds are the person attacking your site is not singling out one account to hack, they are trying bulk attacks with many accounts. So you avoid leaking info to not give the script any more ammo on what else to try. And hopefully the attacker will move on to some site that did give it more ammo.

Of course I meant "automatic forwarding" rather than manually forwarding everything, missed to add that word there someone, corrected :)

> Does it matter given that browsers can remember the username/password anyhow?

No.

The only thing that matters is having two public APIs: one that creates an account (failing if the account already exists), and another that checks if the password matches the username for an existing account. If you have those two APIs then there's no benefit to the second refusing to elaborate on whether the login is wrong or the password is wrong, and it might be useful to users.

However I'm not convinced. For many applications I think a better solution is to merge password-recovery with sign-up: Ask for the email/phone number, then send them an email to confirm which logs them in at the same time. That link, then creates the account if it doesn't exist. This way, no information is leaked, and you don't waste resources creating accounts that never get used.

If you want a fully knowledge-based authentication system, you won't have password recovery, but you might not need usernames at all: I have an app like that, it uses webauthn/client certs/a couple other tricks to authenticate devices, and has one UI function to "log in on another machine" (by taking or displaying a QR code), a separate UI function to "share this view with another user" which creates the user (or selects an existing one that this user created), and a third function to add an existing user (using a meetme code). It only matters what users call each other, not that there are two (or more) geocar's in the system, and so the login API in this system doesn't need to differentiate between an invalid or expired code, nor can it reveal the existence of any internal account IDs because the client never actually sees them anyway.

HN is a social space though, and in this case the username represents some kind of land reservation, so it is important to know if land is taken before claiming it, and it's in this scenario I think I can agree that the login API should tell you if the username is wrong or if it's the password. But I don't think Amazon or Shoprunner more should be like HN even if I usually like it here.