Everything You Know About Passwords is a Lie

Written by Joe Kozlowicz on Thursday, August 10th 2017 — Categories: Security

Well, maybe not quite everything.

You still need a strong — and long — password. And you still want unique passwords for each of your credentials.

But you don’t need to add any special characters or numbers, at least if you don’t want to. And you don’t need to change your password every month, or every week, or every day (even if it feels like the IT department is making you change it that often).

Here’s why experts are no longer recommending passwords like k1TTyc@7z or @ppl3Be3s — and what they say you should be using instead.


Who came up with the requirements anyway?

Previous guidelines for strong passwords were suggested by the National Institute of Standards and Technology (NIST), an agency of the US Department of Commerce that creates measurement standards and references for communications, energy, health, quantum science, manufacturing, and more.

Bill Burr, a manager at NIST, wrote the original document NIST Special Publication 800-63, with Appendix A giving the now-common recommendation of random capitalization, use of special characters like @ or !, and a minimum of one number. NIST also added other widely adopted measures like mandatory change requirements every few months.

The theory behind these requirements is that they will create a more secure environment by making the password harder to guess or crack with a software program, because users are forced to create more unique passwords not made of only letters, while also having to refresh them every so often in case the password was leaked or written down somewhere.

Burr now says he regrets helping to spread these practices, as many studies have shown that some aspects of them actually create less secure passwords.


Wait, I don’t need to use !@#$%^&*() in my password?

Users tend to use the easiest password possible, so the special character requirements usually result in the substitution of a special character for a similar-looking letter. This makes the special character barely more difficult than the letter to guess. When you always substitute “@” for “a”, a hacking program will try to substitute “@” too. Same goes for “1” for “I” or “l”, or “$” for “S”.

Many users — author included — often add a “1” and/or a “!” at the end of their password as a simple way to meet password requirements. Once again, when everyone does it, it becomes much less secure.

The typical password created under the outdated requirements is short and difficult to remember, pushing users towards writing them down and remaining relatively simple for a computer program to guess. Meanwhile, forcing users to reset their password every 90 days means simple changes are usually made, like adding another number on the end or tagging on a question mark, neither of which does much to create a more secure password.


How can I get my users to practice more secure password protocol?

The first step towards teaching your users strong password practices and getting them to unlearn over a decade of poor password protocol is to communicate clearly and often. Use every tool at your disposal — talk to HR and marketing about how to broadcast the password requirements, and your rationale for them, several times.

Users may resist the changes, especially when they see that the minimum character length is 14+. But if you can describe how remembering a long phrase is easier than a bunch of random special characters, they might quickly learn to love the changes. Be sure they also know that minimum length is not the required length — for example, a nine-character minimum can, and should, be a longer password in practice.

Passwords should be lengthy for maximum security. The easiest way to achieve this is with passphrases, preferably a random group of words that are difficult to associate, but relatively easy to memorize.

Here are the keys to secure passwords:

While this shift may take some time, it will eventually be ingrained in your userbase just like the current practices.