'Username or Password is Incorrect' Security Defense is a Weak Practice (hackernoon.com)

Travis Jeffery, writing for HackerNoon: There's a security best practice where sign ins aren't supposed to say "password is incorrect." Instead they're supposed to say the "username or password is incorrect." This "best practice" is bullshit. Stripe's and GitHub's sign ins for example follow this practice. The idea is if an attacker knows a username, he or she could concentrate on that account using SQL injection, brute forcing the password, phishing, and so on. Here's the problem. All a hacker has to do is sign up to know whether the username is valid or not. Why bother then with obfuscating the sign in? Only the dumbest, laziest hacker is stopped by the "username or password is incorrect" sign in. You gain no security, yet your customers lose clarity. Stripe has their form submission behind reCAPTCHA to prevent naive scripts attacking their sign up. However this has been broken multiple times and likely won't ever be perfect. Even if reCAPTCHA was perfect, a hacker could manually validate their usernames of interest by trying to sign up, then automate an attack on the sign in page.

Comments

Except

[Anonymous Coward]

The user may have entered either the password OR username incorrectly. So saying "password is incorrect" could be misleading.

Re: Except

[Anonymous Coward]

And if it is the database?

jsmith
jsmith1
jasmith

etc

Re:Except

[guruevi]

Then you say "username incorrect" or "password incorrect" as appropriate. You generally do the username lookup first anyway so the logic could be short circuited.

Re:Except

[Dragonslicer]

You generally do the username lookup first anyway so the logic could be short circuited.

Doesn't most software check username and password with a single query?

Re:Except

[jellomizer]

Also this argument seems focused around consumer level sites, where people can make their own accounts. Systems with data that they are really trying to secure, has an Administrator create an account, and not the end user.
Also the level of complexity to try to check if a new account is used or not, by making a login into the system, is a bit harder then just trying the login screen. Meaning the hacker will need to be more particular to the system they are trying to break into. As other then trying to put in 2 data points login name/password, it will need to navigate the account creation page.
Finally if you setup your security in your system in a better way the computer really doesn't know if it was your login or your password was incorrect. You really shouldn't be loading the Account object until after authentication is confirmed.

Re: Except

[Zero__Kelvin]

This has to be the most stupid thing I've seen argued about on Slashdot in years. It is possible that someone may mistype a username or a password. In the former case it is possible such a user exists that is not the intended user. If they try to log in and mistype but there is a username that matches it is still possible the username is incorrect and not the password. The system has no way of knowing. In the end, no pertinent additional information is conveyed by adding additional checks and serving up a different message when the user doesn't exist. There is added complexity with no benefit.

Unless...

[Anonymous Coward]

There's no publicly available 'sign up' option.

Non sequitur.

[msauve]

"Only the dumbest, laziest hacker is stopped by the "username or password is incorrect" sign in. You gain no security, yet your customers lose clarity."

By your own admission, you gain, at the very least, security from dumb, lazy hackers.

IT Security Theater

[Comboman]

There are plenty of IT "Best Practices" that have been proven useless of just plain wrong. Forcing users to change passwords regularly just trains them to use insecure passwords. Forcing upper and lower case just trains users to always capitalize their password. Forcing numbers & punctuation just trains users to adopt the standard replacements (a = @, e = 3, etc). All of it is just an excuse to blame the victim when a breach inevitably happens.

Snarky post paints with too broad a brush

[ScentCone]

I deal with many systems that use admin-approved accounts only, following an application processing cycle. The application process deliberately does NOT inform the applicant that they're attempting to create a duplicate account. On purpose. For exactly this reason. And when someone tries to log in, we provide the "user name and password combination not valid" response. Because we don't want to provide a test platform for someone trying to deduce legit user names. Likewise with the password reset features. While it offers to communicate (using two factors) a tokenized reset link to the user, it does NOT say that the presentation of a non-existent email address means a matching account couldn't be found. Because that's just another test platform we don't feel like offering to bad guys. End users may want it to be easier, but adequate communication/explanation of why it is the way it is generally satisfies all but the worst of the PHBs.

The entire premise is flawed

[rsilvergun]

reCAPTCHA means you can't brute force user checks, because even if you can get around it most have a 5-10 second delay built in; which slows any attempt to get a meaningful list of active usernames to a crawl. This is lame click bait. Another 'article' that reads more like a poorly conceived /. post that was made on a better article.

Very short sighted

[Kincaidia]

"a hacker could manually validate their usernames of interest by trying to sign up, then automate an attack on the sign in page." The fuck? He drops that like it's trivial. The whole point is not allowing to blast usernames until you find one that exists. You throttle EVERYTHING. Signups from an IP. Logins from an IP. Login attempts to a specific account. Everything has throttles. I think the author is seriously off on their reasoning.

As a pentester from experience I disagree

[bongk]

It is not that hard to build a login process, a registration process and a password reset process that don't disclosed if a guessed username is a correct username. And these controls do add significant value.

Username enumeration is one of the first things I consistently look for when penetration testing a web-facing application.
Why?

Because if I can start enumerating valid users I can start building a bit list of usernames.
Once I have a list of usernames I can start password spraying.

What's password spraying? I try one password guess per day against each user account that I identified.
Is it a company that rotates passwords every 90 days? OK then "Winter2017", "November2017", etc.
Is it a retailer based in Wisconsin? OK then "Packers1", etc.
This approach is probably about 80% effective at guessing at least one user's password if I can enumerate at least a few hundred usernames.