Slashdot Mirror
Password Autocorrect Without Compromising Security (threatpost.com)
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.
So you are willing to reduce the search space by factor of 2^N where N is the length of the password?
If the alternatives are writing the password down or using short passwords, sure.
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.
Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
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.
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.
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 clear on this, but it seems that in the event of an authentication failure they'll just retry with each auto-corrected variation in sequence until they either get a match or run out of permitted options. Unless both ends of the transaction are making allowances for this (allowing more than three retries for instance), that might actually cause more problems than it solves through locked out accounts, etc. and might also open up new means of attacking an account.
As always, it sounds like the devil is lurking in the details...
UNIX? They're not even circumcised! Savages!
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..
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"
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.
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?
UNIX? They're not even circumcised! Savages!
Having auto-correct eliminates deliberately misspelled words, and thereby reduces attacks to a dictionary attack (the simplest kind).
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.
lucm, indeed.
I mistype passwords all the time due to manual dexterity issues (You try having a stroke) what they are suggesting sounds like a horrible cludge the only functionality I'd like is to be able to select a few of the characters in my masked password and be able to sneak a peek at just the selection.
Build a Man a Fire, and He'll Be Warm for a Day. Set a Man on Fire, and He'll Be Warm for the Rest of His Life.
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.
There is nothing wrong with an all lower case password of an appropriate length.
The Daddy casts sleep on the Baby. The Baby resists!
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....
Computer: > Password
User: > Rameses
Computer: > Uh, you want to tack on anything there buddy?
User: > 2?
Computer: > Come on in
The Quirkz Handbook of Self-Improvement for People Who Are Already Pretty Okay
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 striking out a significant amount of work, and not only is cracking passwords quicker but it's more likely you'll have collisions (and yes, I know about salts, but many web developers don't).
What we need to do is to educate people on why strong passwords are important - and recommend some simply tricks that really can add security with a trivial amount of overhead, such as maybe adding a single phrase to the end of them all, so they remember it as "password" + extra phrase. Another method is to try to remember a catchy made up sentence, XKCD style, and then add some special symbols at the end like $$$ or <3 or whatever to help defeat dictionary attacks, and you've got a reasonably secure password with little extra effort.
"Set a man a fire, he'll be warm for the rest of the night. Set a man afire, he'll be warm for the rest of his life."
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.
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?
"Set a man a fire, he'll be warm for the rest of the night. Set a man afire, he'll be warm for the rest of his life."