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?

[Jesse_Mundis]

To Melmon's statement about "readily available software can guess a password of 12 characters in 2 seconds" I find that ... unlikely. 

Warning, math ahead...

Assuming these are 12 character _random_ passwords, and not just 12 character words, or word combos, or 'likely' passwords, that's on the order of 10^20 password compares per second.

The set of [a-zA-Z0-9] is 62 chars, and add in two pieces of punctuation, you are at 64. 64^12 = 4.7x10^21 possible random 12 char password combinations. On average you can hit one in half the total search space, which drops us down to order-of-magnitude 10^20th compares needed.

That's well out of the reach of a single super computer, which don't reach even that many floating point operations, much less password compares (which would take multiple ops each) a second.

So I suspect the ex GCHQ presenter may have had a bit of a rigged demo for "readily available software," or wasn't going against a truly random password, or had an army of computers running that software.

I'd be very interested to be proved wrong, if anyone has a pointer to that Cyber Security briefing with details, but the numbers don't match with my experience.

[asredux]

---

@Jesse_Mundis wrote:

Warning, math ahead...

Assuming these are 12 character _random_ passwords, and not just 12 character words, or word combos, or 'likely' passwords, that's on the order of 10^20 password compares per second.

The set of [a-zA-Z0-9] is 62 chars, and add in two pieces of punctuation, you are at 64. 64^12 = 4.7x10^21 possible random 12 char password combinations. On average you can hit one in half the total search space, which drops us down to order-of-magnitude 10^20th compares needed.

---

In your example it's really (n+k-1)! / (k! (n-1)!) where n=64 and k=12, or 26,123,889,412,400 possible combinations with repetitions permitted (but more involved -- and a smaller number -- if you require at least one character of certain classes).  Even if you include all passwords of shorter lengths (e.g., 8...11), you are adding results, not multiplying and shaving off 8+ orders of magnitude from your result.  Then, if the pre-built rainbow table is loaded into some data structure (yeah, virtual memory), your search efficiency will be much better than linear (on which you based the average number of compares needed to find a match), but even if not, sorting into chunks with known ranges will also greatly reduce the number of needed compares.

But all of that aside... I *think* the original poster may have been referring to a dictionary attack versus a true brute-force attack, since humans don't generate random passwords -- they do stupid stuff like 'pa55w0rd'.  : )

Regardless, I'm with you... I'd like to see more details to know if this was just parlor games or the real deal.

[wolfawk]

As an individual who provides comments back to NIST on behalf of my Agency, I am certainly taking everyone's comments in my mind as I develop my Agency's response.

[slowlysecure]

While I think the new rules make sense, I haven't seen any movement on the adoption front.  I think we will have "your password must be changed because it has been 90 days" for a few more years at least.

[MrBill]

One thing I don't see mentioned here is that the new NIST documents also include an extensive discussion on what types of authentication you need to access various types of data. As I read those, password-only authentication is no longer sufficient for much. While everyone has focused on the recommendations that will make passwords easier to manage (no strict composition rules, no fixed expiration) no one seems to be focusing on the fact that two- (or in some cases three-) factor is now required for most applications. It seems to me we need to look at the new NIST documents as a whole, and not focus on only one part.

[Joe_Zajac]

Excellent summary! My only concern is that the specification of a minimum password length that’s too low (or any minimum, for that matter) tends to appease those who have the “minimum possible” security mindset. In both application and vendor vulnerability assessments, for example, the decision to accept the risk of using a weak password on something like a domain controller admin account is sometimes argued because “the policy says only eight characters are required.” The next argument will be “NIST says...”. Any ideas on helping an organization overcome the “minimum possible” security mindset?

[jenborst]

And only a subset of special characters.  

I have no idea why question marks are so insecure.

[DavidF]

The draft policy reflects changes in UK advice and imost of it is welcome. Users still need to be discerning though: there are important passwords which should be accompanied with 2FA, that basically protect anything of real value; stuff that users would like to protect but could live with if compromised; and a load of junk passwords that we are forced to create just so the marketers can get your details! Also doesn't solve the problem of having 50, 60, 70+ passwords.

[donallison]

It is a welcome start as an update. I believe that there are multiple levels of importance of data and of the people allowed to access the levels. Unfortunately, data appears to be treated as one entity in the guidance. Even though welcome changes are evident such as the password rules, other areas have not been addressed. As pointed out earlier multi-factor authentication is a must have for certain types of data and access to that data. I would rather see a hierarchy of protection processes, procedures, and technical measures commensurate with the value of the data/user. Additionally, there appears to be relatively little effort involved in looking at the sovereign rights and jurisdictional ambiguities encountered when looking at data at scale.

As for passwords - a password manager would be a nice topic to consider when looking at rules for users.

[mcarter163]

"

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

1st- users are stupid..I'm not favoring them. I always suggest that they use something like Keepass or the like to generate passwords and store them. A version of keepass is available for mobile devices and the .kdbx file can be copied from the desktop to the mobile device for consistency.

2- password strength is still good.. until hashes have been created for word longer than 20+ characters, bruteforcing won't work..