The 90- Day Password (Must Go)
When was the last time your bank asked you to change your password?
When was the last time your company asked you to change your password?
If you’re like most people, the answer to the first question is “never” and the answer to the second is “every 60 or 90 days.” So why do companies require password changes every 90 days? It is most likely because of a legacy of doing so or because of compliance to some security architecture such as PCI or HITRUST. Let’s dig into these.
PCI DSS requirements state the following: “Change user passwords/passphrases at least once every 90 days.” (8.2.4). The explanation included with the requirement states the passwords not changed frequently are more likely to be hacked by a malicious individual. I would agree this is true if you follow their minimum guidelines of an alphanumeric 7-character password.
But PCI also has an infographic on their website showing the time to crack a good password. So why not just change the requirement to exceed the current minimum to something that could allow for a longer password life? And as long as I am ranting, does anyone see an issue with the sample they used on this infographic or a core word? The words “burger” and “hamburger” are way too common and would quickly be hacked in a long password.
So 90 days is the PCI password change requirement, but no good reason why.
HITRUST is more detailed in their requirements and has multiple levels. But all levels require minimum passwords similar to PCI and password changes at 60 or 90 dats in most cases.
So 90 days. But no reason why.
Now let’s look at the most recent NIST guidance. NIST Special Publication 800-63B describes the expectations for “Memorized Secret Authenticators” (means passwords or pass-phrases). Se section “5.1 Requirements by Authenticator Type” for a detailed explanation of the process. In particular the following is stated
When processing requests to establish and change memorized secrets, verifiers 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:
- Passwords obtained from previous breach corpuses.
- Dictionary words.
- Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’).
- Context-specific words, such as the name of the service, the username, and derivatives thereof.
If the chosen secret is found in the list, the CSP or verifier SHALL advise the subscriber that they need to select a different secret, SHALL provide the reason for rejection, and SHALL require the subscriber to choose a different value.
The more significant quote pertinent to my topic is this one taken from “5.1.1.2 Memorized Secret Verifiers”:
Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. 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
So if we follow NIST’s guidance to the letter we would never require a password change as long as we are following the other NIST guidelines.
The “Appendix A—Strength of Memorized Secrets” is labeled as informative but it provides good rationale for my position that 90 day password changes should be abolished/modified.
So, Martin, what do you suggest?
- Use a password dictionary and other tools to verify the password chosen is not already compromised or not easily compromised.
- Prohibit using any portion of a prior password longer than “X” characters (you choose the value for “X”).
- I recommend a 15 character minimum. This prevents the password being subject to the LAN manager hash risk in Windows. (See this Microsoft document.)
I welcome your comments!