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