Uppercase, lowercase, number, symbol – it’s the mantra repeated over and over by IT admins when they set password rules. Throw in the requirement to change those passwords every 30 days or so, and not repeat an old password or even have characters in the same place over some arbitrary cycle and you suddenly have a complex set of rules that makes life really hard for users. And the guy who penned many of these rules, Bill Burr from NIST, says he screwed up.
An article published on the Wall Street Journal [paywall] quotes Burr as saying NIST Special Publication 800-63. Appendix A, an 8-page guide that defined the rules most people base their password policies on today, was flawed.
“Much of what I did I now regret,” said Burr, the now retired septugenarian.
Last year, I MCed an event with famed hacker Kevin Mitnick where he demostrated a number of things.
Firstly, he asked an audience member to create a “complex” password that filled the common eight-character rules we are all familiar with. Using a cloud-based system utilising some powerful GPUs he was able to brute force that password in well under a minute.
He then asked another audience member to choose a longer, but easier to recall passphrase, something like “i have a black dog”. The same cracking tool was unable to crack the longer, but far easier to remember, passphrase.
In another demonstration, Mitnick used a hashed and salted password he accessed from a “public” forum where stolen passwords are available. He simply copied that stream of unintelligible characters, pasted them into a search engine and was able to access the original, unencrypted password.
This was possible because of two things. Firstly, once a password is cracked, threat actors share their work. And, faced with a complex array of rules, users use simple passwords or re-use them in order to make their lives easier.
If we think of those password requirements, we can see that they are predicated on the belief that they will be stolen. The need to regularly change passwords is based on the belief a password will be accessed by an unauthorised party. So, we change passwords regularly so their opportunity to use them for an extended period is limited.
Of course, there’s also the issue of how many different passwords we have. When Burr wrote his rules in 2003, the number of user accounts we had to manage was quite small. When I looked in my password manager today, there were dozens of different user accounts.
We made security the user’s problem
Burr’s rules, which were widely adopted, moved the onus for securing access to systems away from system designers and network managers to users. Instead of having to securely architect systems so access is tightly managed so a compromised account can’t bring down an entire system, we placed complex rules on users.
Of course, we still need users to protect their user accounts, but there are other ways to authenticate a user’s identity when they access a system.
What’s the answer?
There’s no simple way around our “addiction” to passwords but there have been some steps forward.
For example, single sign-on systems, that reduce the number of passwords we need are prevalent. There are some open standards and authentication services that are making life easier as well.
For example, many companies are using Facebook’s authentication as a way for users to connect. Users taking advantage of such services are given limited access to systems and services while more rigourously authenticated users are given higher levels of access.
While that doesn’t negate the use of passwords, it reduces the number of passwords you need to remember.
Mult-factor authentication is helpful. I’ve been using the authentication apps released by Microsoft and Google, as well as Apple’s two-factor systems for some time. All work well and mean I don’t need to remember passwords. I can set a long, random string of characters and never need to re-use it again.
Biometrics are also getting better and more affordable. I first started playing with fingerprint scanners in the early 2000s and they weren’t very reliable back then. But the systems deployed on modern smartphones have come a long way.
Facial recognition, like the Windows Hello system and the anticipated addition of a similar function in the next iPhone, will bring another option to system designers seeking to prove the identity of users.
The challenge comes from legacy. Not just systems but also assumptions and behaviours.
We need developers to think beyond the traditional approaches and use new authentication standards that aren’t based on 2003’s paradigms. That means hooking into the APIs and services that take advantage of new ways of proving identity.
While Burr’s work at the start of this century might have been reasonable at the time, the world has moved on and we need new ways to authenticate users.