Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Security Privacy

'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.
This discussion has been archived. No new comments can be posted.

'Username or Password is Incorrect' Security Defense is a Weak Practice

Comments Filter:
  • Except (Score:5, Insightful)

    by Anonymous Coward on Friday December 22, 2017 @11:46AM (#55789957)

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

    • 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)

      by guruevi ( 827432 ) on Friday December 22, 2017 @12:19PM (#55790223)

      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)

          by jb_nizet ( 98713 ) on Friday December 22, 2017 @12:45PM (#55790423)

          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.

          • You can check a salted password just fine in a single database query; I know, I've done it before. As mentioned below, the issue is whether or not the database has a built-in function for the newer hashing algorithms.
            • 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.

          • by ls671 ( 1122017 )

            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();
            }

        • 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()!)

          • Thanks. It's been a while since I've implemented a user authentication system (i.e. we transitioned from MD5 to SHA1), so I'm used to database systems having those as built-in functions. I'm surprised that non-toy databases like Postgres, MSSQL, and Oracle, haven't added the newer hashing functions.
        • 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.

      • 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.

      • Of course, it could be A username but not YOUR username, which would make it incorrect for you even though it might show up in the database. Alternatively, you would never tell a user that they entered the "correct" password but the wrong username! So why tell them that the username is "correct" if it doesn't match with the password?

        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)

      by jellomizer ( 103300 ) on Friday December 22, 2017 @12:38PM (#55790367)

      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)

      by mwvdlee ( 775178 )

      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.

      • 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.

    • by Kenja ( 541830 )
      That's why I write all my error messages to say "new database, who dis?"
  • Unless... (Score:5, Insightful)

    by Anonymous Coward on Friday December 22, 2017 @11:48AM (#55789971)

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

    • Exactly
    • Re:Unless... (Score:5, Interesting)

      by MightyYar ( 622222 ) on Friday December 22, 2017 @12:03PM (#55790097)

      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.

      • by slyborg ( 524607 )

        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.

      • by tepples ( 727027 )

        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.

        • 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

      • 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.

    • by mysidia ( 191772 )

      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

    • by gweihir ( 88907 )

      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 msauve ( 701917 ) on Friday December 22, 2017 @11:50AM (#55789991)
    "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.
    • by dbialac ( 320955 )
      And an extra bit of security in situations where there isn't a sign-up process for the general public, for example in a corporate network.
    • by rsilvergun ( 571051 ) on Friday December 22, 2017 @11:57AM (#55790055)
      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.
      • 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.

        • 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 sc
          • Real ipsec is complicated as hell.

            Believe me, I know this full well. It's been my specialty for many years.

      • Not trying to disprove your thoughtful post here, rsilvergun. Just want to expand people's awareness of modern vulnerability probing

        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

        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

      • To add to your comment, if it is possible for the hacker to brute-force a password using your API, brute-force dictionary attacks are so quick (and passwords people use are so short) that it doesn't matter if they know the user name exists or not.

        Once you allow brute force attacks, you've lost. Everything else is a rounding error.
    • Comment removed based on user account deletion
    • by jez9999 ( 618189 )

      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.

    • 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 confir
  • https://xkcd.com/936/

  • by Comboman ( 895500 ) on Friday December 22, 2017 @11:57AM (#55790043)
    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.
    • Comment removed based on user account deletion
      • by jez9999 ( 618189 )

        That's a variation on a word.

      • I used to have a password that which could not be typed on a keyboard in the normal way, to type it you needed to use ALT + (character numeric code) many times (one for every character). Except that most systems and sites were unable to accept anything in the password field other than characters between A~Z and 0~9.
    • These assertions are meaningless without comparing them to the password security you get when none of these best practices are in place. Run 10000 real passwords taken from a site A with password policies and 10000 real passwords taken from a very similar type of site B without any password policy through a fast password cracker with a huge base password list in the TB range, and then compare the results. Otherwise you're just guessing. If we're guessing, I'd guess that system A will fare better unless it a
    • The voice of wisdom.
  • by ScentCone ( 795499 ) on Friday December 22, 2017 @11:57AM (#55790051)
    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.
    • by T.E.D. ( 34228 )

      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.

  • 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

    • by Ksevio ( 865461 )
      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
      • 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.

  • Very short sighted (Score:5, Insightful)

    by Kincaidia ( 927521 ) on Friday December 22, 2017 @12:04PM (#55790105)
    "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 whi

    • by tepples ( 727027 )

      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.

      Check your email

      Signup progress: Step 2 of 3
      Enter your email address > Check your email > Profile and password

      We've sent an email message to jhall@freedos.example that should arrive in a few minutes. This message has the next step of how to get on board.

      Click the link in the email, or enter the validation code below:
      [_______________]

  • 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

    • by tepples ( 727027 )

      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?

      • by mysidia ( 191772 )

        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

  • 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.

  • ... but it does create another step in order to break the password. Security is not the destination, it is the process. We should not let a process that is not 100% perfect prevent that good process from being implemented.

    .
    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 on

    • by tepples ( 727027 )

      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?

  • 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

  • by redelm ( 54142 ) on Friday December 22, 2017 @12:22PM (#55790251) Homepage

    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.

    • 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

  • 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 se
  • 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".

    • by tepples ( 727027 )

      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?

      • Not sure I understand your question. I wasn't commenting about sites (like /.) that allow the general public to create accounts.

  • 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."

  • 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 *
    • 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?

      • 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.

  • 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

  • Not many Active Directory systems permit self-enrollment. In these systems displaying the login/password message makes sense.

  • 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.

  • by bongk ( 251028 ) on Friday December 22, 2017 @02:06PM (#55790927)

    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.

  • 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
  • by WoodstockJeff ( 568111 ) on Friday December 22, 2017 @05:14PM (#55792495) Homepage

    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.

Technological progress has merely provided us with more efficient means for going backwards. -- Aldous Huxley

Working...