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?

[Gonif]

Auditors dont know everything and if they push back and if you state that you align with NIST CSF hit them with NIST Special Publication 800-63 Rev 3, Digital Identity Guidelines

[Jesse_Mundis]

While all good suggestions, why has nobody mentioend password managers?

I'd much rather see corporate support for a "blessed" Password Manager, and require its use.  Each site gets a random, unique, strong password.  No need for constant password rotation, easy to change a specific password in case of a site-specific breach.

The most secure password is one the user *can't* remember.

This circumvents most of these issues.

[JamesMac]

It's a kind of horses-for-courses thing. I have about four long passwords that I memorise at any one time: two are for password managers, one for my laptop, one for my desktop PC. The rest go in the password vault.

Worth also thinking about a proper product over the freemium cloud based apps. I use LastPass at home for passwords that are mine: for shared system passwords (eg root passwords for systems) a system that logs when passwords are checked in and out, and by which users, is a better bet. You'd probably be looking at Thycotic or CyberArk for that.

James

[Jesse_Mundis]

James, your use case is almost exactly like mine.  Long, memorised passwords for my machine login and password manager. Everything else in password manager.  Which is great for personal use.

I agree that for corproate use, you'd want something with more access control and logging and central admin features.

[carpet_pants]

I can see it was mentioned about the use of password managers. These are great tools to help protect passwords without the user ever having to see the password or having to think about creating them. The problem here is that NIST guidelines are recommended for all users, so when you have a large user community the cost becomes prohibative. This is why tools such as BeyondTrust, CyberArk, Thycotic typically are used for privileged accounts. Of course if you have an organisation with unlimited budget then hey presto, however its never that simple.

If you are advising a small number of individuals then they're some great tools out there such as 1password, lastpass, keepass etc. These all help individuals manage a large set of passwords and help with generating and auditing the vast number of accounts we all need these days.

Implementing something wider and larger for all users would require going to a fully fledged Identity and Access Management Solution! Great, got 2 years and maybe 2 mil to spare then sorted.

Look at the scale of the problem, what solutions you already have and if they are being used to their best ability and work from there. This way you can decide on the appropraite solution!

[Jason]

Agree with the others that password managers should be encouraged for use. This is especially useful to those in IT operations.

[Melmon]

 At a Cyber Security briefing delivered by an ex GCHQ professional we were shown how readily available software can guess a password of 12 characters in 2 seconds. Therefore, recommending that for every additional character security was increased. Surely recommending 8 then is outdated?  Pass phrases or several unconnected words and no forcing password changes were also recommended as more effective and secure controls. You will never stop people writing down passwords somewhere if they have complex, hard to remember passwords. Because of this it was also suggested that it was better to advise people that if passwords are written down and not in a password manager, then store them away from any PCs, media etc that uses them, rather than say 'don't ever write them down', because inevitably some people will.  Although we recommend the above now as part of 27001 consultancy we find we are often in conflict with outsourced IT service providers who set the password policy at 8 complex characters with forced changes.

How would others faced with this challenge address this?

[HallowedHill]

I've already had users asking about this.  As soon as I can identify an efficient way to check the passwords against a common dictionary attack, I will consider implementing.  Anyone using a tool they would recommend that is cost-effective (or free), secure and can be automated (or at least requires minimal manual intervention)?  Are you checking these quarterly?

[carpet_pants]

A very good and free solution is Hydra. You can pass it a list of users you wish to check and a password you want to test/guess or you can provide a dictionary of passwords you wish to validate. The only problem with the last option is if you run this against active directory and you have a lock out policy configured after so many attempts then you could potentially lock out your users. A good way around this (providing you have a reset on the counter after so many minutes) is to implement a delay between checks, e.g. check users against password1, wait for a given period of time greater than that of your reset time, check users against password2, repeat steps.

[Jesse_Mundis]

As a one-day hack-a-thon project, I downloaded the 300 million + sha1 hashes from the breach corpus Troy Hunt made available, and on a t2.micro instance in AWS, I could search for and compare (with a binary search, the hashes are sorted) in sub one second.  Refusing all passwords which appear in that big a corpus of known breached passwords is pretty good coverage.  It's just a chunk (about 12 gig uncompressed) of disk and a teeny bit of CPU to check.