NIST new ruling on passwords

[Matthew]

I wanted to see how members on here felt about NIST new draft of password policy suggestion.   

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 ChangeMe, thisisapassword, 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.

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. (Really! We have some astonishing examples from Adobe’s 2013 password breach.)

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.

There’s more…

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.

https://nakedsecurity.sophos.com/2016/08/18/nists-new-password-rules-what-you-need-to-know/

I think this is a great step.  The 90 day rotation only made users change the base of their password append with a date or numerical number.  Example, TH!S1sMYp2ssw0rd1, THIS1sMYp2ssw0rd2, etc.    Once the base of the password was figured out or phished, gaining access is easier.  

I still educate my users on passphrases and why they better as a password substitute but our policy (and compliance) rules make it hard to use a nice passphrase.  

I have also educated my users on password management solutions.  This allows for a long passphrase as the master password that bypasses local policy restrictions.  Local solutions work well if you have an office that you will always log into at work.  The database for this solution should be stored on a network share for data redundancy.   Also, Cloud solutions are acceptable if you have a user who is on the move or never logs in from the same device.   I would only caution that your Cloud solution encrypts the data and either you hold the decrypt key or have it part of your master password.  

Thoughts?

[dswomley]

This is a tremendously important subject that requires more discussion at all levels. In fact, thank you for writing the article I have been contemplating (but obviously not acting upon) for several years now.

As an IT Management Professional with a doctorate, 16 years of licensed experience and Board-Certification in a Mental Health specialty, I can unequivocally support the concepts underlying your argument: Human Factors must be included in the development of requirements/ standards which demand participation of and compliance by Human Beings!

With apologies to all for ranting now, without having acted previously, I just want to share my professional responses  (both IT & Psych) when faced by an obstinate, and obviously arbitrary standard, set in good faith no doubt, by someone who thought they were protecting resources.  

For example from the first entry:  “Your password must contain one lowercase letter, one uppercase letter, one number, four symbols but not &%#@_, and the surname of at least one astronaut.”

My professional responses (both IT & Psych) : "Who says?" followed by "what evidence do you have that these standards are effective levels of protection when used according to the instructions?" and further, "what evidence is there that these standards meet a level of reasonableness that will ensure compliance by end-users, and not creative - or not so creative - workarounds?"

Having said all this, I strongly support the NIST ruling on passwords as a common-sense approach to implementing a security strategy that, as always, is dependent  on the Humans charged with implementing it.

Thank you and Happy Holidays to all my colleagues who may be celebrating a holiday in coming days & weeks!

Dr David PhD, CISSP, PMP

CIO - CRO

[JoePete]

How about making the quality of the password commensurate with its function? Many folks only have two or three good passwords. When every system adopts the same rules, well now when the girl scout Web site for Susie Smith's mom gets compromised so does the network of Big Friggin Data because Susie's mom happens to be the network admin there.

Similar lines, passwords are literally half the problem. Unless you are talking a social Web site, you should choose a username that is not your email address and is not displayed to other users. Hash that on the bakend too.

Lastly two factor is neat and all, but it also carries cost and complexity. The reliability for common use just isn't there yet.

[D_Pengelly]

Thanks for the summary.  I have been a fan of longer is better for quite sometime and it angers me when some credentials limit length and restrict/limit special characters.  The math is certainly on the side of longer passwords and currently rainbow tables for longer passwords are not as well distributed.  I agree it is also time for aging to be retired, since it leads to less complex shorter passwords that follow patterns.  Audit and compliance standards need to be updated to reflect NIST password recommendations.

Dean

[DHerrmann]

Which is the stronger password:

1. aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

2. 8wkJ#01

It's about time somebody revisited this critical subject.  Well done, NIST.

[canLG0501]

I agree.  Following NIST recommendations  just equals credibility.  If you are going to abide by the recommendations made by NIST to jettison expiration and outdated password complexity rules in favor of user-friendliness - it requires that you introduce new password encryption standards and require multi-factor authentication for any service involving sensitive information.  Industry will have to layer up.

[vt100]

Same here. I've implemented the mandatory 20 character passphrase as soon as it was supported by AD, (had to use custom OU configuration for that). Ever since the XKCD post: Password Strength

[nvirani]

Guidelines will provide great relief to users and IT help desk engineers.

[dswomley]

Looks like they removed it........it's now missing in action............

---

@Tamangwrote:

Arrived this morning in my inbox from US-CERT

https://www.dhs.gov/sites/default/files/publications/Week5TipCard-%20508%20compliant_0.pdf 

 "Make your passwords long & strong. Use complex passwords with a combination of numbers, symbols, and letters. Use unique passwords for different accounts. "

NIST/Feds needs to agree first.

---

[Beads]

I encourage people to use any number of free password managers, paid or free while discouraging the use of the Post-It note strategy. Ideally the security community would be able to push for two factor if not true multi-factor authentication but I also have a very educated organization that has been "trained" to believe that biometrics will be recorded and shared with numerous government agencies around the world. Suspect this will be the prevailing prejudice until specifically codified not to allow private bio-information not be shared with governments.

Until then we have fairly vague guidelines and a weak control group to protect our organizational assets. Though I agree we don't need to change passwords every 60 or 90 days. Just kept the help desk busy with unnecessary requests.

[eugenioa]

Multi-factor authentication + (Random complex long and unique passwords) are the most secure way. Leaving the second factor away for this discussion, the only way to achieve secure passwords in a humanly manageable way is using a password manager.

All password recommendations (past and present) have a common weakness, it is called "the user" and there is very little a site manager can do to prevent a user to chose a weak password. Many weaknesses have been proven on human habits when forced to use symbols "pa$$w0rd" is a common example.

Then, somebody comes with the idea of a passphrase long enough. What about:

"May the force be with you" how long it will take for a dictionary attack to break this high entropy easy to remember password?

So... you decide to enforce a group policy... minimum 12 characters and at least one symbol (dictionaries will have hard time for a little while, until they figure out all the combinations that people tends to use for "may the force be with you@"

And then, there is the impossible to control factor anyways, what happens when your users start using the same password everywhere (with such a beautiful password is just a matter of time before it happens)

Only a password manager that creates something like "Qc447$q8Xc" and uses a different combination for each service will do.

Off course, the password manager needs to be secure enough or  you are creating the key of the kingdom but let's face it... 90% of your users have already given up the keys of the kingdom when they used your domain password for their e-bay, Facebook, gmail and twitter accounts. If you are lucky they are not subscribed to underground or low reputation websites with the same username and password.

The only policy that would make sense is the policy of using a random password generator and offering a password manager. In all the other cases you are left to the good training and judgement of your users.

Add a second factor whenever possible

Unfortunately, Operating Systems are being very slow on offering out of the box solutions for this.

Expiration or no expiration, complexity or length, those won't make a difference until the users are given a tool that keeps them away from having to memorize which leads to lax choices.