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.
f!rstPo$t (Score:1)
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)
Experience with millions: trim spaces, warn caploc (Score:5, Interesting)
I spent 15 years developing a log in and security system used by about 80,000 web sites, and have had the opportunity to analyze millions of log in attempts. Based on that experience, heres what I do. People copy-paste user names and passwords and when they do, they get extraneous spaces at the beginning and end. So we trim spaces from the beginning and end (not the middle).
Some people use caps lock when they set their password, but most don't, so we show a big warning message if caps lock is on. Later, gdm (the Linux log in) started doing the same.
Re:f!rstPo$t (Score:4, Insightful)
Re: (Score:3, Interesting)
If the alternatives are writing the password down or using short passwords, sure.
Re:f!rstPo$t (Score:4, Interesting)
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.
Re: (Score:1)
> 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.
Re: f!rstPo$t (Score:4, Insightful)
Re: (Score:2)
That is nothing but an assumption on your part.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
If my fingers produce the exact sequence of key presses that constitute my password, how is that sequence not correct?
Re: (Score:2)
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
Re: (Score:2)
That's bullshit, because you already CAN use lowercase passwords, but you do not need to.
Re: (Score:1)
If ever
Re: (Score:3)
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
Re: (Score:2)
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.
Re: (Score:3)
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?
Re: (Score:2)
So? That's not inherently less secure than the shorter PasswordPassword, even if the later is caps-sensitive.
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
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?
Re: (Score:2)
> 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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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).
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:3)
Re: (Score:2)
your password is "Not today and perhaps not in the next 2 or 3 decades."? that's pretty good. not sure I would have posted it on the internet, though.
Re:f!rstPo$t (Score:5, Insightful)
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.
Re: (Score:1)
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).
IP lockout + CGNAT = DoS (Score:2)
(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.
Re: (Score:2)
Re: (Score:2)
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?"
Re: (Score:1)
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.
Re: (Score:2)
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
Re: (Score:1)
You have a point there.
Re: (Score:2)
Re: (Score:2)
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)
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?
Re: (Score:1)
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)
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]
Re: (Score:1)
Ahh - good point. I spend my time worrying about authenticating users using web browsers, so I haven't used any of the zero-knowledge protocols. Maybe some day things like SRP will become commonly available in the web world, but I'm not holding my breath ...
Re: (Score:2)
Re: (Score:2)
So you'd create an Auto-Mistake generator based on common typos. The problem is that people make a LOT of different typos. PBKDF2 would be running until next week keeping up with all the variants on a single password.
Re: (Score:2)
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
Re: (Score:2)
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)
Re: (Score:2)
Linux distros, pure crap, unless you mean Slackware. Full of cargo-cult programmers who think they're cool because they're not using Windows. Crap is crap no matter what OS they're using, they just get to circle jerk with a bunch of other yuppies who think they're awesome for hating on M$.
Yeah those people are not as sophisticated as those who think they're awesome for hating on M$ AND Linux. Clearly the more O/S you hate, the more awesome you are. That's why I hate Windows, Linux and *BSD. I prefer OpenVMS, which is not perfect but those people are a lot more mature and realistic.
Re: (Score:2)
I wonder if the NSA can snoop on carrier pidgeon traffic.
Re: (Score:1)
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)
I'm a C# coder
That explains a lot.
Re: (Score:2)
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!
Re: (Score:3)
Re: (Score:2)
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?
Re:f!rstPo$t (Score:5, Funny)
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"
Re: (Score:2)
Re: (Score:2)
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??
Re: (Score:2)
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.
Re: (Score:3)
If common problems include Caps Lock being on and the first letter being capitalised, sounds like the user frustration is with the input device.
I have a coworker who is Caps Lock challenged, so I configured her computer to have that key behave like Shift. Life has been a lot easier for everyone since then.
Re: (Score:2)
In a business context, leadership is all about leveraging people's strengths, not fixing their flaws. So when I have an opportunity to solve a problem quickly and get the resources focused on value-added tasks, I take it.
Re: (Score:3)
pwgen (Score:1)
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
Obligatory XKCD (Score:2)
It seems that all major research starts on XKCD...
Re: (Score:2)
Re: (Score:3)
I saw an article once talking about how Facebook stores both your hashed+salted password and its case-flipped version. So, leave capslock on and it'll match, for a pretty small loss of protection.
Pretty small? I would think that having two hashes from a reversible permutation of the plaintext can have a very significant impact on how easy it is to break.
Keyboard layout (Score:4, Interesting)
Re: (Score:2)
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).
Transition period (Score:2)
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!
Stupid (Score:3)
No, it's the goddamned asterisks! (Score:5, Insightful)
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.
Re: (Score:1)
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
Re: (Score:3)
"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.
Re: (Score:2)
Re: (Score:3)
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)
Re: (Score:2)
As a practicing Muslim, I take offense to your damning of Allah in the subject line. No virgins for you.
That particular dhow sailed a long time ago.
Re: (Score:2)
sure, and I do use a demasker, but that's beside the point. The complaint is that the field mask has negligible security benefit and is really there mainly for the illusion of security for the user. It makes them feel good but does practically nothing to protect their password from being stolen, while it does in fact create significant issues -- most people are far more prone to typos if they can't see the text they're typing, which then leads to this kind of ridiculous autocorrect idea for password field
Favorite password (Score:2)
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
Watchmen (Score:3)
Computer: > Password
User: > Rameses
Computer: > Uh, you want to tack on anything there buddy?
User: > 2?
Computer: > Come on in
Re: (Score:2)
haha, yeah. to be fair it was written in 1986 ... but yeah that scene is beyond ridiculous, even by 80s computer depiction standards.
for those who don't know what we're talking about -- http://i.stack.imgur.com/LgT6s... [imgur.com]
Security questions (Score:2)
Re: (Score:1)
And are all the limited choices of "secret questions" something that could be easily found via 5 minutes on Google
Um ... you know you are supposed to lie, right? ;-)
Dropbox = optional passwords (Score:1)
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?
Fun story... (Score:2)
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
Re: (Score:1)
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
I have a Cunning Plan (Score:2)
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.
This Girl Will Solve Your Cybersecurity Problems (Score:1)
Dumb idea (Score:1)
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]
Re: (Score:2)
You have gained exactly nothing if the Capital first letter is enforced by the password policy.
Those password policies drive me crazy. They make no sense from the average user perspective, only to the CIO that can say "see, we're very annoying with our password policy, so that makes us very secure". And if anyone chooses Password1! as a password, it is their fault !!