New NIST Password Guidelines

For what seems like an eternity, we've been urged, encouraged, prodded, poked, browbeat, pressured, reminded, cajoled, and any other word you can think of to create secure passwords. Part of that “programming” has included using a unique password for each login you have.

And, in a “more perfect world,” that is great advice. But, once you start mixing in human failings, it all falls apart for a number of reasons. Probably one of the higher ranking problems with that advice is that most people cannot remember all of those different, unique passwords. The rigorous regimen for password creation, coupled with most people's inability to remember 100+ different passwords, has led to users committing the cardinal sin of reusing the same password on multiple sites. Once a password that has been reused on multiple sites has been hacked, then all of the other accounts associated with that user where a password has been reused are also at risk.

The task is made even more difficult by previous password recommendations that forced users to have a mixture of upper and lower case letters, numbers and a non-alphanumeric symbol. Remembering even a dozen of those cryptic passwords is a task too difficult for most users.

I know we've covered password security ad-nauseum in the pages of The PCLinuxOS Magazine. I won't even attempt to count how many articles we've previously run, because my count of them varies each time I try. But trust me when I tell you that we've covered it a LOT. Couple that with virtually every other outlet in existence also harping on the same topic, and there's little to no doubt that you've received the “message,” along with every other computer user on the planet. Whether that message was heeded, however, is a whole other matter.

Despite admonitions to the contrary, I'm certain that someone reading this has one of the following “passwords” to “secure” their private, personal data: passwOrd, password123, 12345678, 87654321, abc123, abcd1234, effthis, or one of MANY other insecure passwords that have been proven time and time again to be insecure. We've also run multiple articles on the annual “Worst Passwords of [YEAR]” in The PCLinuxOS Magazine. While the list changes somewhat every year, many of the top 50 worst passwords on those lists remain stagnant and unchanged.

Fortunately, the National Institute of Standards and Technology (NIST) may have just paved the road towards an easier life for computer users around the globe. They recently released a new set of updated guidelines for password generation and usage.

Actually, it's about time. The evidence for everything I just discussed has existed for several years now. We've even run multiple articles in the past detailing these new and improved regimens for password security. For what it's worth, NIST makes the recommendations for cybersecurity for the U.S. government.

So, let's take a look at those NIST recommendations, and how you might be able to benefit.

When reading through these new password standards, keep in mind that those items labeled “SHALL” and “SHALL NOT” are requirements, while those labeled “SHOULD” and “SHOULD NOT” are strong recommendations. Whenever you come across the term “CSP,” interpret that as “credential service provider,” which can be a local credential service provider, or a third-party credential service provider. Even though NIST doesn't have any enforcement powers, their recommendations are typically enacted in toto.

Section 3.1.1.1: Password Authenticators

Passwords SHALL either be chosen by the subscriber, or assigned randomly by the CSP. If the CSP disallows a chosen password because it is on a blocklist of commonly used, expected, or compromised values, the subscriber SHALL be required to choose a different password. Other complexity requirements for passwords SHALL NOT be imposed.

Section 3.1.1.2: Password Verifiers

There are nine key requirements under the new password recommendations.

First, passwords need to be a minimum of eight characters, with a minimum password length of 15 characters recommended.

Second, verifiers and CSPs also should allow passwords up to 64 characters in length.

Third, all ASCII printing characters, including the space character, should be allowed within the password.

Fourth, all Unicode characters should be accepted in passwords, and each Unicode character shall be counted as one character when evaluating password length.

Fifth, additional rules regarding password composition, such as a mixture of upper and lower case letters, numbers, and symbols, shall not be required for the composition of passwords.

It has been shown for quite some time that stringing together four or more common, random, unrelated words is at least as secure as requiring the mixture of characters, and it makes remembering those passwords far, far easier for users to remember.

Sixth, there shall be NO requirement for users to periodically update their passwords, unless there is evidence that a user's password has become compromised.

Seventh, verifiers and CSPs shall not permit the subscriber to store a password hint that is accessible to an unverified claimant.

Eighth, subscribers shall not be prompted to use knowledge-based authentication (KBA) (e.g., “What was the name of your first pet?”) or security questions when choosing passwords.

Ninth, verifiers shall verify the entire submitted password (i.e., not truncate it).

The recommendations continue beyond these nine requirements.

If Unicode characters are accepted in passwords, the verifier should apply the normalization process for stabilized strings using either the NFKC or NFKD normalization defined in Sec. 12.1 of Unicode Normalization Forms [UAX15]. This process is applied before hashing the byte string that represents the password. Subscribers choosing passwords that contain Unicode characters should be advised that some endpoints may represent some characters differently, which would affect their ability to authenticate successfully.

When processing a request to establish or change a password, verifiers shall compare the prospective password against a blocklist that contains known commonly used, expected, or compromised passwords. The entire password shall be subject to comparison, not substrings or words that might be contained therein. For example, the list may include, but is not limited to passwords obtained from previous breaches, dictionary words, and context-specific words, such as the name of the service, the username, and derivatives thereof.

If the chosen password is found on the blocklist, the CSP or verifier shall require the subscriber to select a different password and shall provide the reason for rejection. Since the blocklist is used to defend against brute-force attacks and unsuccessful attempts are rate-limited, the blocklist should be of sufficient size to prevent subscribers from choosing passwords that attackers are likely to guess before reaching the attempt limit.

Verifiers shall offer guidance to the subscriber to assist the user in choosing a strong password. This is particularly important following the rejection of a password on the blocklist as it discourages trivial modification of listed weak passwords [Blocklists].

Verifiers shall implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made on the subscriber account.

Verifiers shall allow the use of password managers. Verifiers should permit claimants to use the “paste” functionality when entering a password to facilitate their use. Password managers have been shown to increase the likelihood that users will choose stronger passwords, particularly if the password managers include password generators [Managers].

Users on PCLinuxOS can use multiple password managers to help remember the vast quantity of passwords. One that I use quite regularly is Bitwarden, which we covered previously in The PCLinuxOS Magazine, here and here. I've also used KeePassX in the past, which we've covered here and here.

To assist the user in successfully entering a password, the verifier should offer an option to display the secret — rather than a series of dots or asterisks — while it is entered and until it is submitted to the verifier. This allows the claimant to confirm their entry if they are in a location where their screen is unlikely to be observed. The verifier may also permit the user's device to display individual entered characters for a short time after each character is typed to verify the correct entry. This is common on mobile devices.

Verifiers may make allowances for mistyping, such as removing leading and trailing whitespace characters before verification or allowing the verification of passwords with differing cases for the leading character, provided that passwords remain at least the required minimum length after such processing.

Verifiers and CSPs shall use approved encryption and an authenticated protected channel when requesting passwords.

Verifiers shall store passwords in a form that is resistant to offline attacks. Passwords shall be salted and hashed using a suitable password hashing scheme. Password hashing schemes take a password, a salt, and a cost factor as inputs and generate a password hash. Their purpose is to make each password guess more expensive for an attacker who has obtained a hashed password file, thereby making the cost of a guessing attack high or prohibitive. The chosen cost factor should be as high as practical without negatively impacting verifier performance. It should be increased over time to account for increases in computing performance. An approved password hashing scheme published in the latest revision of [SP800-132] or updated NIST guidelines on password hashing schemes should be used. The chosen output length of the password verifier, excluding the salt and versioning information, should be the same as the length of the underlying password hashing scheme output.

The salt shall be at least 32 bits in length and chosen to minimize salt value collisions among stored hashes. Both the salt value and the resulting hash shall be stored for each password. A reference to the password hashing scheme used, including the work factor, should be stored for each password to allow migration to new algorithms and work factors. For example, for the Password-Based Key Derivation Function 2 (PBKDF2) [SP800-132], the cost factor is an iteration count: the more times that the PBKDF2 function is iterated, the longer it takes to compute the password hash.

In addition, verifiers should perform an additional iteration of a keyed hashing or encryption operation using a secret key known only to the verifier. If used, this key value shall be generated by an approved random bit generator. The secret key value shall be stored separately from the hashed passwords. It should be stored and used within a hardware-protected area, such as a hardware security module or trusted execution environment (TEE). With this additional iteration, brute-force attacks on the hashed passwords are impractical as long as the secret key value remains secret.

But Wait … There's More!

The new NIST guidelines also continue on to cover “Look-Up Secrets,” and how CSPs should handle those types of requests. They also offer updated guidance on how to handle multifactor authentication.

I'll leave looking up the information for those methodologies as something for you to do on your own. I'll also urge you to view the rationale for these changes by cross-referencing with the article's Appendix, which does a decent job of explaining the reason for the changes.

Summary

The new NIST guidelines for passwords are long, long overdue, seeing how the information supporting these changes has been around for at least five years. Anything that can make remembering passwords easier will also make it easier for users to NOT reuse passwords on multiple sites. And, as you can see, these changes are quite wide in their scope and breadth.

This is, without any argument, a HUGE step in the right direction. As huge as these changes are, don't hold your breath waiting for the recommendations to be adopted quickly and en masse. There will be resistance, as well as those who are unaware of the changes brought forth in the new recommendations. Some people absolutely hate change, in any shape, form, or color. It will take some time, so don't expect to see these changes happen overnight. Some CSPs and verifiers will try to claim that the current password regimen is not broken, and will resist to the nth degree. Except, the current system is broken, as evidenced by users taking the shortcut of reusing passwords for multiple logins.

If you want to read more about these new password recommendations (besides the NIST document itself, which is rather dry reading material), I can recommend these two sites to start your dive into these changes. The first one is an article from Intelligent Technical Solutions. The other article is from Specops Software. Both have great information on the recommended password regimen changes.

Creating a unique and secure password is YOUR responsibility. No one else is going to protect it for you. No one else has as much vested interest in protecting your private, personal data as you do. These changes should help keep your private, personal data safe from prying eyes, but only if you follow these recommendations.