It’s no secret. We’re really bad at passwords. Nevertheless, they aren’t going away any time soon.
With so many websites and online applications requiring us to create accounts and think up passwords in a hurry, it’s no wonder so many of us struggle to follow the advice of so-called password security experts.
At the same time, the computing power available for password cracking just gets bigger and bigger.
OK, so I started with the bad news, but this cloud does have a silver lining.
It doesn’t need to be as hard as we make it and the government is here to help.
That’s right, the United States National Institute for Standards and Technology (NIST) is formulating new guidelines for password policies to be used in the whole of the US government (the public sector).
Why is this important? Because the policies are sensible and a great template for all of us to use within our own organizations and application development programs.
Anyone interested in the draft specification for Special Publication 800-63-3: Digital Authentication Guidelines can review it as it evolves over on Github or in a more accessible form on NIST’s website.
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.
Favor 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.”
Applications must allow all printable ASCII characters, including spaces, and should accept all UNICODE characters, too, including emoji!
This is great advice, and considering that passwords must be hashed and salted when stored (which converts them to a fixed-length representation) there shouldn’t be unnecessary restrictions on length.
We often advise people to use passphrases, so they should be allowed to use all common punctuation characters and any language to improve usability and increase variety.
Check new passwords against a dictionary of known-bad choices. You don’t want to let people use
yankees, 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.
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
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.
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.
NIST also provides some other very worthwhile advice.
All passwords must be hashed, salted and stretched, as we explain in our article How to store your users’ password safely.
You need a salt of 32 bits or more, a keyed HMAC hash using SHA-1, SHA-2 or SHA-3, and the “stretching” algorithm PBKDF2 with at least 10,000 iterations.
Password hashing enthusiasts are probably wondering, “What about bcrypt and scrypt?” In our own How to article, we listed both of these as possibilities, but wrote, “We’ll recommend PBKDF2 here because it is based on hashing primitives that satisfy many national and international standards.” NIST followed the same reasoning.
Additionally, and this is a big change: SMS should no longer be used in two-factor authentication (2FA).
There are many problems with the security of SMS delivery, including malware that can redirect text messages; attacks against the mobile phone network (such as the so-called SS7 hack); and mobile phone number portability.
Phone ports, also known as SIM swaps, are where your mobile provider issues you a new SIM card to replace one that’s been lost, damaged, stolen or that is the wrong size for your new phone.
In many countries it is unfortunately far too easy for criminals to convince a mobile phone store totransfer someone’s phone number to a new SIM and therefore hijacking all their text messages.
This is just the tip of the iceberg, but certainly some of the most important bits.
Password policies need to evolve as we learn more about how people use and abuse them.
Sadly there have been more than enough breaches for us to see the impacts of certain types of policy, such as the evidence shown above from Adobe’s 2013 hack about the danger of password hints.
NIST’s goal is to get us to protect ourselves reliably without unneeded complexity, because complexity works against security.
Original Source: Naked Security