"password is incorrect" would be technically correct, perhaps not as helpful as it could be, but certainly not "lying".

This is a better argument, but rarely given. The issue is the accepted argument made for 'username or password is incorrect' is it's a best practice protecting the existence of accounts on sign ins, yet sign ups are ignored.

Agree, the pair username, password can be invalid for 2 reasons:

It is the intended user, but the password is wrong

It is the right password, but the user is mistyped

The login screen has no way to know when is one or the other.

The OP wrote a whole article based on the wrong assumption, and since the title is a click bait, it made it to the front page of hacker news.

Sad.

So passwords might be forced to be unique across users? I've read about that before:

https://thedailywtf.com/articles/Really_Unique_Passwords

You mean you log onto John with password 12345 and the website says "Some other user uses this password, but not John"?

Seems wrong, somehow.

If you, as a developer, are technically able to check that the password is used by another user, you have failed pretty big at best practices.

Doing it every time a user login failed is probably infeasible if you have even a moderate number of users, but you can presumably do it on an ad hoc basis unless you have a ton of users. Or am I missing something?

Yes you are. If you have done your security right, users' passwords are not stored in a form that lets you determine whether one is equal to another.

It's a little different from determining if one salted hashed password is the same as another salted hashed password. Whether it's account signup ("the password is already in use") or login ("you typed in someone else's password"), you have the plaintext of the password, and can just loop through the user table and attempt a login for every user with that password. It's slow when you have a lot of users, as mnarayan01 mentioned, but certainly reasonable as an ad-hoc thing.

(Not that any of this is good practice.)

If you are able to do that, then I insist: you probably have failed at best practices.

Most likely on this part: a good password hashing (ie. security hashing) should be fast so that you can log-in but slow enough to prevent brute force (ie. what you are implying). Hashings like md5/shaX don't have that: you can compute of lot them very quickly, which is their purpose. Bcrypt/Argon2/... will have a cost/time that will allow only a few computation per second, which is their purpose.

So if you did best practices well, and try to loop through your users database, (I assume you have more than a few hundreds users) it might take some time, some long time. Anyway, you'll then fail at another best practice because the initial user trying to log in will get bored and be gone somewhere else ;-)

You might be able to do it for all user names within a certain Levenshtein distance of the current user. That would handle mistyping, but it wouldn't handle the case where you have numerous emails and forgot which you signed up with on this site.

That's so horrible it never entered my mind. But you're right, of course, one could do that.

Yeah, that too :)

More like, I log in as john with password 12345, but I forgot that I had to sign up as john87, so the password is correct and saying it isn't is misleading (even though the system doesn't know that for a fact, it is a possibility).

But how would the system know you're supposed to log in as john87? It would have to check your password against ALL passwords (which shouldn't be technically possible in the first place, because passwords should be hashed and salted, and the only way to check if they are valid should be in context of the given user - as gregoriol noticed).

It doesn't, so it doesn't know whether your password is incorrect, so if it claims it is incorrect it is saying something it doesn't know for sure.

Also it's technically possible to check the password against all other passwords, it just requires rehashing it for every user in the table, you shouldn't do it obviously.

edit: Even if you would check it, it wouldn't help to answer the question about whether the password or the username is wrong, even if the password is used for a different username you still don't know that it's the right password. So it's a bit strange that it is brought up as an issue that you can't check against other usernames.

I think you're confusing "correct" and "exists" or "was entered deliberately." A password can only be correct or not for a given account. If the password differs from the one recorded for the user you specified, it is incorrect. It doesn't matter if there's some other place where that password does exist.

A system that used an "existence" or "user intended to type this" concept of password correctness would be either unimplementable or insecure to the point of uselessness.

If the username is used as the salt when storing the hashed password in the database, it's unpossible to know if a supplied password is valid-but-for-a-different-account.

Wow, using the user as the salt is awesome. Is this considered an ok security practice?

Why would anyone use that ? Best practices require that every user has a random (probablistically) unique salt. Just use bcrypt, or other password hash functions.

Nah, user logins/emails often won't be long enough or random enough. See https://security.stackexchange.com/a/8024/28881 and https://stackoverflow.com/a/5565071/2521092

Would it be an okay practice to prepend the username as extra salt, still using the randomly generated salt?

Why not just use a longer salt? The username is only going to reduce randomness. Moreover, I don't buy the presumed advantage: nobody is really parsing that message to mean someone else could have the same password.

Be careful about how you merge the username and the random salt.

If that is the justification, then the possible error responses could be: 1. Username is incorrect, or 2: Username or password is incorrect. If no user exists with that username, then you can just tell the user that the username is incorrect.

Optimizing for the common case seems prudent here.