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