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:
- Length
- Composition (e.g. digits, special characters)
- Dictionary membership (in any language)
- Don’t write it down
- Don’t share it with anyone
- Change it often
- Don’t re-use passwords across sites.
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.
Taking 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.
Give up user name and password pairs, simple as that.
jmdesp: 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 :-)
jmdesp, 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é?
The 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
> 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
Exactly!
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).
Like Jonadab, my perspective is a little different.
First of all, I work in an environment where we have all kinds of “strong password” requirements. From my experience, I have to reset passwords for people who have recently changed their passwords and people who have been off work for a while. If you’re already using strong passwords, (i.e., 12 characters including a mix of upcase/downcase/numeral/specialchar that don’t spell a word in any known language and have no quality that would make them memorable for you or anyone else), most people shouldn’t have to worry about dictionary attacks. For this reason, I cannot stress enough that passwords shouldn’t have to change more frequently than yearly.That is, unless you, as a site admin, like having the user do daily password resets for a while.
Secondly, most people use the same two or three passwords everywhere. When they do this, that forum they joined and never revisited (the one that is still using the same software from 1997, when storing passwords with minimal encryption was still acceptable), when it is penetrated, will have username, password, full name, and e-mail address, which could then open up other sites.
I think the solution there is to stop trying to remember passwords at all. Passwords *must* be written down and kept in a safe place (the sticky under the keyboard doesn’t count). Even better, users should have something like KeePass (or Password Safe or Password Gorilla) on their flash drives and let that be their memories. If I can remember a password, it is vulnerable in today’s threat environment.
Once people are used to tools like KeePass, they no longer need to use the same password(s) for every site.
Third, once we have users using KeePass, there is no reason why passwords should be less than twelve characters long. I know two passwords: one to get into my computer, and the other to unlock my password database. Beyond that, they are all in the database. So since I no longer need to remember them, why shouldn’t they be as long as each site allows, with the full mix of supported characters?
Fourth, every user account should be paired with at least one OpenID. That way, when the user doesn’t have his memory stick handy, he can use Yahoo or Google or Facebook as an alternate way to get into his account. Chances are, he (or she, but “he or she” is a lot of text to type repeatedly) uses those accounts often enough to remember the password, but might not remember the password for less-frequented sites.
Fifth, those “what was your cat’s grandmother’s uncle’s name” questions have got to go. There was one such question where I didn’t know the answer, but found it by doing a web search. We have ancestry records, birth certificates, and everything else you can think of available to anyone who can spell “Google”, so they don’t help. In fact, since there are only a limited number of such questions that are meaningful, each additional site that requires this information makes it a little less secure. (Do you hear that, YHOO? Are you listening SLMA?) This information is sitting in the databases of online forums, news sites, webmail services, job boards, and chat rooms all around the WWW, just waiting for some bad guy to break in and take it.
Don’t use those questions. Got it? Good.
Sixth, Password length: once we establish that holding passwords in memory isn’t working, and that therefore, users should be using KeePass or a similar tool instead of trying to continue using human-memorizable passwords, there is no longer any justification for accepting or allowing short passwords.
I recently cancelled an account that dates from at least 1995. Why? Because I was unable, after months of working with the service, to switch out my 1995 password for a more modern password. What made it worse was that they continually sent me my username / password information in e-mail messages as the process moved onward, so I knew they hadn’t hashed it.
The other thing is that I knew I had a set of about twenty-five passwords to go through (hadn’t used this account in years) and I just entered a couple each day until I was in. That was when I started trying to change the password. Not good, because anyone who knows me from that time period can probably guess the password fairly quickly.
Seventh: password comlexity: If a site allows special characters, it should accept every character in the language/encoding/charset being used. Why accept “!” but not accept “@”? Users don’t understand this (and if you’re sending this information unsantized through the shell, you’re too dangerous to be taking their information anyway). If you accept special characters, accept special characters. Otherwise, don’t accept them, but make the password length requirement a little bigger.