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