'Username or Password is Incorrect' Security Defense is a Weak Practice (hackernoon.com) 249
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.
Except (Score:5, Insightful)
The user may have entered either the password OR username incorrectly. So saying "password is incorrect" could be misleading.
Re: (Score:3)
The user may have entered either the password OR username incorrectly. So saying "password is incorrect" could be misleading.
And that there could be the end of the discussion. Not everyone saves their username creds in their browser.
Re:Except (Score:4, Insightful)
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: (Score:2, Insightful)
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 (Score:4, Informative)
No, because that would mean the password is stored in clear text in the database, or hashed but not salted randomly, which would be a much bigger security problem.
To securely verify credentials, you get the random salt and hashed password of the user, thanks to the provided login, in the database. Then you salt the password and hash it, and compare the result with the password you got in the database.
Re: (Score:2)
Re: (Score:2)
You can check a salted password just fine in a single database query; I know, I've done it before.
Ahh, the wisdom that comes with age. For absolutely DECADES, Unix stored both the username and encrypted password in the same file, both retrieved at the same time. It's amazing how some people claim that the things Unix did on a routine basis are impossible.
Re: (Score:2)
Still, it is a single query. Example, see " // ONLY ONE QUERY!!!!" below:
public User login(String userName, String passwd)
throws LoginException {
if (userName != null) {
userName = userName.trim();
}
Retrieve password hash, then verify it (Score:2)
Doesn't most software check username and password with a single query?
No, at least not unless the query manager supports a salted slow hash as a built-in operation. As far as I'm aware, it's more common to SELECT the user ID and password hash (consisting of a salt, PBKDF2 iteration count, and hash value) WHERE the username or email address matches. Then the application runs PBKDF2 on the salt, count, and user-provided password, and compares the result to the stored hash value. (Use slow_memcmp(), not strncmp()!)
Re: (Score:2)
Re: (Score:2)
As the password should be hashed and salted, likely no.
On the other hand, you probably would querry for the user and retrive everything that is relevant, which would include the salted, hashed passwd.
Re: (Score:2)
If it's a database lookup the search should be against the username and password together.
The message should be incorrect password, or user doesn't exist.
Validating that the username/email is valid but the password is incorrect is leaking the information that a certain user account exists.
Re: (Score:2)
Apparently you didn't even read the summary. This particular case was already covered right there.
Require email login, not username login (Score:4, Informative)
Requiring users to log in with an email address, as opposed to a username, doesn't disclose that the account exists. If you try to create an account for an address that you do not control, you will not receive the verification message. If you try to create an account for an address that you do control and which already has an account, you'll begin a password reset instead.
Re: (Score:2)
Importantly, multiple attempts to log-in using someone else's (correct) username could lock them out of the system thus resulting in an inconvenience to the other user who has
Re:Except (Score:5, Insightful)
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: (Score:2, Informative)
While we're being pedantic assholes; the user may have entered the correct username and password, but for a different website. So saying "username or password is incorrect" could also be misleading.
Re: Except (Score:3)
We regularly get calls from irate customers who are unable to log in to our website and it's not at all uncommon for them to be either trying to log into one of our competitor's sites or trying to use credentials for our competitor's site on our site.
Re: (Score:2)
Re: Except (Score:2, Insightful)
And if it is the database?
jsmith
jsmith1
jasmith
etc
Re: (Score:2, Informative)
If it is the database, it is a valid username (or once was), but that doesn't mean that it is *correct*.
If I'm jsmith1 and try to log in as jsmith with my password, then it'll fail. Why did it fail? Depending on your perspective it failed either because of a wrong password (it wasn't jsmith's password!) or a wrong username (password was correct, but username was wrong).
The whole point of the article is to have something like "oh you used the wrong username" if the username is invalid. Fine, you can do that
Re: (Score:2)
What is this whole thread about? If it is in the database, it is correct and we can concentrate on the password, or am I missing something?
The point is, I may have miss-entered my username (but it does belong to someone else) while entering my correct password. If you tell me "the password is incorrect" that's incorrect. It's the correct password, just the wrong username, for me.
Re: Except (Score:2)
The point is that there are plenty of hints that can make it easier on your legitimate customer while not decreasing your security. It's rather trivial to validate a username or email in most systems so it doesn't add to security to inconvenience your legitimate customer by being intentionally vague.
Re: (Score:2)
The message should say "that password is not correct for the account [whatever you typed]." That's certainly better than "at least one of those two is wrong and I'm not telling you which."
It means exactly the same thing. "Username/password error" means "at least one of the two is wrong, and I'm not telling you which."
Re: (Score:2)
"Access Denied. Please verify username and password are both correct."
Re: Except (Score:4, Insightful)
Re: (Score:2)
" It is possible that someone may mistype a username or a password."
Ok. So if they enter a username that is not in the system, it should still say "username not valid". Sure, yes, its possible you mistyped your username with another valid user name... and the system can't know... but in a lot of cases the system assuredly does know the username does NOT exist. So in those cases it should say so.
In the case you describe, it should just say, 'This is not not usernames password; ensure both username and passw
Re: (Score:2)
This has to be the most stupid thing I've seen argued about on Slashdot in years.
I'm just wondering if the last time you logged on was years ago. CowboyNeal would never have stood for this nonsense.
Re: Except (Score:4, Interesting)
...or that not all systems allow a user to create their own accounts.
Re: (Score:2)
Unless... (Score:5, Insightful)
There's no publicly available 'sign up' option.
Re: (Score:2)
Re:Unless... (Score:5, Interesting)
The other thing is I may not want people knowing whether or not I have signed up for a service... Does MightyYar have an account at BigFatBootyMamas? Yes, yes he does. I don't care if you can sign in and see the beautiful ladies on my dime, but I don't want it to be easy for people to check my email address against random websites looking for where I have accounts.
Re: (Score:3)
What kind of cretin signs up for anything sketchy with their main identity? If this is your concern you have more basic Internet skills deficiencies.
Re: (Score:3)
This.
I honestly worry about people who only have one identity they use for all purposes on the internet.
Re: (Score:2)
Well he seems to be using is same login for Slashdot as the other sites. So he is using a different login for sketchy sites.
Re: Unless... (Score:2)
Re: (Score:2)
I don't want it to be easy for people to check my email address against random websites looking for where I have accounts.
If someone tries to create an account for mightyyar@zorlonmail.example, then you'll receive the confirmation message instead of the attacker.
Re: (Score:3)
If someone tries to create an account for mightyyar@zorlonmail.example,
They're not trying to create an account, they're running email addresses through the login process. If the login process normally fails with "no such user", and it does not fail that way with "mightyyar@zorlonmail.example", then you know that MightyYar has an account there. It's worse than just using a username, since anyone could have the username "MightyYar", but only one mailbox "mightyyar@zorlonmail.example" can exist.
If it fails with "username or password incorrect" you don't know nothin.
then you'll receive the confirmation message instead of the attacker.
If a website
Re: Unless... (Score:2)
The point is that on most systems it's easy to check for an existing account during account creation so this information is already leaking. The only way for it not to leak would be to not notify someone that the account already exists during account creation.
Re: (Score:3)
There's no publicly available 'sign up' option.
Even then, sometimes the publicly available sign up option requires more intensive/time-exhausting work than simply logging in.
For example: you might specify your e-mail address, then be sent an e-mail with a link to continue the signup process.
You might have to specify your E-mail address before attempting to pick a username,
and the username availability test will be delayed, and the number of usernames you can check per e-mail address will be limited,
A
Re: (Score:3)
Or it is much more carefully rate-limited than the login-option or captcha'ed. Seriously, what is bullshit here is the "story".
Non sequitur. (Score:5, Insightful)
By your own admission, you gain, at the very least, security from dumb, lazy hackers.
Re: (Score:2)
The entire premise is flawed (Score:5, Insightful)
Re: (Score:2)
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
Unless, of course, you hire one of the services that can deploy an army of different people to brute-force user checks at the same time. It isn't even that expensive.
It's still costly enough (Score:3)
Also, there's other things you can do. Like track IPs or use browser fingerprinting to mitigate these attacks. Real ipsec is complicated as hell. At least if you put any real effort into it, which believe it or not most companies do. Where they get hacked is they skimp on the rank and file who do the server patching or they skimp on training their employees to watch out for sc
Re: (Score:2)
Real ipsec is complicated as hell.
Believe me, I know this full well. It's been my specialty for many years.
Re: (Score:3)
The delay is effective at slowing a single-source attack. Modern probing is performed by botnets numbering in the tens-to-hundreds of thousands of sources. I run a firewall monitor that tracks connections attempts and reports them to Dshield [dshield.org]. If you lo
Re: (Score:2)
Once you allow brute force attacks, you've lost. Everything else is a rounding error.
Re: (Score:2)
Re: (Score:2)
By your own admission, you gain, at the very least, security from dumb, lazy hackers.
And you lose a convenience for the user who can't remember what username they signed up with.
Re: Non sequitur. (Score:3)
Stupid article (Score:2)
To prevent attackers from knowing whether an account exists or not your signup must only take an email address and provide no feedback in the UI if the sign up succeeded or not. Instead the user would receive an email saying they’re signed up. The only way an attacker would know if an account exists is if they had access to the target’s email.
Sending a confirmation email w/o UI feedback isn't denying an attacker confir
Requisite XKCD (Score:2)
https://xkcd.com/936/
IT Security Theater (Score:5, Insightful)
Re: (Score:3)
Re: (Score:2)
That's a variation on a word.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: IT Security Theater (Score:2)
Snarky post paints with too broad a brush (Score:5, Insightful)
Re: (Score:2)
The application process deliberately does NOT inform the applicant that they're attempting to create a duplicate account.
So what you're saying is that the article fails due to the fact that it didn't occur to them that sysadmins could also deal with the security failures of a common user-unfriendly setup by making it even more user-unfriendly.
reCAPTCHA has been fucking broken for WEEKS (Score:2)
Click on all the images with cars.
Click-click-click-click-click.
Captcha is invalid, please try again.
Click on all the images with roads.
Click-click-click-click-click-click-click-click, with the image fade-in/fade-out being slower than before.
Captcha is invalid, please try again.
Click on all the images with store fronts.
Click-click-click-click-click-click-click-click-click-click, with the image fade-in/fade-out being slow as fuck.
I swear, reCAPTCHA has made me turn away more than once in the last month or so
Re: (Score:3)
Re: (Score:2)
Crypto-currency faucets have to use reCAPTCHA so that people cannot claim coins with automated scripts.
So some people do use reCAPTCHA dozens of times per day (multiple times per day, over multiple websites) even though it's legit and we're not bot and we're not attempting to break into logins.
Re: (Score:2)
What really annoys me is when the signs are partially inside another square. Should I click on the square that has just the corner of the sign?
Very short sighted (Score:5, Insightful)
A thousand subscribers behind a NAT (Score:2)
You throttle EVERYTHING. Signups from an IP. Logins from an IP.
Good luck with that if you have a substantial number of legitimate users in countries with an insufficient allocation of IPv4 addresses. The IP address of a carrier-grade network address translation (CGNAT) appliance may represent a thousand subscribers or more. Consider what happened 11 years ago when a Wikipedia administrator inadvertently blocked editing from the entirety of Qatar [techcrunch.com].
Their solution is no feedback (Score:2)
The article is very short, and the summary is basically the entire article. What's missing from the summary are the screenshots that explain what is meant by "the attacker just needs to sign up." Because when you try to create a new account for most websites, the website will tell you in real time (before clicking Submit) that your username or email address is already taken. So the attacker has an easy way to figure out what accounts on there. Just enter (via a script) a bunch of email addresses and see whi
Re: (Score:2)
I think this will really confuse people who legitimally try to sign up for a service, and don't get any feedback. That confirmation email might take a few minutes to make it to the user's Inbox. Or maybe they won't realize they will get an email confirmation.
Of course they'll get feedback.
Weak argument against login username obfuscation (Score:2)
Obscuring valid usernames / making them harder to figure out is RISK REDUCTION; the scheme NEEDN'T be PERFECT to be extremely useful.
The best way to mitigate brute-forcing the signup page (IMO) will be require users fill in info such as E-mail address and Captcha before picking username, then RATE LIMIT USERNAME CHECKS for example by using a Proof of Work in the browser.... Or If you try 10 usernames in 5 minutes on the signup page, then throttle or block.
Also, even if you can brute-fo
Re: (Score:2)
RATE LIMIT USERNAME CHECKS for example by using a Proof of Work in the browser
But how do you balance this Proof of Work so that a legitimate user with a mobile phone can complete it in a reasonable time but an attacker with a beefy GPU cannot?
Or If you try 10 usernames in 5 minutes on the signup page, then throttle or block.
How would that work if you have ten legitimate users behind one IP address logging in at the start of their workday?
Re: (Score:2)
But how do you balance this Proof of Work so that a legitimate user with a mobile phone can complete it in a reasonable time but an attacker with a beefy GPU cannot?
You use Argon2D. The mobile phone user will be OK if it takes 10 seconds to signup.
It's fine if you cut 99% of attackers short here; an attacker who is willing to analyze your system and bring a beefy GPU to the table is not really the concern.
How would that work if you have ten legitimate users behind one IP address logging in at the
As usual, I suspect the answer is "it depends". (Score:2)
Security is not something you ever achieve, so what you have to ask is whether a particular practice does enough good to outweigh its cost.
Making an attacker speculatively register an account and solve a reCAPTCHA at least slows down and complicates an attack. That won't stop a determined attacker, but you can make life harder for him. However you do so at the cost of creating issues for users who occasionally forget their user names. The question is whether the the cost outweighs the obtainable benefits.
It's not perfect... (Score:2)
.
The cited article sounds more like someone is just having a bad day and needed to vent, rather than providing any real insight.
Yeah so what? (Score:2)
Why is this even a post? So what? The error message is an error message, it's content is utterly irrelevant. How telling someone "that didn't work" any differently makes any difference is beyond me. Stupid.
Try again "later" (Score:2)
IMHO, the single WORST offense is when an app or system doesn't even have the courtesy to inform you that a username+password will NEVER succeed without intervention by some specific, identified person or group (and provide contact information for reaching them).
Good: "Unable to log in with these credentials. The username and/or password might be incorrect, or the account might have been disabled. For assistance, please call {someone} at {specific number}."
Bad: "Login failed. Please try again later."
It's on
Re: (Score:2)
at LEAST have the decency to furnish the number of somebody (available 24/7/365) who CAN figure out whom they need to contact and tell them.
Is it acceptable to make this "somebody" an international call for at least some of your user base, particularly in countries where you do not have an office?
BULLSHIT (Score:2)
The claim that this best practice is bullshit is itself bullshit.
The hole of determining if the name is in use by trying to sign up for an account using that name or trying to initiate the recovery process using that name is a solved problem.
The usual method is to require the login username to be an email address, and then to have a separate display name for use on the site, in the forum, in the game, etc. No one but the system should see the email address.
- If you try to log in using an invalid em
INCREASE guessing cost (Score:3)
Crackers play script games because zhey can. Good programming should assist genuine users (who make more mistakes than scripts) while heavily penalising automated attacks. [re]CAPTCHA is one idea, rather poorly implemented (AI is better than humans). But lockout, exponential backoff, black- and greylists, IP fail2ban, rate limiting, fail advice, provisional (honeypot?) access and other tactics will increase attack costs. Yes, some of them becomes DoS, but all cracking essentially is exactly this.
Re: (Score:2)
lockout, exponential backoff, black- and greylists, IP fail2ban, rate limiting, fail advice, provisional (honeypot?) access and other tactics will increase attack costs. Yes, some of them becomes DoS, but all cracking essentially is exactly this.
Agreed! But don't go hog wild. Slowing down a password-guessing attack requires only a moderate amount of throttling. Extreme measures just piss off legitimate users.
A rate-limiting or exponential back off scheme can reasonably be capped at a few seconds, perhaps a few tens of seconds delay at most. And lockout is never justified. A 5 second delay will be tolerable for the casual user who types clumsily, yet is more than adequate to defend against a brute-force attack.
Always consider the frustrations e
Do hackers really spend time on that? (Score:2)
Incomplete counterargument (Score:2)
The argument that saying "username or password is incorrect" is silly because hackers can just try to create accounts to discover usernames only applies to systems that allow the general public to create accounts.
That said, the amount of added security by using that phrasing is trivial under the best of circumstance, so I pretty much agree that it's a meaningless "best practice".
Re: (Score:2)
The argument that saying "username or password is incorrect" is silly because hackers can just try to create accounts to discover usernames only applies to systems that allow the general public to create accounts.
How else would you have preferred that Slashdot furnish you with the account JohnFen?
Re: (Score:2)
Not sure I understand your question. I wasn't commenting about sites (like /.) that allow the general public to create accounts.
My favorite response... (Score:2)
I even made this my email sig:
"Password update for user gillbates failed; password '12345' already used by user 'Administrator'; change the password and try again."
Least Worst Option (Score:2)
Tokens can be expensive and easily lost.
Biometrics can be defeated [see iPhoneX face recognition, for example] and, worse, if your biometric signature actually *
Re: (Score:2)
what the hell is it anyway, that makes security tokens so easy-to-lose, even though everyone carries around their car keys all the time and that mostly works?
Re: (Score:2)
maybe if computers made the sound of an engine revving up when you authenticated, people would manage to keep a hold of them? it's just baffling.
Layers of security (Score:2)
As long as we provide for eventual access to the secured location/object/mechanism/whatever, there will always be a way for an unauthorized person to overcome it. However, each layer reduces the number of individuals capable or willing to overcome it. Some of these may be small gains, but as long as the cost in accessibility (the legitimate user impact) is low, there's little reason not to add it.
To put it another way: if you're not going to lock it, it shouldn't matter much whether or not you leave your f
No, this is not always good advice (Score:2)
Not many Active Directory systems permit self-enrollment. In these systems displaying the login/password message makes sense.
No, the problemis the goddamn asterisks (Score:2)
Almost all password errors are caused by those infernal masked entry fields. Today your user ID is most often your email, because this is pretty much guaranteed to be unique as well as being a code you can always remember. Because passwords are intended to be obscure, a good one is hard to enter correctly unless you can see what you're typing. Let there be a Mask This Field checkbox option for that one time in a hundred when someone might actually be looking over your shoulder.
As a pentester from experience I disagree (Score:4, Insightful)
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.
Locking accounts and so on (Score:2)
"For a certain subset of reality..." (Score:3)
When someone tries to log in to one of my systems, I cannot tell which value is incorrect. There is no "look up the user name, then compare the password given", it must be a matched set.
By the time the query to see if the user is valid is made, the user name and password have been hashed, and the query asks for a match to that hash. No match? One of them is wrong, figure it out.
Re: (Score:2)
Option 1 is overkill for a failed login attempt that could be a typo.
A similar message should be for a password reset though. That way attempting to reset the password doesn't expose that an account exists.
Re: (Score:2)
Maybe not.
Only send an email if the email actually matches an account on the site.
Re: (Score:2)
Especially on sites where your user name is your email address. Verifying the account is verifying an address to spam. If you're after a mailing list, you don't need to crack a single account to get valuable information. Then, if you're a smart phisher, you can email all the addresses with an email spoofed from the company, and use it to more easily get into the accounts, and probably a good number of other things.