Passwords have always been a hot topic of discussion both in and out of security circles. Users have always hated being forced to come up with schemes to meet the complexity rules, or change their password at defined intervals. The multitude of password requirements of the past have frustrated users and have led to bad behaviors which time after time led to compromised passwords and resultant data breaches.
It has been just over a month since the public comment period for the NIST 800-63-3, Digital Identity Guidelines, closed. After adjudicating 1,477 comments over the past year since the draft was released, the Special Publication will soon be finalized and published. The changes in direction are significant as they contradict the decades old password requirements that drove everyone crazy, and they relieve users of much of the pain when dealing with passwords.
What is NIST 800-63-3?
The National Institute for Standards and Technology (NIST) is a governmental organization charged with developing information security and privacy standards and guidelines under the Federal Information Security Management Act of 2014. Once you start digging into their publications, it is quite impressive at the depth and breadth of topics they cover in their published works. One of the most well-known of their security publications is Special Publication (SP) 800-53, Security and Privacy Controls for Federal Information Systems and Organizations, which is at the heart of the various Risk Management Frameworks and is a comprehensive guide to security control definitions and supporting information.
NIST 800-63-3 provides “technical requirements for Federal agencies implementing digital identity services” and covers areas such as “identity proofing, registration, authenticators, management processes, authentication protocols, and related assertions.” NIST 800-63-3 received a lot of attention in the security world because it broke with the norms of the previous decade’s (or more) guidelines/requirements for password management. Altogether, I spent almost 20 years either directly working for the government or as a government contractor, so I’m very familiar with the password requirements. In fact, I was the one to enforce these password complexity rules for the many systems I worked on as a security engineer. The NIST password guidelines are mandatory for federal agencies and are extensively used by commercial organizations as best practices. The new password guidelines actually contradict with other NIST publications, and my understanding is that those on the SP 800-63-3 team are coordinating resolutions to those conflicts with the other teams managing other SP documents. Overall, it will be interesting to see how government agencies do with “unwinding” the password requirements they’ve enforced for so long.
What are the new NIST password policy guidelines?
The SP 800-63-3 team did not recommend undoing everything we’ve known regarding passwords and leave it at that – that approach would be negligent. Some of the changes introduced in SP 800-63-3 are based on studies and research which indicated that the password requirements of the past encouraged the creation of bad passwords.
The new NIST password standards that are breaking with the previous norm are specifically found in SP 800-63-3B, Digital Identity Guidelines, Authentication, and Lifecycle Management. While there are several changes to the requirements, the primary ones generating most of the discussion are summarized below.
- Password length: Minimum password length (for user selected passwords) is 8 characters with up to 64 (or more) allowed.
- Password complexity (e.g. requiring at least one upper- and lowercase, numeric, and special character): NIST recommends password complexity not be imposed.
- Character sets: The recommendation is all printing ASCII and UNICODE characters be allowed.
- Password “hints”/authentication questions (e.g. what was your first car?): Password hints/authentication questions shouldn’t be used.
- Check for “known bad” passwords: New and changed passwords are to be checked against a list of common or previously compromised passwords (e.g. from dictionaries, previous breaches, keyboard patterns, and contextual words (e.g. the user’s username)).
- Throttling: Implement throttling to limit failed authentication attempts.
- Password expiration: Organizations shouldn’t require users to change their password at defined intervals (e.g. 45, 60, or 90 days).
- Using SMS for MFA: NIST “discourages” the use of SMS as an out-of-band authenticator and is considering removing its use in future versions of the SP 800-63 series.
Is my organization required to implement the new NIST password guidelines?
As a note, the traditional government conventions for documents such as this one (SHALL/SHALL NOT, SHOULD/SHOULD NOT, MAY/NEED NOT, etc.) were intentionally avoided. These terms are specifically defined in the document itself, and as previously mentioned, represent various levels of compliance (from required to recommended) for Federal agencies. As far as passwords are concerned, NIST SP 800-63-3 is considered by many to represent password best practices. For commercial entities, it is recommended that this new NIST password policy be considered as part of their evaluation of risk and changes be made accordingly.
Should my organization implement the NIST password guidelines?
The short answer is – it depends. It depends on which changes are made, how they are implemented within your organization, and the other compensating controls in place in your organization. Below are a few things to consider regarding each of the NIST password recommendations:
- Password length: Allowing a 64 character (or greater) passwords is great move on NIST’s part. I was surprised, though, that the minimum password length requirement was only eight characters. To me, an eight-character minimum password length is insufficient. As we all know, users will do the minimum, so eight character passwords will become the norm. Also, in today’s computing environment, brute forcing an eight-character password is trivial. I would recommend at least 14-character passwords for general users. With the removal of password complexity, this simplifies coming up with a longer password. NIST’s argues that in conjunction with No. 5 (checking for known bad passwords) and No. 6 (throttling), there was not a need to increase the minimum length. It may also be with the push toward MFA, an eight character, non-complex password is sufficient. Why, though, encourage one of the two factors in an MFA solution to be weak?
- Password complexity (e.g. requiring at least one upper- and lowercase, numeric and special character): This one has been the thorn in the side for many users over the years and has resulted in common substitution techniques (e.g. a 1 for the letter l, or @ for the letter a) which met the requirements but did not increase the security of the password. Longer passwords without complexity are better than short passwords with complexity factors.
- Character sets: Increasing the allowed character set is good, but it may take some time before it is supported in some technologies.
- Password “hints” (e.g. what was your first car?): Password hints/authentication questions have been used on multiple occasions to gain unauthorized access to user accounts, so getting rid of them is a good move.
- Check for “known bad” passwords: As mentioned previously, this is one of the password requirements that provides “cover” for the minimum password length of eight characters. The concern here is the implementation. When is an organization’s collection of passwords that are “commonly-used, expected, or compromised” considered complete? Is just using a collection of dictionary words and a few keyboard patterns (e.g. qwerty, qazwsx, abc123, etc.) considered sufficient? Compliance with this requirement is subjective, and therefore its effectiveness can be marginalized in organizational environments.
- Throttling: This is another one of the password requirements that provides “cover” for the minimum length policy. In general, throttling is a good idea, but my concern is in the implementation across the multitude of technologies requiring authentication. More specifically, I would be concerned that the minimum password length be quickly relaxed which is extremely easy to do while waiting some undetermined time for the throttling implementation to be put in place across all the areas where authentication occurs. The time delta between the relaxing of the minimum length (and complexity for that matter) and the implementation of throttling significantly increases an organization’s risk. Again, throttling is a good idea, but in my opinion it shouldn’t be used as a justification for an 8-character minimum length password.
- Password expiration: This is a big win for users since users often just incremented by one the number at the front or end of their password. This requirement makes the most sense, though, when paired with longer passwords, not one that is just 8-characters.
- Using SMS for MFA: Using MFA with SMS is better than just relying on your password for authentication. Since the primary SMS infrastructure runs on an old infrastructure built without a thought toward security and an SMS-based MFA implementation has been exploited (in conjunction with a weak password), this is a step in the right direction. Time bound out of band authenticators that don’t require transmission are a better option and easily implemented.
According to the 2017 Verizon Data Breach Investigations Report (DBIR), “81% of hacking-related breaches leveraged either stolen and/or weak passwords,” so improving passwords and authentication techniques is still, as it has always been, a timely topic of discussion against the backdrop of the NIST password policies outlined in SP 800-63-3.
While the intent is to help individuals and their data become more secure online, it will be several years before the implementation of the NIST password guidelines is pervasive across the Federal government, and it will be many more years after that before the impact upon the Federal agencies is well understood. Until then, measure how the NIST password guidelines in SP 800-63-3 fit with your organization’s risk appetite and how they may be able to ease at least some of the burden for your users while still providing an acceptable level of protection.
Linford & Company has extensive experience with NIST and associated NIST compliance. If you are interested in learning more about NIST requirements and compliance, please contact us.
Ray Dunham started his career as an Air Force Officer in 1996 in the field of Communications and Computer Systems. Following his time in the Air Force, Ray worked in the defense industry in areas of system architecture, system engineering, and primarily information security. Ray leads L&C’s FedRAMP practice but also supports SOC examinations and HITRUST assessments. Ray enjoys working with clients to secure their environments and provide guidance on information security principles and practices.