Cormac Herley of Microsoft Research recently published a paper called "So Long And No Thanks For The Externalities", which highlights the cost to users of security advice. His point: user time is not free, and there are a lot of users, so that adds up to a massive cost, which often outweighs the harm that the advice is trying to avoid.
He focusses on 3 areas of advice-giving: Password Rules, URL Reading (to avoid phishing) and Certificate Errors. This blogpost is about Password Rules.
The 7 rules most often cited are these:
I won't recap his entire argument (read the paper) but his point is that they all impose a cost, and don't actually provide significant mitigation against common attacks.
Basically, he's right. Here's my alternative proposal.
Sites should abandon putting any restrictions beyond the most basic (longer than 3 characters, not your own name) on passwords, and should not give advice like the above. Instead, they should measure the strength of the password chosen. If it's weak, have a 5-unique-strikes-and-lockout policy (unique strikes, so that a client attempting to authenticate multiple times with a mis-typed or old password doesn't trigger the lockout). If it's strong, have no lockout (but perhaps a rate limit).
This means that most people can pick weak passwords with a much reduced risk of brute-forcing, and those people who are concerned about DOS (someone keeping them locked out) can just pick a stronger password and have the lockout removed. You don't even need to explain any of this to the user; users who might be disliked enough by those with the technical capability to mount a sustained DOS are few and far between, and are much more likely to pick strong passwords anyway.
The principle here is to take the load off the users and put it on the technology. Such a scheme is more complex to implement server-side than a simple "hash the password, compare it to the stored one, if it's the same, authenticate" mechanism which sites have been using for ever. But it's likely to provide a much greater increase in security than giving advice which is generally ignored.
Posted by gerv at November 26, 2009 10:36 AM | TrackBackTaking the load off the users and putting it on the technology, right.
But we should go further than what you describe here.
I think the true answer is to kill the password, plain and simple.
People are abysmally bad at handling password, creating them, remembering them, everything related to them. Why should they have to do that ?
Why can't the browser generate the password for them ? We do password auto-filling already, let do the last step.
And then, when they will be asked to enter their password at a site that looks the same but doesn't really have the same URL, they simply won't be able to.
The browser won't auto-fill a saved password, and will not generate the same password.
I'm not saying that wouldn't be difficult, what to do about sites that ask you your password on page with a slightly different URL ? (hint: whilst the URL are slightly different, if they belong to the same owner, that should mean they have the same suffix. And you have a suffix list that you can really trust, you can automatically detect this), what to do if the configuration is destroyed (but users already often loose their password), all of this needs to be taken into consideration.
But even a slightly imperfect solution would be much of an improvement over the current mess.
Some of those rules are a *lot* more important than others. Some guidelines:
First, in practice, if your goal is to choose a password that's harder to brute force, making it a little longer is *MUCH* more effective than changing up the composition (e.g., by throwing in a punctuation mark). I have run the math on this, and something like ydrnnownbbthyeuy has half again as much inherent complexity as something like 6a\W32!F, even if the attacker *knows* whether you're using all lowercase, whether there are punctuation marks and numbers, etc. And in practice a lot of attackers (especially automated attacks like worms) won't be able to assume that, in which case longer definitely wins out over a more complex charset.
Even throwing in multi-byte characters is not as good as increasing the length by the corresponding number of bytes. If your password has one four-byte character in it, that character *at best* could only be as good four regular one-byte characters, and in practice it's not nearly that good, because almost all of the theoretically possible four-byte strings aren't actually characters. So yeah, length improves security more than charset complexity does.
Making the password a straight-up unaltered dictionary word is insecure against dictionary attacks (which are fairly common), so for a password that does in fact need to be secure (more notes on that very important point below), I would strongly recommend against straight-up dictionary words.
However, I think the risks involved with *basing* a password on dictionary words has been significantly overplayed. If you use a decent-sized dictionary (like, /usr/share/dict/words for instance), there are tens of thousands of possible words, and so stringing three random dictionary words together makes a stronger password (more mathematical complexity, more possible combinations) than eight random mixed-case alphanumeric characters. For added bonus points, it's also significantly easier to remember, which is important. Which would you rather try to remember, MQuvnpMwbBKI, or unisomeric-morgan-funariaceous-Bethlehemite? The latter is a stronger password, even if the attacker *knows* that you strung dictionary words together with hyphens to make your password. If he doesn't know that, then it's *WAY* stronger.
I strongly disagree with #4. With rare exceptions, all passwords *SHOULD* be written down, and kept *somewhere*, ideally in a location that's at least as secure as the account that the password protects. In practice, for most users, writing the password on a little slip of paper and putting it wherever you keep important documents (like your birth certificate and whatnot) is probably a good compromise. There are a lot of reasons to do this, the biggest being that your memory simply isn't as reliable as you'd like it to be, *especially* when it comes to things you don't use every day. There's also the question of your family being able to access things if you fall under a bus.
> 5. Don't share it with anyone
Well, duh. Actually, that's "don't share it with anyone whom you don't intend to give control of the account to", but that's nit picking.
> 6. Change it often
I strongly disagree with this one. I understand the reasoning behind it, but the cure is worse than the disease. (That's in general; there are exceptions, of course.)
> 7. Don't re-use passwords across sites.
Depends. For accounts that need to be secure, this is sound advice.
But most people (network administrators being an exception) only have one or two accounts that actually matter, if any. If you use the same username and password on a bunch of inconsequential web fora and such, what are you risking? A bunch of inconsequential accounts that you can replace more easily than trying to dig up an obscure one-off password every time you visit the site. So, yeah, in a lot of situations the risk is a good trade-off.
That's a general principle, not just for passwords but for everything: the level of security you implement should be commensurate with the importance and value of the assets you are protecting.
I would add another rule: If the facility exists for a "Security Question" that allows the password to be recovered or reset if forgotten, make the answer to the security question at least as secure as the password itself. Otherwise any security you put into the password is completely pointless. It's like putting six titanium-steel deadbolts on the front door and leaving the side door unlocked.
> Sites should abandon putting any restrictions beyond the most
> basic (longer than 3 characters, not your own name) on passwords
Agreed. In fact, if a site *requires* certain things (like, it must contain a numeric digit), then that gives the attacker knowledge about the composition of the password. And if we're talking about any normal kind of site, most users don't value their accounts enough to justify such restrictions. You're just annoying people. Stop it.
> If it's weak, have a 5-unique-strikes-and-lockout policy
> (unique strikes, so that a client attempting to authenticate
> multiple times with a mis-typed or old password doesn't
> trigger the lockout). If it's strong, have no lockout (but
> perhaps a rate limit).
If denial of service is less of a problem than a compromised account, just increase the mandatory waiting period geometrically based on the number of successive failed logins. I'm assuming here that a sysadmin can reset the thing and clear the failure counts in the event of a major DOS fiasco. Doubling is probably two steep. *= 1.25 or so is probably more reasonable. That's steep enough to effectively shut down brute force attacks against all but the most infamously weak passwords (think: birthdate, year of high school graduation, mother's maiden name, favorite sports team).
If denial of service is at least as bad as letting an unauthorized person in (which, IMO, is pretty rare), then a constant rate limit would be better.
Posted by: Jonadab the Unsightly One at November 26, 2009 9:33 PMGive up user name and password pairs, simple as that.
Posted by: Eddy Nigg at November 27, 2009 4:58 AMjmdesp: what you propose has been tried several times before, with things like PwdHash. They normally fall down because users cannot transport the password-generating algorithm with them wherever they go. If the algorithm was built into every browser, it might work.
Jonadab: several good points :-)
Posted by: Gerv at November 27, 2009 9:41 AMjmdesp, Gerv: what if one used Weave (or equivalent) to sync those passwords across devices, and a webservice frontend to it in case the user is using someone else's machine / an internet café?
Posted by: Gijs at November 27, 2009 10:42 AMThe web service front end is the usual solution to the Internet cafe problem. It's bad in a few ways, mostly because it's clunky. You'd have to load the site, paste the URL into it, type in your password, press "generate", then copy and paste the result into the login box in another tab. You might be able to reduce the work with a bookmarklet.
Weave doesn't actually gain you much if you already have a site-specific-password generation algorithm built into the browsers. Of course, it helps if you don't have that :-)
Also, password generation algorithms can fall down because every site has irritatingly-different password rules. You can try and get an algorithm that meets most (8 chars long, mixing numbers, letters, UC and LC) but it can never be 100%. Some require punctuation, some forbid it. :-|
Gerv
Posted by: Gerv at November 27, 2009 10:54 AM> 4. Don't write it down
> 7. Don't re-use passwords across sites.
I think this should not be a problem at all. I'm a system administrator and i have to handle round about 50 passwords. Every one of them is generatet by a algorithm. This is not a problem because i use a password manager (Revelation
I think this is something that one can expect to be accepted by the user.
Jonadab the Unsightly One made up some interesting points about how a password can be save without cryptic character combinations. This is really interesting because (blanks only for your convenience)
"the crocodile falls asleep and the beagle is dancing all night on its back"
is simple to remember and according to Jonadab way more secure than
"dösWEFlkvW$%23Dvw("
(if i get Jonadab right)
Martin
Posted by: Martin at November 27, 2009 4:22 PMExactly!
Currently I'm writing a 3-part-series about passwords
and password-safety for my German blog. I released the
first part 2 weeks ago and I'm planning the second part
for the next week:
http://www.anonym-surfen.com/regeln-fuer-sichere-passwoerter/
My conclusion during writing and investigating for the series
was: the most lists and reports for password-safety results in nothing.
Most people read about BruteForce and things like that
and recognize the threat. But they don't know any victims.
The threat seems to be far, far away.
Finally, the costs to implement all the effective password tips
seems not to be worth it.
My recommendation is to reduce the complexity to an acceptable
"work". It's better to have implemented some tips and rules than
to ignore them all because it is too much work.
Your recommendation sounds good, too. I hate services who want to ensure
my password safety by forcing me to choose a password with minimum 8
characters and to have at least one number and one upper char.
It should be my decision. Everywhere.
If they want to help their users, they should implement more
complex mechanisms than just hashing the password.
FOSDEM 2010 requires a "long enough" password with all of: uppercase letters, lowercase letters, digits, and punctuation. So they won't accept "wudfg1hx" but they do accept "You1Suck2Big3Time4!!!" Now which one do you think is more "guessable"?
I like your proposal except that for "weak" passwords I feel 3 trials is enough (that's what my bank's cash distributors offer -- not 3 trials each time but 3 trials /in toto/ -- before the card gets "eaten"; but the "password" is a 4-digit number).
Posted by: Tony Mechelynck at January 7, 2010 10:47 AM