Password Strength Testers Work For Important Accounts 129
msm1267 writes "Many popular online services have started to deploy password strength meters, visual gauges that are often color-coded and indicate whether the password you've chosen is weak or strong based on the website's policy. The effectiveness of these meters in influencing users to choose stronger passwords had not been measured until recently. A paper released this week by researchers at the University of California Berkeley, University of British Columbia, and Microsoft provides details on the results of a couple of experiments examining how these meters influence computer users when they're creating passwords for sensitive accounts and for unimportant accounts."
Re:What's really needed... (Score:4, Informative)
This is the basic goal of http://openid.net/ [openid.net]
Using facebook's auth mechanism is mostly just a flavor of this.
Though see also http://supergenpass.com/ [supergenpass.com]
I don't know any of my passwords. I just know my supergenpass phrase.
Re: What's really needed... (Score:4, Informative)
Re:What's really needed... (Score:3, Informative)
And by "working with phrases" you mean "working with known phrases", or rather "correct horse battery staple is already in the dictionary". If you do any PW cracking and "know that comic is wrong", you're probably just a script kiddie.
A random word from 65000 words dictionary gives 16 bit of entropy, adding variations on capitalization and 1337 makes each word worth a little over 18 bits. 4 word phrase is equal for a bruteforcer to a 10 full ASCII characters password, while being a lot more memorable. Yes, you'll pick those words from dictionary, which probably confused you, but it's the same as picking characters from alphabet for bruteforcing.
Re:What's really needed... (Score:5, Informative)
Here's why that doesn't work. The attack is very, very, very simple, and once you see it explained, you'll never trust those sorts of services again. A basic attack looks like this:
Elapsed time: tens of milliseconds after the user logs in. A slightly more sophisticated attack looks like this:
Elapsed time: tens of milliseconds after the user logs in. And if the service you're logging into works the way most services do, an even simpler attack looks like this:
Elapsed time: zero milliseconds after the user logs in. But the best one of all is this:
Elapsed time: zero milliseconds after the device is first compromised or GA is first installed.
All four techniques are 100% transparent and are 100% effective attacks against software-generated time-based authentication schemes. The first two are 100% effective against hardware tokens used for time-based authentication, too. In fact, even if Google upped the ante and made the authenticator be interactive, where the Google servers sent a unique nonce that had to be encoded along with the time stamp, this scheme would still not be significantly stronger. The only change required to the first two schemes would be adding one additional step—telling the attacker's server to issue a request to Google and pass that request nonce to the compromised client. And the third and fourth schemes would continue working as-is. This is why time-based authentication is basically worthless unless the endpoint is trusted (and at this point, I'm growing more and more convinced that users should assume that their endpoints are not trusted).
The reality of the matter is that time-based authentication schemes are an anachronism. When they were first conceived by RSA in the mid-1980s, they were not intended for general users. They were intended to protect against precisely one threat—an attacker with a very specific target watching a user type in his or her password from a distance. They work well for that purpose. They can be compromised once by any attacker who gains control over the system where the authentication token is being entered, even if hardware tokens are involved, and they are permanently compromised by any attacker who gains control over the system where the secret key is stored. The reason there haven't been very many new implementations of time-based authentication since the 1990s is that such schemes just aren't particularly useful against modern attacks. They give the illusion of security without actually adding any. Well, unless you're worried about your roommate seeing you enter your password.
Put another way, creating a secure authentication scheme where the endpoint is compromised is fundamentally impossible for precisely the same reason that perfect DRM is fundamentally impossible. Alice is also Eve and Mallory. Food for thought.
Re:Indeed. Most strength checkers are quite wrong (Score:4, Informative)
coherent english phrases have approximately one bit of entropy per character. your sentence wouldn't be that unusual if crackers were using the appropriate tools (which of course they aren't).
the xkcd example works better because it's nonsense. to see it intuitively, "eats cherry" is a common 2-gram (although salaciously ambiguous out of context) whereas "horse battery" is uncommon (as is its referent).