Making passwords easier

We’re in the process of changing our password policy, and the software that enforces it. For some time now the advice has been that passwords must be long, obscure, contain “special characters” (whatever the hell that means?), at least a number or two, and so on. The accepted wisdom being the less “predictable” a password is, the harder it will be the hack.

The interesting thing about this is the law of unintended consequences that followed it. Firstly, people just started doing all kinds of obvious things to circumvent the rules. If their password was “password”, they’d change it to “Password1!!” — yay, it passes the check! Hmm… That hasn’t helped us much though, has it?

And even if you make someone have a password like “xwskiYi\m2kkSouiin4o” (I just made that — catchy, isn’t it?) what are they going to do it with it? There’s a fairly good chance they’ll do one of several things with it, all of which are bad for the security posture of your organisation. They’ll probably:

• write it on a Post-it;
• save it in their browser passwords;
• set anything using it to “Remember me” (if that’s an option).

So sure, they have a secure password. But they’ve done several insecure things with that password. Oops.

And let’s not ignore the fact that making people come up with a password that has ten characters, two upper case letters, three special characters, a number and at least one emoji just makes them angry.

Password vault software tries to do something about this. Apple’s “keychain” software that ships with Mac OS-X is a local system example. There are also web-based password vaults like LastPass, 1Password and their ilk. But all these systems are problematic too, because at the base there has to be a master password. And that there is the weak link in the chain.

There are mitigations for this too, and indeed this is why we at Code Enigma already enforce a second factor of authentication on our choice of password vault software at an organisation level. But, aren’t we sticking band-aids on the band-aids? I mean, passwords are terrible, they need to die in a fire, but in the meantime it’s pretty clear that our current password thinking, in an attempt to be secure, is actually resulting in, at best, insecure user behaviour — and at worst, a false sense of security (while users make lame passwords to circumvent rules, which are just as easy to guess as they ever were).

So goes the thinking of the National Institute of Standards and Technology (NIST) who have recently altered their best practice guidelines on passwords. The bottom line on their thinking is this:

There is no password more secure than something long that a person can remember without recording somewhere.

To that end, they now recommend you:

• do allow all Unicode characters without exception;
• do not enforce complexity;
• do enforce a minimum length of at least 8 characters;
• do prevent known bad passwords by using a dictionary of “bad words”;
• do not expire passwords, unless you know them to be compromised;
• do have multifactor authentication, wherever possible.

It makes logical sense and, more importantly, it’s evidence based, coming out of observation and study of the recommendations of five years ago, and the impact they have had (or perhaps, have not had) on password security.

Length is one password control they recommend you do not stop enforcing. This is just basic mathematics, if someone has to use a powerful computer to try to break a password, the longer it is, the more possible combinations exist, the longer it is going to take to crack. And by a significant factor for each additional character in length!

But mathematics aside, from a human perspective if someone has a password they know — providing it is long and not containing anything silly like their name, company name, “password”, and so on (there are free dictionaries you can incorporate into your password checking app) — they will not write it down, they won’t need a password vault, they won’t need to make applications remember them, it will be more secure.

And for heaven’s sake don’t force them to change it after three months if there’s no evidence of compromise, otherwise they’ll have to re-remember a new one all over again. (Or write it on a Post-it.)

Taking this new thinking on-board, this is the approach we have decided to take at Code Enigma. Our new password policy is simple. Passwords will:

• be a minimum of 12 characters in length;
• contain at least 2 upper case letters (we see no harm in making the set larger while keeping it simple, people can simply chain two words);
• be checked against the NIST dictionary and our own custom dictionary;
• not be expired unless we suspect they are compromised.

This way people can have long passwords they will remember and (we hope) they won’t be writing on Post-it notes. And we also hope they won’t become enraged while trying to come up with a password!

As an aside, we’re also rolling out a second factor of authentication using a combination of LinOTP and SimpleSAMLphp (see our open sourcing of our modifications to the necessary module) which we are likely to make mandatory. We already had 2FA via YubiKeys, but we wanted to open up more options to people before enforcing 2FA. There is no better defence against bad passwords than not relying on passwords.