The National Institute of Standards and Technology (NIST) has issued a new draft of its Digital Identity Guidelines. The Special Publication, 800-63-3, includes sections that cover Enrolment and Identity Proofing Requirements, Federations and Assertions guidelines, and Authentication and Lifecycle Management.
While each of these documents are helpful in many regards, the one that will impact the security industry with the broadest reach is the Authentication and Lifecycle section. This section has some very advanced, yet timely guidance about passwords, or as NIST likes to call them, “Memorized Secrets”.
To quote the document directly (in which I have bolded three key items):
- When users create and change memorized secrets:
- Clearly communicate information on how to create and change memorized secrets.
- Clearly communicate memorized secret requirements.
- Allow at least 64 characters in length to support the use of passphrases. Encourage users to make memorized secrets as lengthy as they want, using any characters they like (including spaces), thus aiding memorization.
- Do not impose other composition rules (e.g. mixtures of different character types) on memorized secrets.
- Do not require that memorized secrets be changed arbitrarily (e.g., periodically) unless there is a user request or evidence of authenticator compromise.
- Provide clear, meaningful and actionable feedback when chosen passwords are rejected (e.g., when it appears on a “black list” of unacceptable passwords or has been used previously). Advise users that they need to select a different secret because their previous choice was commonly used.
In case that paragraph did not make your eyebrows go all the way up to your hairline, NIST now recommends that we no longer force periodic password changes and we no longer should force complexity requirements. In the appendix in the same section of the document, the strength of “memorized secrets” is explored in a beautifully concise and accurate manner.
Folks like Graham Cluley, Per Thorsheim, and many others have been promoting these ideas for years, and it is as if NIST has not only listened; they heard!
I have to admit that even I was late to this party, and once I changed my view, I have had a hard time convincing the old password stalwarts of the new paradigm now codified by NIST. I plan to post a framed copy of this new model at my desk as soon as it is in its final published form.
What do you think? Would your staff prefer to make one long password that they only have to change if there is a compromise, or would they still prefer the complexity and forced change requirements that have failed us in so many ways?