Account passwords are required for security and accountability but are often despised by users that must remember them and network administrators that must reset them when users ultimately forget after a long weekend or a donut-infused sugar coma. While recommendations have changed slightly over the years, the base settings remain the same: sufficient length to prevent easy guessing or cracking (currently around 14 characters), complexity levels to discourage the use of names and dictionary words (3 of 4 types of characters – uppercase, lowercase, numbers, or special characters), and password change cycles to force new passwords that are fully up-to-date with policy settings and not used anywhere else (30 – 90 days, typically).
Problems arise[JS1], however, when users aren't trained to rely on easy to remember passphrases [JS2] such as "Passwords are lame!" but instead cling to the traditional "P@ssword01!" nonsense words that are difficult to remember, especially if users are correctly instructed to not write them down and the organization has not implemented password managers. The problem seems to worsen the more often passwords are changed. To address these issues, the National Institute of Standards and Technology (NIST) released Special Publication 800-63B[1].
Now, before the happy dance starts and password policies are updated to never require a change or enforce complexity, be aware that 800-63B contains recommendations, indicated by "should" and "should not," as well as strict requirements, reflected by the use of "shall" and "shall not." [JS3] In other words, there are loose guidelines, much like the "code" in the much loved first Pirates of the Caribbean movie (we won't mention the others[JS4] ), and rules that must be abided by for the standard to be met. Research into the recommendations will be left to the reader, but some of the important requirements are listed below (emphasis NIST):
- Verifiers SHALL require subscriber-chosen memorized secrets to be at least 8 characters in length.
- Memorized secret verifiers SHALL NOT permit the subscriber to store a "hint" that is accessible to an unauthenticated claimant. Verifiers SHALL NOT prompt subscribers to use specific types of information (e.g., "What was the name of your first pet?") when choosing memorized secrets.
- When processing requests to establish and change memorized secrets, verifiers[JS5] SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. For example, the list MAY include, but is not limited to:
- o Passwords obtained from previous breach corpuses.
- o Dictionary words.
- o Repetitive or sequential characters (e.g. 'aaaaaa', '1234abcd').
- o Context-specific words, such as the name of the service, the username, and derivatives thereof.
- Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.
A quick review of the requirements would probably indicate that the first two items are easy to adopt, assuming they aren't already in place. After all, most organizations are requiring at least 8 characters, if not more, and have done so for several years. Additionally, most Windows login screens do not list a password hint, especially in a business setting. It is the last two items in the list that will create the greatest obstacle to using the updated NIST guidelines in a standard work environment.
First, there must be a way to compare the user passwords to a list of known dictionary words, passwords obtained from other breaches, etc. and do so DURING password creation. Doing this requires software that ties into Active Directory and has configurable policies and word lists. While a specific product will not be recommended here, two commercial offerings that come to mind are nFront Password Filter[2] and Anixis Password Policy Enforcer[3]. Standard vendor due diligence applies to either of these options, and any others discovered during a Google search.
Second, once passwords have been set, they should not be changed UNLESS there is evidence of compromise of the authenticator. The simplest method that comes to mind for most organizations is to periodically dump user password hashes and compare these hashes to large rainbow tables, such as the list of 555 million (yes, million) breached passwords hosted by the haveibeenpwned.com creator, Troy Hunt[4]. This list can, and should, also be used to check new passwords before the change is applied.
If an organization is willing to invest the [JS6] time and money into implementing the last two requirements above, and the changes do not go against any regulatory guidance by which the organization must abide, then a brave new world of no scheduled password changes and no password resets, will open up. If not, then the NIST guidelines cannot be adhered to and the same old settings must remain in place.
[1] https://pages.nist.gov/800-63-3/sp800-63b.html
[2] https://nfrontsecurity.com/products/nfront-password-filter/
[3] https://anixis.com/products/ppe/default.htm
[4] https://www.troyhunt.com/pwned-passwords-version-5/