Slashdot Mirror
'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.
The user may have entered either the password OR username incorrectly. So saying "password is incorrect" could be misleading.
There's no publicly available 'sign up' option.
"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.
"National Security is the chief cause of national insecurity." - Celine's First Law
https://xkcd.com/936/
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.
Support Right To Repair Legislation.
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.
Don't disappoint your bird dog. Go to the range.
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.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
The point here is to stop easily mass enumeration of user names which even the author agrees it DOES since the sign up processes use additional slow down mechanisms like captchas. This is the fucking point.
How did this even end up on the slashdot main page?
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.
#DeleteFacebook
"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.
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 which ones generate an error that the account is already signed up. Now the attacker has a list of valid usernames/emails.
What should websites do, if "incorrect username or password" is not the right way? The article makes this suggestion at the end:
So their recommendation is to not provide any feedback when you sign up for an account. Just let the user sign up for a new account (i.e. click Submit) and if the email address doesn't already have an account, then you send them their login details.
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. In the meantime, the user might think the sign-up failed, and attempt to create another account. Granted, only one email will get sent, but the user will be spinning their wheels and getting really agitated for the first few minutes. Not a good way to start a user experience.
I think a better solution is not to notify the new user that the username or email already exists before clicking Submit. Just let them click Submit, then figure out if the account name already exists, and present an error message after Submit. That's not a perfect solution either, but I think it's better than the one suggested in the article.
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-force to find usernames through the signup process; it's going to be that much harder than through the LOGIN process.
Furthermore, I have seen some websites make even THAT unlikely by requiring users to pick a username 8 or more characters and include at least two digits.
The character comp requirement means that simple dictionary words won't be your username, and your dictionary search space is fairly large.
However this has been broken multiple times and likely won't ever be perfect. Even if reCAPTCHA was perfect [.....]
reCAPTCHA is currently GOOD ENOUGH protection to make guessing valid usernames hard. YOU WILL NEVER OWN A PERFECTLY SECURE SYSTEM.
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.
I certainly see how username-or-password doesn't accomplish anything by itself, but as part of an overall design it might, under certain circumstances.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
.
The cited article sounds more like someone is just having a bad day and needed to vent, rather than providing any real insight.
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.
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 one thing to be purposefully vague to make enumeration attacks harder. It's another matter ENTIRELY to tell an outright lie that will do *nothing* to stop a real attacker, but will badly frustrate REAL users. You can remind users of the possibility that an account MIGHT be valid-but-locked-out without explicitly confirming that it IS.
The only valid exception is if lockouts are self-clearing after some period of time (in which case telling them to "try later" would be valid advice).
Almost as bad: "Please contact [sic] Your Administrator". Nobody, and I mean NOBODY who's in a situation that requires "contacting their administrator" EVER knows who "their administrator" is or has their contact information handy. If you can't furnish the helpdesk number in the error message itself, 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. This, IMHO, is another major usability sin inflicted on hapless users all the time.
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 email address or invalid password, you get the "Invalid email or password" message.
- If you try to sign up using an existing email address, you get the normal success flow and "Please confirm your account by clicking the unique link sent to your email address." Legit users simply click that. Attackers simply get no email and no information. (Unless they have access to the target's email, at which point there's nothing the authenticating system can do.) The victim gets a "Someone tried to create an account using your email address." message.
- If you try to initiate the password reset process, you're again blocked by the email address. "If we have an account registered with that email address, we will send you an email with a link to reset your password."
You can also take it a step further by ambiguating display names used on the site, in the forums, in the game, etc. This typically involves appending a random number to the end of the user's name. Thus you can be "DipShit" in the game and "DipShit" to your friends. But to a stranger trying to get at your account, you're "DipShit51615" and there may be dozens of others with the same name.
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.
I see a deluge of script kiddies try to ssh in to my home web server from time to time. It is easy enough for morons to do that, why would they bother with trying to get in through an actual web interface when the tools already exist for them to automate ssh attempts? I can also tell you that the data supports them not paying any attention whatsoever to the messages they get when they fail at this, so if they are going to go to the trouble of failing at web logins why would they care what messages they see there?
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
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".
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.
to deter most would be 'hackers'. It's like putting a club on your car steering wheel. It gets them to move on to easier targets.
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 scams.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
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()!)
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."
The society for a thought-free internet welcomes you.
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.
We get questions related to this topic [and on the general subject of "is the password dead yet?"] coming round on slashdot with a regular if somewhat infrequent basis. But one of the interesting things we seem largely unable to agree on [which is perhaps why the password remains so popular] is: "What, realistically, can we replace them with?"
Tokens can be expensive and easily lost.
Biometrics can be defeated [see iPhoneX face recognition, for example] and, worse, if your biometric signature actually *is* cracked, then it's not easy for you to "change your biometric password", short of surgery of some kind. A bit extreme, perhaps?
Way back in 1950, an American science-fiction writer, E. E., "Doc" Smith recognized this in his space opera, "First Lensman", observing that "anything that science can devise and synthesize, science can analyze and duplicate".
It is genuinely difficult to see where this paradigm will evolve next, but in simple terms it looks as though any solutions based on physical tokens will be too expensive for mainstream adoption; that biometric solutions should be treated with great scepticism from a strength capability and even more scepticism from a personal integrity perspective. That doesn't leave us a whole lotta choices...
The first person to properly crack this is going to have the potential to become seriously wealthy...
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.
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 front door wide open, right? The reality is though, that you're lowering the opportunity cost for a thief, and it makes it more likely you'll be broken into.
Don't believe me? Leave your car door open the next time you're out shopping for food, and something valuable on the passenger seat.
So, yes, it's not providing much, but it's providing something at almost no cost.
Not many Active Directory systems permit self-enrollment. In these systems displaying the login/password message makes sense.
deleting the extra space after periods so i can stay relevant, yeah.
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?
Do you know what is really stupid? Not asking the user to confirm the password. Who of us has never mistyped a password, only to find they couldn't login later?
Good point, but the author's premise has more flaws. From the article:
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 confirmation about the existence of a email address, it is just moving that confirmation from the UI to email, and in the process creating a muddled confusing sign up process. Did I succeed in singing up and the server is slow, or is there already a user with that screen name?
The author is an idiot, because he is advocating trading simplicity and usability for a majority of your users in return for very slightly slowing (but not stopping) attackers. They will get the exact same info, it will just take their script an extra step or two.
HA! I just wasted some of your bandwidth with a frivolous sig!
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.
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.
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 start of their workday?
You shouldn't ever have ten "legitimate" users behind one IP creating new accounts at the same time, and if you do, then some will have to wait or answer a Captcha, not a big deal.
Almost every account I have anywhere locks after so many tries. Typically to the point where you have to contact the sys admin\site owners. This requires access to someone's email - usually their main account. If you can already authenticate someone's email and they are a simple everyday person, you likely already have the username and password to any and every account they have. It's easy. Take that info and hit up every bank login (or whatever) that does not require dual factor. Other possibilities apply like a question\answer which is also not insurmountable. Then again, dual factor is becoming the new norm. In a situation where a password requires a special character, and you can authenticate their primary email account, put a ! at the end you 9 times out of 10 you've got it. Past that - and maybe someone can help me out here - I can't think of any common systems that do not specify whether or not the username or password is incorrect. Now, there is a better situation where you can attempt a password reset. In this situation you will often get "if this username or email exists in the system you will get an email with instructions at that address". If you use an invalid username or email, the system will not tell you. Instead, no email will be sent if it is not registered in the system. This is the one case where quite often it will indeed flat out tell you username or email does not exist, and it is typically specific between the two which can be a big help in modifying an existing known username from another system.
All in all this article is a bit several years ago don't ya think?
Brought to you by Carl's Junior.
Maybe not.
Only send an email if the email actually matches an account on the site.
If a website sends a confirmation email for a login attempt, or for an attempt to create an account that already exists, then it is a mailbomb waiting to happen.
Tell that to the operator of any Internet service that uses two-factor authentication where ability to receive a code through email, SMS, or voice call is the second factor.
You shouldn't ever have ten "legitimate" users behind one IP creating new accounts at the same time
Ever?
Say an Internet literacy class at a high school needs to provision students' accounts on various services. For example, if a Wikipedia student assignment is part of the course, students might need an account with which to edit. How would this be done?
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.
...with one of these:
Tells you you aren't getting in but not why.
CUR ALLOC 20195.....5804M
a high school needs to provision students' accounts on various services. ... How would this be done?
One at a time? Next question.
Relying on correct user error/input isn't a solution to unique identifiers or user indicators. An actual solution is needed and usernames/passphrase will never truly provide it.
The worst you could say about such a message is that it is not informative enough to the end user for them to easily recognise what they may have done incorrectly, but I don't see how on earth anyone could argue that the practice is actually weak, or that it harms security in any way.
And for fuck's sake.... if I see an error that says that says that my username or password is incorrect, then I'm going to go back and explicitly check both my username and password anyway. Expecting the computer to tell you which one was wrong if it happened to find an account with the name you specified has negative security implications that would *VASTLY* outweigh any possible added convenience.
I have a suggestion... instead of even mentioning the username or password, just give the message "Login failed". It's simple and entirely clear what is being said. The fact that it doesn't tell you *why* the login failed is irrelevant. That is a problem that ought to be handled by the end user anyways.
File under 'M' for 'Manic ranting'
Thirty accounts provisioned in thirty minutes, one each minute, is still technically "one at a time". But thirty accounts in thirty minutes would still be likely to activate a rate limiter. So my next question is what approximate rate you meant by "one at a time".
But thirty accounts in thirty minutes would still be likely to activate a rate limiter.
Thirty accounts done sequentially is not "at the same time."
So my next question is what approximate rate you meant by "one at a time".
It's simple English. One at a time.
Why create a programmatic friendly response? Why be precise? Just say. Wrong!! Denied. Try Again. Perhaps the server that is refusing should also notify a user if the account is matched, but the password is wrong.. One on the first fail. And one on the tenth, on the fiftieth, etc... Time for us all to create an authentication scheme that is Vendor independent. Its Time.
Time for a new Political party in the US (or two!) One is off the rails Other cant pony up a leader.
Hiding SSIDs isn't without merit. Not for security, but let's say you're a hotel with a guest network. Hiding the staff network would decrease support calls, because everyday users won't see and won't try to connect to the wrong one.
Those who want to sell account access on the black market are not trying just one user name at a time. They try thousands, maybe millions. They aren't going to try to sign up as thousands or millions of users, just to see if an account exists. Instead, they are going to use lists of guessed user names and common passwords to try to log in. Security certainly IS improved by not telling hackers whether the login failed due to incorrect user name vs. incorrect password.
A lot of the "best practices" are utter bullshit or outright harmful. In Information Security, we are basically at the end of the middle ages of medicine - a few people have woken up and are thinking stuff like "maybe actually check if this does anything?" but most follow ridiculous rituals because that's what the ISO or OWASP or some random website says.
There is an alarmingly small number of actual studies and evidence to support almost all of the best practices. In fact, even when you start searching for them, good luck.
I did a small meta-study by myself (to be published soon) and I'd love to do a large one but I'm not in the academic world anymore, hard to do that when you get paid for applying the best practices and can only work on improving the field as an aside.
But slowly, slowly, us experts are waking up. The NIST password rules change in summer might have been a wakeup call. I sincerely hope so.
Assorted stuff I do sometimes: Lemuria.org
Carrier-grade or not, [being behind NAT] is not Internet. That is a content consumption service.
The world's population exceeds the number of IPv4 addresses. Therefore, it's impossible to provide Internet including IPv4 to everyone. Whom would you leave out? Or would you consider a service that allows inbound and outbound IPv6 but provides no IPv4 routing at all to be "Internet"?
Thirty accounts done sequentially is not "at the same time."
I am aware of that. Closely spaced sequential actions don't have to be "at the same time" to activate an automatic rate limiter.
So you'd rather it say username is incorrect and password is incorrect than username or password is incorrect?
Tell your boss you have too much free time on your hands. They need to assign you more work.