Earlier this month, on March 2, NIST formalized a significant number of changes to its password recommendations as part of the final release of its updated Digital Identify Guidelines document or NIST publication SP 800-63-3. The full document which includes three additional sister documents (800-63A, 800-63B & 800-63C) is here:
https://csrc.nist.gov/publications/detail/sp/800-63/3/final
It's a bit of a tough document to read and has a lot of information for system designers, code-writers and software developers in it. The changes gathering the most end-user and systems administrator attention are below:
- Increase the minimum length of passwords to at least 15 characters – and allow as many as 64 characters. Password length does more than any other password characteristic in making it difficult for brute force password attacks to be successful due to the increase in resources required to crack it for each additional character in the password. This recommendation now leans towards the idea of a pass "phrase" rather than a pass "word" to make it easier to remember a long string of characters for passwords.
- Eliminate routine periodic password change requirements – After extensive research, NIST determined (and the FBI has concurred) that passwords with 90 days or shorter lifecycles present more risk. Users find "creative" ways to keep track of new passwords that, more often than not, turn out to be counterproductive to good password security. The new recommendation is that password changes should only happen when there is evidence of a possible security breach (compromised credentials) or other use case requires that change.
- Eliminate the song and dance around password complexity – no more requirement for uppercase, lowercase, numbers, and special characters. Humans have tended to add these characters in predictable patterns that have been easy to guess for the bad actors. So, like the password change requirement, this outdated rule has been shown to do very little to prevent password compromise and sometimes has resulted in worse passwords.
- Require applications to screen new passwords against a list of commonly used or compromised passwords – this one is not for us as end-users but is a strong recommendation for all application developers and service providers. The idea here is to prevent allowing users to select known bad passwords (like "12345678" or "Password") or other commonly used passwords that are known to be compromised in the wild. Expect to see more password checking done at the application level as time progresses.
A few of these changes surprised a number of folks and it’s going to be interesting to watch to see how fast other entities pick up on these significant recommendation changes. For me, all of this makes a lot of good sense. It mirrors the problems and feedback on passwords we have seen in the field.
When I have talked about these changes with Tech Directors to-date, their primary concern has been with auditors and how fast they will adjust their existing standards from the old 8-character, highly complex, change every 90-day rules.
With NIST formally publishing its updated recommendation on March 2, 2020, I would hope the standards change would come quickly.
Or, if you were so inclined to implement the updated best practices right away, I think it would be pretty easy to justify the action by directly pointing them to the relevant updated NIST documents. I would think it would be hard to argue about keeping current with the most updated security best practices issued by the national body responsible for such things and whose standards schools are all now required to follow.
You must be logged in to post a comment.