Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
Security The Internet Communications Education Network Privacy Programming Technology News

Password Autocorrect Without Compromising Security (threatpost.com) 140

msm1267 quotes a report from Threatpost: Intuitively, auto-correcting passwords would seem to be a terrible idea, and the worst security-for-convenience tradeoff in technology history. But a team of academics from Cornell University, MIT and a Dropbox security engineer say that the degradation of security from the introduction of such an authentication mechanism is negligible. The team -- Rahul Chatterjee, Ari Juels and Thomas Ristenpart of Cornell University, Anish Athalye of MIT, and Devdatta Akhawe of Dropbox -- presented their findings in a paper called "pASSWORD tYPOS and How to Correct Them Securely" at the recent IEEE Symposium on Security and Privacy. The paper describes a framework for what the team calls typo-tolerant passwords that significantly enhances usability without compromising security. The paper focuses on three common types of password errors that users make while typing: engaging caps lock; inadvertently capitalizing the first letter of a password; or adding or omitting characters to the beginning or end of a password. By instituting an autocorrect scheme, the researchers said in their paper that they could reduce common mistakes and user frustrations with logins. Recently, an anonymous user asked Slashdot how one creates a highly secure password after a study from Carnegie Mellon issued a warning about common user misconceptions. You can engage in the conversation and/or read the witty responses here.
This discussion has been archived. No new comments can be posted.

Password Autocorrect Without Compromising Security

Comments Filter:
  • Half of what TFA is suggesting is, essentially, making passwords case-insensitive. Which as far as I'm concerned is a good thing, I despise case-sensitivity in all its forms in computing, to a human filename is the same as Filename and FILENAME. It's only binary technical smart-asserry that distinguishes them. (I'm a C# coder and I have no problem with the IDE auto-correcting and formatting the cases on my variables so that code is readible and consistent, thus avoiding compile errors)

    • Re:f!rstPo$t (Score:4, Insightful)

      by rastos1 ( 601318 ) on Tuesday June 07, 2016 @05:17AM (#52265751) Homepage
      So you are willing to reduce the search space by factor of 2^N where N is the length of the password?
      • Re: (Score:3, Interesting)

        by Anonymous Coward

        If the alternatives are writing the password down or using short passwords, sure.

      • Re:f!rstPo$t (Score:4, Interesting)

        by TuringTest ( 533084 ) on Tuesday June 07, 2016 @05:42AM (#52265815) Journal

        Yes, because that makes passwords more user-friendly, which ultimately makes them MORE secure (no need for the user to write them down in a post-it, and all that).

        If you remove capitalization as a factor, people would need to choose longer words and more symbols, so it even may prompt a net security gain overall.

        • by Anonymous Coward

          > would need to choose longer passwords

          See the optional part in that sentence?
          Thats why its not gonna happen.

          Also the most insecure passwords are already lowercase only.
          This would just make "password" as secure as "Password" - while atm the second is much more secure than the first one.

        • Yes, because that makes passwords more user-friendly

          That is nothing but an assumption on your part.

          • >Yes, because that makes passwords more user-friendly

            That is nothing but an assumption on your part.

            What, that accepting a correctly-typed password will be more welcoming than rejecting it because of a system mode error? I have empirical evidence for all the times my password has been rejected by typing it with Caps Lock enabled.

            Heck, the Windows login screen had to include a warning for Caps Lock due to all the users failing because of it.

            • You're redefining words like "correctly" to only match certain reduced values. Correct is normally understood to mean correct; not partially correct, or correct-except-for-details.

              • If my fingers produce the exact sequence of key presses that constitute my password, how is that sequence not correct?

                • No, here you use the word "exact" but you left out the equivocation. Here, you're completely wrong. Above, you were wrong because you were using a non-standard value of the word "correct." Here, with the bare unaltered word, you're just being a tool.

                  Now you're wrong about what "exact" means and what "correct" means.

                  If you type exactly the same thing 2 times, they're the same. If you change a "system mode" that determines the value of the keys pressed, and then press the same keys, then you typed something d

        • by allo ( 1728082 )

          That's bullshit, because you already CAN use lowercase passwords, but you do not need to.

          • by Anonymous Coward
            There are plenty of sites that require at least one uppercase letter in a password. And others that require at least one number. And others that require a non-alphanumeric 'special' character "()(*&^%$#@!". And others that do not ALLOW a non-alphanumeric character. And in some technological backwater there are probably sites that require ONLY uppercase or ONLY lowercase. The result is conflicting requirements that make it much harder for people to create and remember strong, long passwords.

            If ever
            • There are plenty of sites that require at least one uppercase letter in a password. And others that require at least one number. And others that require a non-alphanumeric 'special' character "()(*&^%$#@!". And others that do not ALLOW a non-alphanumeric character. And in some technological backwater there are probably sites that require ONLY uppercase or ONLY lowercase. The result is conflicting requirements that make it much harder for people to create and remember strong, long passwords. If every site allowed a password like "MyPasswordOnSlashdotIsUnicornDroppings", it would be easy for people to have a mental system in place to create strong, unique passwords for every site. Autocorrect would help usability here, but would still not make a dictionary attack feasible when there are 7 or 8 dictionary words strung together. Yes I know some people think XKCD is wrong and everybody should be using random passwords and a password manager, but personally I think A) they are full of shit, mainly because cross-device password manager usability sucks (especially when you're unwilling to trust your passwords to a cloud service, as I am), and B) that's just never going to happen anyway - people aren't going to switch to password managers en-masse ever.

              No, they wouldn't. You seem to assume users have a set amount of effort they'll spend on a password, correct? That's a false assumption - because, most users will spend as little effort as possible. If FOOTBALL is the same as football, do you think they'll switch to something like "football12468;|"? No, they'll pick... football. But now, it's also Football. And fOotball. And FOOTBALL. Some limited forms of autocorrect don't really weaken security, but if we go to password case insensitivity, you are striki

              • No, they wouldn't. You seem to assume users have a set amount of effort they'll spend on a password, correct? That's a false assumption - because, most users will spend as little effort as possible.

                You seem to assume that users will have a choice in the matter. I would expect that any site implementing a password autocorrect feature would also increase the minimum length to something significantly over 8 characters so as to prevent usage of single words as passwords.

                • No, they wouldn't. You seem to assume users have a set amount of effort they'll spend on a password, correct? That's a false assumption - because, most users will spend as little effort as possible.

                  You seem to assume that users will have a choice in the matter. I would expect that any site implementing a password autocorrect feature would also increase the minimum length to something significantly over 8 characters so as to prevent usage of single words as passwords.

                  Ahhh... but if the only requirement is length, you don't think we'll see "passwordpasswordpassword" become popular?

                  • Ahhh... but if the only requirement is length, you don't think we'll see "passwordpasswordpassword" become popular?

                    So? That's not inherently less secure than the shorter PasswordPassword, even if the later is caps-sensitive.

                    • Ahhh... but if the only requirement is length, you don't think we'll see "passwordpasswordpassword" become popular?

                      So? That's not inherently less secure than the shorter PasswordPassword, even if the later is caps-sensitive.

                      But it's not an improvement. If anything, it's worse, because it leads to a false sense of security. It's a much better use of effort to convince people why it's important, after which they'll naturally adopt strong passwords, as opposed to trying to force them into something they don't want to do.

                    • People will never "naturally adopt strong passwords", and pretending that "they will, if only technicians bother them sufficiently" is the main reason why security by passwords is the clusterfuck that it is.

                      Designing the security system around the behavior of its users is the proper way to do it, rather than forcing users to adopt the behavior requirements of a bad system.

                      In the meantime, I welcome any attempt to make the life of password users less miserable. The password system is NOT secure as commonly i

                    • Designing the security system around the behavior of its users is the proper way to do it, rather than forcing users to adopt the behavior requirements of a bad system.

                      Too many security people don't understand this. Obvious there are degrees of compromise, but I've seen way too many instances of security necessarily hassling people to the extent that they circumvent it in a manner that's even more unsafe.

                    • Then they are not good security people. The weakest link in security is most often the human element; if you don't understand humans well, it's impossible to build a secure system, no matter how much of a cryptographer wizard you are. How good is the best encryption scheme if its user is socially engineered to unlock it for you?

                  • by allo ( 1728082 )

                    > would also increase the minimum length to something significantly over 8 characters so as to prevent usage of single words as passwords
                    how long?

                    Come for a visit to germany and meet the Donaudampfschifffahrtskapitaen.

          • That's bullshit, because you already CAN use lowercase passwords, but you do not need to.

            You don't understand the problem. Having a lowercase password won't help you when you happen to type it with Caps Lock enabled.

            Not that it prevented you from posting an inflammatory post.

            • by allo ( 1728082 )

              YOU don't understand. But think you for flaming.

              The point is, you should not make passwords case insensitive, but you should not force upper case letters either. Because you would rule out all all-lowercase passwords, thus making the set of possible passwords smaller.

              And for caps lock there is an easier solution: show the user an indicator (or fully ignore the capslock). The indicator has some advantage, when the user uses caps lock on purpose.

              • Showing the indicator is almost useless, as proven by the Windows login dialog; people typing either from muscle memory or hunt-and-peck will most of the time ignore it until it's to late.

                Ignoring the capslock is a much better strategy, and it outweighs the marginal benefit of easing out an ALL CAPS password (which is not much better than an all lowercase one).

                • by allo ( 1728082 )

                  I guess ignoring caps lock (or showing indicator) will not work for web pages. OTOH, how often does it happen? Then the people type in the password a second time, so what.

                  • Then the people type in the password a second time, so what.

                    You've never heard about death by a thousand papercuts?

                    Every single misstep caused by a user interface makes people mistrust technology; and the effects are cumulative. This carelessness by developers is what makes end users badmouth tech and think it's too complicated.

        • Having auto-correct eliminates deliberately misspelled words, and thereby reduces attacks to a dictionary attack (the simplest kind).
      • Re:f!rstPo$t (Score:5, Insightful)

        by michelcolman ( 1208008 ) on Tuesday June 07, 2016 @05:57AM (#52265857)

        I suppose it's OK if, on login, if the entered password does not match, they try with simpler versions but NOT more complex ones.

        For example, if the password is "password", then "Password" and "password]" will be accepted as correct.

        However, if the stored password is "passWord]", then "passWord" will not be accepted and neither will "password]"

        So basically, the system should try removing capitalization and removing extraneous characters, but not adding them. This would indeed increase user-friendliness without affecting security much. Hackers tend to try the simpler versions first anyway.

        Another thing I wish people would implement everywhere, is not counting duplicate login attempts with the same erroneous password or pin towards your allowed number of login attempts. If someone types the wrong pin (not a typo, but just a mistake), he will usually try it a second time before realising it was a different one. Then, on the third attempt, a single typo can block his card. Counting multiple entries of the same code as a single miss will have absolutely no negative effect on security but will make a big difference in user-friendliness.

        • by Anonymous Coward

          The whole concept of locking an account for too many login attempts is broken. It's nothing more than a denial of service vulnerability.

          (Locking out the IP address is another matter in most cases).

          • (Locking out the IP address is another matter in most cases).

            That still allows a bad actor behind a carrier-grade network address translation (CGNAT) to DoS a hundred legitimate users behind the same CGNAT. And with IPv4 address exhaustion, many mobile ISPs and ISPs in late-developed countries have deployed CGNAT so that the Internet can have more than 4.2 billion users.

        • This would almost certainly require storing passwords with reversible encryption instead of a hash; how else can you check for "sufficient" similarity or dissimilarity without knowing the password? What algorithm would you use to determine "this character can be dropped, but that one can't?"

          • User enters "password]"

            Does the hash for "password]" match? Nope
            Does the hash for "password" match? Yes, acces granted.

            No need to reverse the hash.

            Not that that is not the approach taken in the paper, theirs is quite a bit more complicated.

            • by skids ( 119237 )

              But that's not how the secure password systems these days work. The ones that are worth their salt (no pun intended) never actually send a password to the remote host. They use the password to create a crypt which the remote server can re-create using what it knows of the password. The only way to actually do this sort of "auto-correction" is to make multiple actual attempts against the auth server. The auth server cannot tell whether these attempts are auto-correct attempts, or someone trying to brute

      • by Bengie ( 1121981 )
        Correction, 26^N
    • Having a maths background, the ability to have x and X refer to different things is natural, useful, and the inability can be annoying. I haven't read the article, but essentially what I imagine is that, given a mismatch when checking exactly (that is, hash and compare to stored hash), it is then easy for the server to calculate say 1000 likely variants assuming the presence of a typographical error, and try those. The insecurity is mitigated by making your minimum length 2-3 characters more.

      • Re:f!rstPo$t (Score:4, Interesting)

        by Zocalo ( 252965 ) on Tuesday June 07, 2016 @07:12AM (#52266149) Homepage
        With salted and hashed passwords it would need to be the client generating the auto-corrected versions - the server should never, ever, have any idea what the actual password was and just retain a copy of the hash to mitigate against brute forcing, but otherwise yes, the lost security would be offset by adding a few more characters. What I'm currently trying to figure out is what additional impact (if any) combining this with a scenario involving dictionary attack and rainbow tables might have on the net security of the system. My initial gut feeling was that you would need to add more than 1,000 extra combinations to the password through additional characters to offset the loss of allowing 1,000 variants - and possibly a lot more - but I'm coming up short on actually quantifying it; ultimately you *still* need an exact match, so all the proposed system is doing is a small scale version of a dictionary attack, so maybe there's no change there at all.

        One way it absolutely weakens your overall security though is account lockouts through retries; you are going to need to allow a lot more retries for this to work, which is going to allow kiddies trying lists of popular passwords a *lot* more attempts before they trigger an account lockout. Tools like Fail2Ban are incredibly effective when you only allow three attempts before blacklisting the IP (bonus points if you do so across your entire estate), but if you need to set that to a few thousand to allow for auto-corrected variations then what's the point?
        • by Anonymous Coward

          With salted and hashed passwords it would need to be the client generating the auto-corrected versions.

          That is not correct.

          There is already code on the server that generates a hash from the user input, in order to compare the new hash against the stored version. That's the code that would generate hashes from the auto-corrected variants as well.

        • Re:f!rstPo$t (Score:4, Insightful)

          by Ly4 ( 2353328 ) on Tuesday June 07, 2016 @08:48AM (#52266777)

          Are you positing that the client creates the hash from the user password?

          That's not how it works. If the client generated the hash, then the hash would essentially become the password, and all of the benefits of hashing and salting would be lost.

          There's a pretty good discussion here about why hashing occurs on the server:
          http://security.stackexchange.... [stackexchange.com]

      • by fnj ( 64210 )

        The insecurity is mitigated by making your minimum length 2-3 characters more.

        I didn't think so, so I ran the numbers. Disregarding dictionary attacks, you have to brute-force 26^8=2^10^12 tries to nail "password", and 52^8=1x10^14 tries to brute-force "passworD", but 26^10=1x10^14 for "passwordab", which adds only 2 letters.

        You're absolutely right. Doubling the character set from lower case to both cases only gives you a puny increase in entropy for passwords of non-trivial length. Clearly adding digits an

        • by BranMan ( 29917 )

          So, basically getting rid of uppercase letters essentially shortens your effective password by 2 letters? OK, makes sense.

          On the subject of dictionary based sequences of words - how much entropy would be added if you deliberately misspelled one of the words in the password phrase? Would you get the entire sequence of characters for entropy in that case - 26^42 in your example, since the codebreaker would have to go back to fully brute force? (I get 2 x 10^59)

    • by Anonymous Coward

      The filename is a variable, Filename is a class, and FILENAME is a constant. Or whatever your code convention says. As long as the codebase is consistent, it makes the code a lot easier to follow.

      That certainly is better than having to guess what it should be, or using a variation of pattern like filename_var, filename_class, filename_const.

      You also could similarly argue that long names are bad. Just use f for file name, etc. If you think that is bad, think about the reason (loss of information) and why som

    • Re: (Score:1, Funny)

      by Anonymous Coward

      I'm a C# coder

      That explains a lot.

      • by lucm ( 889690 )

        I'm a C# coder

        That explains a lot.

        Oh I see, it's funny because you imply that being a C# coder is bad! Good one!

    • by Zocalo ( 252965 )
      I think they are going a bit further than that; based on the examples in the summary, then for the actual password of "p@ssword" the system would also accept "P@SSWORD", "P@ssword", "p@sswor" and "p@ssword1". That's all well and good if you have access to the original password and can apply the auto-correct algorithm to see if what was entered is good enough, but how is that supposed to work if you are taking password security seriously and using salted and hashed passwords? The article isn't totally clea
      • That's all well and good if you have access to the original password and can apply the auto-correct algorithm to see if what was entered is good enough, but how is that supposed to work if you are taking password security seriously and using salted and hashed passwords?

        If you don't have access to the password that the user entered, how do you check their password at all?

    • by Anonymous Coward on Tuesday June 07, 2016 @06:38AM (#52265977)

      to a human filename is the same as Filename and FILENAME

      But to the same human, jack and Jack is not the same.

      "I helped my uncle jack off a horse"
      "I helped my uncle Jack off a horse"

    • by DrXym ( 126579 )
      If you don't want case sensitivity then don't create passwords with mixed case. The purpose of course for mixed case is to increase the key strength for any given length of password.
    • Ummm....having case-insensitive passwords is a Terribly Bad Idea(tm), which you'd realize if you'd thought about for even a moment or two.

      So..."MyPaSwoRDsTrinG" should be equivalent to "mypasswordstring"? Really?

      What kind of head injury do you have??

      • by lgw ( 121541 )

        TFA didn't suggest case-insenstive, but rather "caps lock on" and "first letter unintentionally capitalized". That costs 2 bits of password entropy, not bad.

        But really, case insensitive doesn't cost you that many bits of entropy for most passwords.

  • by Anonymous Coward

    I just let pwgen generate my passwords. I basically use two: low sec (e.g. my login passwords) are eight characters, hi sec (hd and backup media encryption, ssh key passphrase, bank token) are 16 characters.

    I just generate one, i.e. I don't pick a "nice" one, so I'm out of the equation.

    I memorize them. I never use the same password twice.

    Seldom used passwords are in an encrypted file. Passwords I use frequently are just in my head. I don't even trust firefox with them (heck: I trust my browser with as littl

  • https://xkcd.com/936/ [xkcd.com]

    It seems that all major research starts on XKCD...

  • Keyboard layout (Score:4, Interesting)

    by kubajz ( 964091 ) on Tuesday June 07, 2016 @05:48AM (#52265835)
    In my country, along with caps lock, many people will switch between local and English keyboard layout so instead of 123 they will type ÄÅÄ. Another one back home is qwertz versus qwerty. I wish someone implemented this a long time ago along with the 'caps lock ignore' feature. By the way, it is quite unlike case insensitivity because you just accept two versions - Password and pASSWORD - pAsswOrd would not be accepted. That actually till keeps the security pretty high I would say, with a decrease of the search space to one half of the original for each 'forgot to switch' factor.
    • by _merlin ( 160982 )

      That's not how caps lock works on a Mac for example. On a Mac Caps-Shift-A will produce capital A as well (shift doesn't negate caps lock on letters).

  • If this ever starts to take hold it might really screw up those people who use the same password in multiple places. If I use a password frequently in a place where autocorrect is implemented, I might re-memorize the password incorrectly both in mind and in muscle memory. Then, when I enter the 'same' password in the place where I use it less frequently, and where autocorrect isn't implemented... OOPS!

  • by SuperDre ( 982372 ) on Tuesday June 07, 2016 @06:35AM (#52265961) Homepage
    So instead of just making sure the user learns from the bad input, we'll just let them go ahead.. Sorry, but to me it's just stupid, yes it might be annoying at times, but if it happens a lot, then you might want to consider fixing the problem yourself and not let a system help you with your own faults during entering the password.. If the capslock is on, just tell the user the capslock is on, not help them circumvent it..
  • by Applehu Akbar ( 2968043 ) on Tuesday June 07, 2016 @06:47AM (#52266009)

    Instead of weakening passwords by assuming that some combinations are errors, let's fix the main cause of password typos, the masked entry field.

    Think back on the last hundred times you logged into something with a password. Other than at the ATM, in how many of these cases could someone have been looking over your shoulder? The only times when you need a masked field is when you're standing at a dedicated device with people lined up behind you. On computers, a 'mask this password' checkbox option will cover that occasional instance when you're in a public environment.

    • by Anonymous Coward

      The only times when you need a masked field is when you're standing at a dedicated device with people lined up behind you. On computers, a 'mask this password' checkbox option will cover that occasional instance when you're in a public environment.

      No, the reason you mask the password is to prevent the chance of a malicious third-party seeing it. Just because there's no one standing behind you at the time, doesn't mean that someone or something isn't monitoring your screen / device. A camera planted discreetly could take photos or video of your screen. The machine itself might have been compromised to take screenshots. The "display password" toggle to remove the asterisks is a better idea.

      Back to the topic: is it me or is correctly password typos akin

      • "Just because there's no one standing behind you at the time, doesn't mean that someone or something isn't monitoring your screen / device."

        The cheapest and most likely way for the bad guys to capture logins is with a keylogger, against which masking is useless.

    • Why not simply have a button/control/shortcut/whatever that briefly _shows_ the masked password - that way the default is safe and you can check for shoulder surfers before you make it unsafe, but you have the ability to check the password if you are unsure about your typong.

      Simple, easy, helpful, safe-by-default.

      And also, already there on anything from phones to desktops (std disclaimer: your chosen OS may vary)

  • TRIGGER WARNING: Anecdotal evidence

    One of my favorite passwords was based on the word wizard. I didn't often type z's, let alone x's...I set up a new Linux box and my root account (before all this safe don't-ever-use-root-use-sudo bullshit). Trying to log on to my system the first time, I couldn't get the password right no matter how careful I was.

    Finally, I decided to type it quickly and see what "muscle memory" did. wixard.

    Ahh! There it was, a simple typo (I had to type it at the prompt to see what the t

  • by Quirkz ( 1206400 ) <(ross) (at) (quirkz.com)> on Tuesday June 07, 2016 @08:49AM (#52266779) Homepage

    Computer: > Password
    User: > Rameses
    Computer: > Uh, you want to tack on anything there buddy?
    User: > 2?
    Computer: > Come on in

  • Maybe they can apply this to those terrible security questions. Was my high school mascot the Cardinals or the Red Cardinals? Which one did I type when I was first asked this question, because we used to call ourselves both when I was in school. And did I capitalize it? And did I pluralize it? I got locked out of an important system because of this, and it was a system that didn't need that level of security.
  • Given that Dropbox has previously considered passwords to be optional, I'm not convinced that Dropbox engineers adds much credibility to this research.

    http://techcrunch.com/2011/06/... [techcrunch.com]

    And how are they hashing the passwords if they are allowing for typos?

  • 20 years ago I was working on a SunOS setup, and we would periodically crack our own users passwords to let them know when they were vulnerable.

    I don't recall the specifics, but one user was failing with something like 'Password'. The user was befuddled because they swore they used much longer passwords with a bunch of hardening tacked on the end. They had been dutifully typing the 20 character password they had selected, not knowing the SunOS system at the time would truncate to 8 and check only that.

    Any

    • A lot of systems have old habits from back in the 1970's, like short passwords.

      But if the new versions allow 120 characters for just the first name, I think they could afford a longer password and hash. 8-P

  • From now on, my systems are going to require that all passwords include an emoji character.

    Crack that, you rotten blackhatters!

    And while we're ranting about capitalization and special characters (%$*&#), why not just give up and realize that everything inside a computer is 1s and 0s? Require all passwords to be a string of at least 110111110111 1s and zeros.

  • What's a BOFH to do? With auto correct this could cut down trouble calls a lot. It's a BOFH's highlight of the day to get those calls.
    http://bofh.bjash.com/ [bjash.com]

"Well, if you can't believe what you read in a comic book, what *can* you believe?!" -- Bullwinkle J. Moose

Working...