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?

[sapounas]

I see this as a first great step in the direction of "when security becomes too restrictive, it may cause worse or even more unsecure issues to arise".  For example, when requireing a individual to change a complex password  every 60-90 days (ex. must have 1 of each character type not to have more than two of the same....) it causes a situation where not only the person many time only replaces or adds the next characther (ex. Scott@1 to Scott@2 or Scott@12 then Scott @123) but many times will end up writing it down either in a file or a notebook somewhere.  Although many may encrypt the written password change somewhere, majority will not.

[kimberdray]

Just last week there was NIST Blog by Mike Garcia called "Easy Ways to build a Better P@$$w0rd": https://www.nist.gov/blogs/taking-measure/easy-ways-build-better-pw0rd.

I strongly agree with the concept of using associations that are unique to you. More importantly, if you have to use passphrases at all, it is more and more necessary to utilize Multi-factor Authentication, whereever possible.

The most challenging outcomes of the many breaches reported in the last fews years are:

1. easily guessed and short passwords

2. password reuse.

Troy Hunt wrote a great blog about this very issue here: https://www.troyhunt.com/password-reuse-credential-stuffing-and-another-1-billion-records-in-have-i-...

Once we focus in increased length of passphrases versus complexity and ensure there is no password reuse, credential stuffing goes away. When we increase the length and ensure uniqueness of passwords for each individual service we use, Password Managers become a necessity.

Aside from our social and personal spaces, when it comes to credential protections in the enterprise, Privileged Access Management conversations are becoming more and more prevalent overall.

[Martinvj]

There is an interesting conversation in Bruce Schenier's Blog around the same topic . https://www.schneier.com/blog/archives/2017/10/changes_in_pass.html

[Jesse_Mundis]

As others have said, what really matters is when the auditors and QSAs update *their* checklists.  As long as businesses continue to get digned in audits for *not* expiring passwords every 90 days, they will continue to do so.

What do *I* think of NIST guidance?  I think it is fine, and a net positive for business in general.  I think they should be adopted ASAP, but they won't be adopted until the auditors buy in.

[Robert]

Looks like a good step forward and moving password expiry is particularly welcoming.

I wonder how difficult it will be for some organisations to change direction especially when years of advise and awareness training will have been contrary to this advice.

[DALX]

You have a point there.

Does anyone know of any organization who has already implemented these new password standards?

[Hilljg]

I join those who applaud the update from NIST. Having said that, I am surprised they didn't increase the 8 character minimum, even for non-privileged/sensitive accounts. We will likely go with 15 character passphrases. We may also use the lack of an expiration as an incentive to adopt 2FA.

[NicG]

As an auditor, all I can do is audit against my organizations password policy. Until my organization changes their policy all I can do is report that the policy does not line up wiht NIST. And until the regulators change their requiremnts, my organization's policy will stay exactly as it is...
Which brings me back to your point, when will we see changes from the various regulating bodies.

[carpet_pants]

I would recommend you do an audit of your user passwords and then you should get a good idea if your password policy is actually working for you, regardless of NIST recommendations. My experience has shown me that changing passwords every 30 days whilst might feel secure just forces users to adopt common themes for passwords and write them down. This makes password guessing incredibly easy!

User education can work for some individuals however more often and not you are trying to change peoples habits which is a longer term problem, usually about 12 weeks of following a new pattern to adopt a new behaviour. 

In summary, moving to a longer period (no more than 90 days) is in most cases more secure however, I would suggest increase the minimum length as well backed up with strong user eductation to promote passphrases and lack of themes.

[JJP]

Yep, drop a custom api component in thsts got a blacklist of common passwords. Test pw stores for easilly cracked passwords (there are many good tools for this) and extend the life time of the pw cycle to break away from similar inerations of passwords. Teach pass phrase approaches and that special symbols and spaces really boost pw strength. Passwords managers, federated identity etc to make things easier and remember that identity is the new perimiter.