Password Strength Testers Work For Important Accounts

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

Comments

Minor difference at best

[icebike]

The long and the short of it: Not Much!

Users, despite a barrage of news about stolen credentials, identity theft and data breaches, will re-use passwords over and over, especially at account creation, regardless of the presence of a meter. If the context changes, however, and users are asked to change existing passwords on sensitive accounts, the presence of a meter does make some difference.

They claim it was for "important accounts" but how important would the account be that was being used in a study?

Lots of people re-use passwords on "nothing accounts" simply to prevent having to remember a gazillion passwords.
That doesn't mean they reuse all passwords.

Its probably more important to not log in using the same user name on many different sites than it is to have passwords consisting of crazy strings of random characters that you can't even type consistently let alone remember. If someone guesses your re-used password in one site they have a much better chance of guessing your other logins.

Re:Minor difference at best

[jrumney]

90% of accounts I have created were so I could read some support documentation, or download an updated driver from a vendor etc. The only reason for putting password protection on such things is so the vendor can spam me in future. I really don't care if such accounts are compromised, in fact, I actively use obvious username and password combinations along with fake, or if they require confirmation before activating the account, throwaway email addresses. Another 9% are sites like slashdot, where the account gives some convenience, but nothing of value is stored there (a bit of reputation is at stake if someone hacks the account and uses it to troll, but the damage is minimal and easy to explain away). For the other 1%, I'll care enough to create unique passwords that are difficult to crack.

The forced registrations on many sites drive reuse

[luvirini]

The growing number of places you need a password on just to access some content is a sure cause for increased password reuse.

Humans are simply not suited to remembering random enough password to cover all the sites on internet.

The save password option on the browser might help...

but more and more sites use the "no not save passwords" option.. forcing people back to reusing passwords.

Well, personally I just use fairly random passwords and "rememberpass" extension on firefox to force saving password even when the site does not want you to do that.. as the lesser of the evils.

Re:What's really needed...

[msauve]

Oh, yea. Obligatory Dilbert (better than XKCD in this case).

Re:What's really needed...

[Exitar]

http://xkcd.com/936/

So?

[Smallpond]

Now tell us what percent of breakins are due to guessing passwords. Maybe 2%. The rest are social engineering, default accounts, keyloggers, vulnerabilities, malware, misconfigured networks and people leaving their phones in bars.

Re: What's really needed...

[Anonymous Coward]

All well and good if the sites would stop implementing arbitrary password length limits.

Re:What's really needed...

[dgatwood]

The FIDO stuff sounds like a whole lot of expensive extra technology with no real benefit over a password. A finger swipe is a replayable event just as much as a password or PIN.

The Google Authenticator is conceptually okay in theory, but in practice, AFAIK, it too becomes a gaping security hole as soon as your mobile device gets compromised.

If you want something stronger than passwords, it must have the following criteria:

1. Immune to replay attacks. Done correctly, this means that each authentication request must have a unique ID that must be signed or otherwise combined with some shared secret in a secure way.
2. Immune to man-in-the-middle attacks. Each request for authentication must be signed by the requestor so that the user can be certain that he/she is not agreeing to do something other than what is intended. Each response from the user must include at least a hash of the original request.
3. Immune to device compromise. The most common way that computer security is breached is through password sniffers or other compromise of the user's computer or mobile device. If you cannot trust the device that is performing the authentication, you cannot trust the action being performed, and all security goes out the window, including existing measures for preventing MITM and replay attacks, such as SSL/TLS.

None of these schemes I've seen so far address #3, and as a result, none of them are significantly more secure than typing letters at random and pasting the resulting password into a text file on your Desktop. They try to address problems that don't actually exist, while failing to address the root of the problem, which is that computers, mobile devices, etc. are not inherently secure.

For example, Google Authenticator uses a time-based token. This tries to avoid replay attacks by limiting the period during which an attack is possible. That doesn't work very well, though, unless you can delay an attacker's ability to sniff that token. This means that you have to prevent a MITM attack. As soon as the device is compromised, SSL and TLS are no longer capable of preventing a MITM attack, so the entire scheme falls apart.

Anything short of a non-networked device communicating with your computer over a very simple protocol (think "formal verification" here) is not a major win, IMO. And it can't be something silly like touching a smart card to an RFID reader, either, because the reader could perform more than one transaction, and you would have no way of knowing that you just bought some farmer in Iowa a new tractor alongside that DVD from Amazon. No, you really need a physical screen and a button on the device saying, "Do you agree to transfer $258,000 to Bank of Nigeria?" in order to significantly improve things. Anything short of that is just wasting a lot of time and expense without addressing the real problem—that if you can't trust the endpoint, you can't trust the message. Start by developing a truly trusted endpoint. After that, the entire problem becomes fairly trivial.

Re:What's really needed...

[fostware]

But all my passwords are "correcthorsestaplebattery"!

Re:What's really needed...

[Carnildo]

If you actually do any PW cracking, you'd know that comic is wrong. Dictionary attacks with not just words, but with phrases and 1337 replacements, and exclamations, and numbers after or before or in between words, runs of N repeating characters to 'pad out' a password, etc, all get tried before brute force.

If you understood combinatorics, you'd know that the comic is right. The first row is a password made from known tricks, and is probably in a dictionary (the 28-bit strength represents the size of the smallest dictionary likely to contain it, or how far you need to go through the dictionary before running into it). The second row represents a password generated randomly from what is effectively a 2048-letter alphabet.

A thought..

[SuperCharlie]

Maybe a brainfart..but here goes..

Has anyone worked on a time based password system..such as.. the timing between the entry of the characters? So 11 then isnt the same as 1 1

I find that I have a few passwords that I use that I end up with a typing rhythm for certain character sets. I could logically break and wait on some.. or speed some up and slow some down consciously.. the intent of course being to add another completely random variable into the password thing..

You could have different timing resolutions for different levels of security. Imagine the difficulty of a password with only 2 characters exactly 1.756 seconds apart .. with a resolution of .002 seconds..and someone who can flip a coin, catch it, and click the second character consistently because of muscle memory and repetition. (random specs..but you get the picture)

And then the same scheme with a 1.5 second resolution for not so strict security. (again..random specs..but you get the picture)

Of course you would have words or phrases with timings in between so that...

"the l a z y dog" isnt the same as

"t h e lazy do g"

simply by the timing between the characters.

You would need to add or change passwords by typing them a few times until you can get the timing right for the resolution..and I would think a test or two before setting the password with timing..somthing like the voice recognition training...

and theres my brainfart for the day..enjoi.

Re:What's really needed...

[dgatwood]

I think that Google Authenticator tries to prevent mitm attacks by having any given token usable exactly once in addition to having a very short lifespan.

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:

1. Attacker compromises the device and waits for user to log into Google.
2. Attacker captures the response to the authentication request and forwards it to their own server.
3. Attacker's server connects to Google's system and obtains credentials.
4. Attacker displays a network error message to the user. The user logs in again to the real Google server, unaware that the first attempt was successful, just for somebody else.

Elapsed time: tens of milliseconds after the user logs in. A slightly more sophisticated attack looks like this:

1. Attacker compromises the device and waits for user to log into Google.
2. Attacker captures the response to the authentication request and forwards it to their own server.
3. Attacker's server connects to Google's system and obtains credentials.
4. Attacker masquerades as a forwarder for Google's server so that the user is completely oblivious.

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:

1. Attacker compromises the device and waits for user to log into Google.
2. Attacker steals the cookies that Google stores on the user's system and uses them on another machine.

Elapsed time: zero milliseconds after the user logs in. But the best one of all is this:

1. Attacker compromises the device and steals the private key used to generate the authentication token.
2. Attacker logs in at will. From anywhere. At any time. Forever and ever.

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.

No kidding

[Sycraft-fu]

I'd say I'm a pretty security aware individual, what with working in IT and all that. I do defense in depth on computer and physical security, I'm proactive about things, etc. Seems to have worked, I've never had a system owned.

So I never reuse passwords, right?

Wrong, I do all the time. Almost every forum online I have the same password for, and it is a weak one. Why? Because I don't care. Oh no, someone might hack my forum account and... I dunno, post something as me! Whatever would I do? I'm not going to bother to generate a great, unique, password for every site.

However my bank account? Random password (I don't seem to have trouble remembering them), long, and it requires two factor authentication. That protects my finances, and those matter. So security on that is pretty high.

The idea that everyone is going to have a high security password for every site and not reuse it is silly. There are plenty of things where if your account got compromised, you just don't care so much.

Also it can make sense to group systems. All my systems at home use a single password. There is no reason for them not to. They are all in the same security context, basically. It is no different than at work where my single account gets me access to any domain system.

So people choose strong passwords...

[theedgeofoblivious]

And then they write them down, stick them on sticky notes, and put them under their keyboards, or in their drawers, completely destroying the security, but maintaining the administrators' beliefs in it.

It's almost as good of an idea as making people change their password once a month, which also encourages people to write them down, re-use their weak passwords or choose passwords that are easy to guess.

And how about those password retrieval questions?

What's your favorite color or your mother's maiden name? No one can guess those.

Not really checking password strength

[mwvdlee]

To most of those password checks I've encountered, "P@ssw0rd" is very strong, but a thousand random digits is unpermissably weak.