Three challenges to making passwords user-friendly
Following the interview of Bill Burr, author of NIST’s 2003 paper on Electronic Authentication, in which he announced that he regrets much of what he wrote, we stop and think.
Why was the standard putting users at risk? Paraphrasing History: “Tout pour le peuple; rien par le peuple”. Perfectly correct from a theoretical point of view, the standard failed to acknowledge that users are indeed people, and when asked to follow too complex rules they will find “tricks” to help themselves to remember their current nightmarish password. Of course, said tricks are fairly easy to guess by any decent hacker, let alone an educated computer.
Nothing new here, the user is often and unfairly considered as the problem. But since there is no easy way to fix the user, it is up to us, as security and IT professionals, to design and build our systems to make them more resilient to human mistakes, and maybe some laziness.
Ah, those funny stories on predictable passwords
The problem with the previous standard wasn’t that it was advising people to make easy to crack passwords, but that too complex rules steered users towards the path of least resistance: very complex and very predictable passwords.
I remember working in a team where, by knowing how long one of your colleagues had been around, you could easily guess their password, applying the simple rule of Company_nn, where nn was the number of the rotation of the password.
So, what now ?
Three challenges to making passwords user friendly
The new NIST 800-63 special publication, and previous publications such as GCHQ’s NSCS guidance, turns the approach upside down: make your password policy user friendly and you’ll get better security. A simple idea: put the burden as much as possible on the verifier, not the user. With one dream: create security that works no matter what the people do. Is it all that easy ? Let’s look at three recurrent challenges we’ve encountered at our clients:
1. Make it hard to guess with blacklist check
What is this about?
Forget complexity and just make sure you don’t use a word from the dictionary, a known first or last name, or a commonly used password (based on public lists of breached passwords). Now, this is easier than done.
Why is it a challenge?
While quality password blacklists can be found online, neither the blacklist validation mechanism nor the integration with frequently updated blacklists is proposed in most systems and applications on the market. Azure AD, for example, has offered this functionality for only a year, and its scope remains limited. And then, most organizations use a local AD. Or something else that doesn’t have such a native password validation check.
So what ?
There are workarounds of course, but they’re not always robust and imply manual maintenance of a blacklist – an effort many organizations are reluctant to commit to. It will be interesting to see how the market catches up on this one. Until then, well, most system admin prefer to keep some complexity requirements on.
2. Make it easy to remember by promoting the use of passphrases
What is this about?
Lengthy passwords, such as passphrases, are much more likely to integrate human randomness: easy to remember, yet almost impossible for an automated system to make sense of when properly done. As usual, xkcd got it right.
Why is it a challenge ?
While passphrases are a simplification on paper, especially if complexity requirements are dropped, they’re also a new paradigm for most end-user. Let’s face it: 24 characters password sound scary and users are clearly reluctant to commit to this. We’ve tested this on a few friends: after some enthusiastic explanation from our part, they agreed to switch.
For the first few days, our names were accompanied with words that weren’t exactly kind. After a week, the cursing had disappeared and they got used to typing long passwords, often several times to get it right. With locked out increasingly replaced by password throttling, frustration was luckily enough not turned into user being locked out.
But only a few passwords were changed: replacing all passwords in use meant inventing tens of completely new password, based on a completely new reasoning.
So what ?
This tells us that Awareness and communication is needed to make mentality evolve. Maybe re-using some of the good Belgian material of our friends at safeonweb.be. Even like that, you may wish to focus your effort on one specific password – typically, their Windows password.
But this also tells us that users should only have to remember 4 or 5 passwords: the rest should be in a password vault. Here too, it’s about changing users habit. And again, this works fine until you want to connect from another device than the one hosting the vault. Who said Cloud? But that’s another debate.
3. If it’s still a secret, why change it?
What is this about ?
NIST has gone bold on the advice: only change password if you think (or know) it’s compromised. Don’t have them recurrently expire, this is exactly how passwords become predictable. Of course, this only works if other NIST recommendations are implemented, especially increased length and blacklist check.
What’s the challenge ?
It’s like Perfect Information of consumers in economics: in theory, we should all know everything. But look around and you’ll see it may take months or years to find out your users’ passwords were stolen – not to mention they might have been using that password all over the internet.
So what ?
The best friend of “no expiration” is “second factor”, making sure the memorized secret alone won’t let them in. Of course, with cost of these things and their inherent complexity, you’ll probably select risk-based on which layers and Apps you want to implement it – or even better, go for a common authentication portal that supports adaptive authentication.
What does this all tell us, then ?
That the world is moving to user-friendly security, at last. And the best part is: it’s doing it because old security didn’t work. But it also tells us that these things will be complex to implement, because systems are not ready, implementation will prove complex, and users have to unlearn what we’ve spent the last 20 years pushing into their brains.
This is essentially what our colleague Benoit said on TV a few weeks ago, in case you missed it, you can watch it here.
