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?

[alanborack]

Not sure if the new password rules are going to be effective given the public community (personal accounts) such as online banking, online shopping, brokerage accounts, etc., for the most part, have no password expiration requirements, many cause the user to employ 3 out of 4 character types (upper, lower, number, special characters), most limit the use of all special characters.  But the problem as I see it is, the frustration of changing passwords that are significant complex.  I tend to use passwords (when the application permits) that look like my 2 year old granddaughter  was typing or my cat was walking across the keyboard.  In other words, ones that are so weird, the cracking tools would give up or bypass.  As a retired IT auditor, it was always my experience that clients will generally go along with the Best Practice if you can substantiate its use.  

[G08]

I welcome the new suggestions by NIST. However, in my view, the human element who made the computer and all other technologies is the strongest as well as the weakest link the cyber chain. If a person can hack complex passwords, he or she can devise programs or ways to hack pass phrases or longer passwords, its not that difficult. The most important threat to the information security is the human being who is either ignorant or unaware or negligent about information security. Major cyber crimes including data breaches have happened because of lack of responsible behaviour from our human element in one or the other way. So, it is worth while to consider how to deal with this human element such that the efforts that we put in improving cyber world is respected and considered as their own responsibility.

Regards,
Gargi Akolkar
B.Com., Chartered Accountant, PGDiploma in Cyber Security, Cyber Forensics, Cyber Laws and Cyber Crimes, Certification in Forensic Accounting and Fraud Investigation.

[amine_ie]

Very interesting!!

The whole point is in educating the end user, Respect the complexity/aging won't HELP as we still see stolen pwd (brute force, rainbow tables....etc) I have seen examples where end users where lazy and adding a special character each time they were forced to change their pwd. Or the best, the least effort when chooing compliant pwd : "Abcdefg.".

[Byórðæįr]

the 57 one is a famous actor, the password was tatters.

What I do is create a table of printable askii characters and toss that in +-=_@#$%^&;:,.<>~?!|"'*` with upper case, lower case, and 0-9 at which point, I can generate a password with any number of characters, turn off the special characters for sites that broken security, and I don't bother to remember any of the passwords, I simply generate the passwords and change them at random intervals. Which I can save as notes in the password tables.

Asking your users to change the password every so many days makes it boring. People get used to logging in with a certain password and when they have to change it, it causes problems trying to forget the old password and remember the new one. Which creates extra work for the IT team resetting the password and the people bothers other employees while locked out of their machine. We need a way to create a new password while allowing the old one to work until the person thinks they have the new one remembered and can lock in their new password as the only password that works for that account. But having people either carry a smart phone or a key generator is likely a good idea, or simply as others have said make sure that the physical security is good enough that they can use less secure passwords on site and more secure passwords to connect to off site resources.

[Blackswam]

I am about to recommend this for our Shadow/Business-led Systems as part of their security measure. Corporate policy is use passphrase but there is still 90 days expiry and AD complex password.

[tschack]

HITRUST has already adopted the new NIST guidance in CSF version 9.0.

[tschack]

I am on board with the new NIST guidance.  I expect having some interesting conversations with our customers about these changes.  Many of them still have the older recommendations in their contracts.

[sdsimpson]

This should not be seen as a ruling, its advice and not bad advice at that.  We must always remember though that security is not a blanket that fits all, it needs to be appropriate to the information we are protecting and our password approach must be flexible enough to provide the necessary protection.

Passwords have had their day though so we do need to provide users with a better and more secure authentication experience.

I prefer the advice coming from the UK with regards to this evolution - https://www.ncsc.gov.uk/guidance/password-guidance-simplifying-your-approach

This provides a good balance, we may reduce password security (by our old thinking) but what we must do is to counter that by putting more emphasis in our IT processes such as through increased or targeted monitoring.

[Squig]

I am with you on this. I'm wondering if there is a mathematician here in the group who could show "aaaaaaaaaaaaaa" is more secure that "$(@^$)&%".

[pop]

I personally dislike the "this password has been used recently and cannot be used" rule.  This is close to the no more password expiration rules.