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?

[bobkorz]

"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."

How will that impact performance? Does someone want to wait 1-2 minutes to process such a validation?

"No composition rules"

Big time important. Rules make it easier for passwords to hack.

"No password hints."

Well this means people are forced to write their passwords on a sticky note then. There are security implications for that.

"No more expiration without reason. "

Agreed.

[KPentecost]

GREAT TOPIC! I'm very curious to know how many of my fellow CISSP's are planning to move to passphrases or may have already gone to passphrases.

- If you have, I'd love to know how easy it was for the user's to adopt?

- Do you have any suggestions to make it less painful?

- Did you have to offer user training?

- Thoughts on Diceware vs. traditional user created Passphrases?

Thanks to anyone who might be able to provide some insight.

[Wolf]

Surely it isn't just size but complexity too? Given the option the majority of people will choose convenience over complexity and your ordinary user will opt for a 'Loved One' password, e.g. juliet.  When encouraged to better their passwords a more evolved version of this will become Juliet01.  However, forcing a user to include a special character makes the evolved password + special character 23.5 x stronger under brute force conditions.

I'm also in favour of forcing users to periodically change their password.  Some users will quite openly volunteer their password with the littlest of encouragement.  In areas that have high staff turnover or take on students for temporary assignments changing passwords is essential, even if it is an incremental change. That's better than the alternative.

End user education is essential.  It's important to offer up suggestions to what makes a good password be it passphrases, keyboard pattern strokes or anything else.  I teach my users the difference between passwords that are crackable and passwords that are guessable.

[noel]

@bmullen I don't really understand how the two are related. Can you explain it to me?

The concept behind SQRL is to remove any shared secret with the end server. It instead moves authentication to the smartphone which holds the secret key used for authentication.

It seems like Trusona only moves the shared secret away from the target end server to an OOB authentication server.

[Lance]

I agree mostly with the new changes. 90 day expiry drives me nuts. BUT (you knew there would be one), the only thing that some interval of expiry prevents to some degree is the cardinal sin of passwords: re-use.

Right now, users won't change their consumer based passwords to be in alignment with enterprise standards, it's too much of a hassle. But if expiry were eliminated altogether? I think there is a stronger risk here.

As a result, I'd love to see a middle-ground (almost said compromise, heh), of maybe changing once a year.

Also, if this is going to be successful, enterprises need better signals when passwords are compromised in the wild & tied to enterprise data (ie. email address). This can trigger a forced change, which I'm fine with.

[jespinoza]

Nice article. I see a lot of bank's websites using KBAs. it's very easy to get those answers in social networks.

[Ackis]

I found this article to be a good read on password standards:

https://www.troyhunt.com/passwords-evolved-authentication-guidance-for-the-modern-era/

Particularly, this statement:

"If someone really wants to have a password that's an emoji representation of the first verse of "Let It Go" from Frozen, good on 'em!"

[bmullen]

@noel From and end-user perspective the two are very similar - scanning a QR code vs. logging in with user/pass. This is particularly beneficial when the user is logging in from an unknown source that could have a keylogger active.

No password is exchanged with Trusona. Just as you say with SQRL - it moves the authentication to a smartphone app, which means that you would need to trust that the smartphone is secured appropriately. But in this day and age where most software-based, user-facing MFA is on a smartphone, that shouldn't be anything new.

I'm not a salesman for the product and I don't work for the company, so I wouldn't be able to go deep here. I've just seen the product demoed and it looks promising and, at least to me, very similar to SQRL code authentication.

[rycase]

Matthew - first, thank you for your service to our country!

I agree the revised standards are an improvement, however clearly there is a gap between the auditors and the regulatory bodies as there are a TON of financial services companies that still do not allow full ASCII characters in form fields. In a time when almost every presentation layer framework has built-in functionality to assist with input fields, through very very simple approaches to mitigate risks throughout the stack - I still constantly see terrible implementations. All commercial and even open source directory servers I am aware of allow for account suspension (Time based, error based, etc). I am more concerned about organizations that opt for hashing passwords.

The one area I feel is a mainstay is the shift to the producer from a verification and complexity standpoint. UX continues to be the big dog on campus and as long as we see more and more devices making user experience a top priority - many existing controls are going to be ignored, avoided or implemented in such ways that they defeat any benefit. I suppose if emoji's need to be represented (terribly strange to me), this still just aligns with Unicode. Mobile devices usage of biometric authentication should continue to reduce the focus on things we should have been requiring a decade ago.

When I teach the Safe and Secure Online program to children and elderly alike - there are very simple instructions on password creation tips - why cant the W3C just provide an RFC that is available for anyone when creating an account?

[rycase]

"End user education is essential" 

100% agree - the trick is finding a way to make a meaningful approach towards the enormous variance of intelligence, experience et al.