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?

[JLB171]

We have had a direct challenge to our password policies as a result of changes to NIST and NCSC (UK) guidance. 

The challenge I have faced is presenting these valid challenges through to InfoSec management. It is taking a little time but we are finally making progress. 

I'm keen to keep updated on any case study examples of implementing the changes.

[FraserRoss]

Does any one disagree with these rules?  If not why has it taken so long for the advice (which will feed the accreditation processes) to change?

[EnviableOne]

The NCSC discussion document was published a while back by CESG before they were merged into NCSC

The gist of it is that password policy is too easy for computers to guess and too hard for users to remeber.

It also goes into the justification behind all the controls and why in the current era they seem redundant.

Personally I am trying to get Our internal auditors to accept our new policy based on this:-

Passwords are at least 14 characters, and do not expire, unless they are reported as compromised or their use indicates they may be.

complexity is not required but recommended

Passwords will be checked against https://haveibeenpwned.com/Passwords and any existing rejected

Passwords must not contain username, DOB or employeeid

We will be extending Single sign-on and promoting use of its password generation facility.

However its hard to get people to change from what they have always believed is right.

[CyberGirl100]

LOVE the non restrictive length and character change. I would be surprised to see the DoD or any Govt organization adopt any of these changes in less than 5 years though. I hope I am wrong! 

[Xephu]

I still see sites that has a very short maximum password length, and the worst one I saw was for a governmental site that only allowed the user a fixed size of 8 characters..  As I understand, any password from 8 and below is pretty bad, I did a major facepalm when I tried register my password. I think it's good that NIST comes out with a post like this because it would put more focus on how passwords should be treated.

It still annoys me a lot with the expire-date for passwords, and I talked with a lot of people that say they only change it from one number to another, or use something like spring,summer etc.

[richardw]

I think without MFA: eliminating password aging is less secure from an auditing standpoint because now it's much more likely that useful passwords can be leaked through phishing and remain viable, or shoulder surfing happens and the password remains viable, or the password get passed around for convenience.  The new NIST recommendations seem to look only at "brute force password security" and miss the bigger picture regarding the various other ways passwords get compromised.

[Maverick]

Great .. thanks for sharing, in my view No more expiration without reason is great move, especially when used with 2FA. Danger is when no password expiration without any additional security measures.

[bmullen]

@noel - check out Trusona, which builds off of the idea of SQRL. Good technology, backed by MS ventures.

Generally, I feel like something like this (the NIST change in recommendation) doesn't make much difference. Passwords are still a poor means of authentication. Make them longer, they're harder to type or remember. Make them shorter, they're easier to guess or brute force.

Best bet is to start reviewing technologies that allow us to reduce password use entirely in the hopes of eliminating it for most use cases in the near future. Difficulty is that there's a bunch of disparate technologies across workstation and web that can be hard to reconcile for the end-user.

We're trying to use "native" no-password technology wherever possible - biometrics, IWA... any technology that's easy or transparent to the end-user while still offering better security than a shared secret.

[Dink]

Why did it all take so long? It was obvious since more than a decade to me.

Perhaps too many morons in Information Security: Checkbox auditors, IT vendors, IT security vendors,  ... and apparently also ISC2 as they don't apply it themselves - but it's just a way to make business for them of course.

What's still very irritating is that the central problem of password flooding (so many apps and web sites require passwords) is not effectively tackled. And even with less silly password rules, many users will still use the same passwords or phrases (or parts of them) over and over again. And thus a targeted attack will be able to find them in the “weakest link”.

Incredibly NIST even promotes the use of Password Managers / Wallets. Just like that. No concern for vulnerable applications (accidentally or on purpose). Yes, it happens with software. “Even” free software, even “security software”, look at CCleaner. Another thing I’ve been warning about since so long. Is NIST sponsored by the NSA maybe? Or are they just stupid?

If there was anything like a trustworthy Password Manager / Wallet Device. Completely separated and unconnected (except for QR code visual transfers perhaps) with a high level Common Criteria evaluation …

Yes, of course that would almost be the same effort and cost as having a (multi-factor) OTP device or a (multi-factor) cryptographic device. And thus it would be better to use the latter anyway instead of passwords. And thus also mitigate the MiTM threats a bit at the same time by setting up mutually authenticated secure tunnels.

But it's so so inconvenient for the users … and the big software vendors don't see enough profit in it for them.

[procloudadmin]

We are going to become more effective by getting rid of this password changing freak show. Imabine how much time and ressources we would free up.

Replacing password changes with a 2 factor authentication is a decent solution , and only changing password when there are sign of compromise on an account.

Well, then there is regulations and etc.