New guidelines for creating strong passwords

New guidelines for creating strong passwords

The US National Institute of Standards and Technology (NIST) has issued new guidelines for password security that turn accepted wisdom about creating long strings of letters, numbers and symbols on its head.

Details

NIST, a non-regulatory federal agency within the US Department of Commerce, issued the original advice in 2003 that became the global standard for password security. But it now says the advice led people to create predictably ‘complex’ passwords in a bid to remember them, which made them more vulnerable to hackers.

A former employee who has since retired said there just wasn’t enough real-word data available at the time.

Key changes in NIST’s new digital identity guidelines include:

  • Don’t arbitrarily mix letters, numbers and symbols to make a password. Instead, create passwords that are more memorable.
  • Single dictionary words, the user’s street address or numeric sequences such as 1234567 should be banned.
  • Organisations should screen the strength of their passwords against those used in cybercriminal dictionary attacks; a method of breaking into a password-protected computer or server by systematically entering every word in a dictionary as a password.
  • Stop frequently changing passwords, for example each month, as it leads to poor passwords being created.

What’s new ?

What are the major differences between current received wisdom about “secure passwords” and what NIST is now recommending?

Some of the recommendations you can probably guess; others may surprise you.

We’ll start with the things you should do.

  • Favour the user. To begin with, make your password policies user friendly and put the burden on the verifier when possible. In other words, we need to stop asking users to do things that aren’t actually improving security. Much research has gone into the efficacy of many of our so-called “best practices” and it turns out they don’t help enough to be worth the pain they cause.
  • Size matters. At least it does when it comes to passwords. NIST’s new guidelines say you need a minimum of 8 characters. (That’s not a maximum minimum – you can increase the minimum password length for more sensitive accounts.) Better yet, NIST says you should allow a maximum length of at least 64, so no more “Sorry, your password can’t be longer than 16 characters.”
  • Check new passwords against a dictionary of known-bad choices. You don’t want to let people use ChangeMe, thisisapassword, GoCowboys, and so on. More research needs to be done into how to choose and use your “banned list,” but Jim Fenton thinks that 100,000 entries is a good starting point.

The don’ts

Now for all the things you shouldn’t do.

  • No composition rules. What this means is, no more rules that force you to use particular characters or combinations, like those daunting conditions on some password reset pages that say, “Your password must contain one lowercase letter, one uppercase letter, one number, four symbols but not &%#@_, and the surname of at least one astronaut.” Let people choose freely, and encourage longer phrases instead of hard-to-remember passwords or illusory complexity such as pA55w+rd.
  • No password hints. None. If I wanted people have a better chance at guessing my password, I’d write it on a note attached to my screen. People set password hints like rhymes with assword when you allow hints.
  • Knowledge-based authentication (KBA) is out. KBA is when a site says, “Pick from a list of questions – Where did you attend high school? What’s your favourite football team? – and tell us the answer in case we ever need to check that it’s you.”
  • No more expiration without reason. This is my favourite piece of advice: If we want users to comply and choose long, hard-to-guess passwords, we shouldn’t make them change those passwords unnecessarily. The only time passwords should be reset is when they are forgotten, if they have been phished, or if you think (or know) that your password database has been stolen and could therefore be subjected to an offline brute-force attack.

Leave a Reply