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
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/
"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.
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.
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/
Have you considered that you might be a robot? I just click the checkbox that says "I am not a robot" and I'm in
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.
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.
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.