Sophocles said, “No enemy is worse than bad advice."
If we assume that Sophocles was referring to actually acting on bad advice, it is easy to see how his sage words can be applied to Information Security some 2400 years after his death. In the first of a series on dealing with bad advice from an InfoSec perspective, Procella will examine an area that has a long history of misinformation: Password Hygiene.
Before examining an example of poor guidance one of Procella’s principals recently encountered personally, it’s important to note that passwords are often the elephant in the room. In most cases, Procella strongly advocates for moving away from traditional passwords in favor of passkeys or other FIDO2 authenticators.
With that PSA out of the way, on to the example:
For security purposes, passwords expire after 90 days. The data in our website is called Protected Health Information, or PHI; HIPAA (Health Insurance & Portability Act of 1996) requires the highest level of protection for this type of data.
The healthcare organization in question acknowledges the importance of protecting ePHI data, which is commendable. However, does expiring passwords every 90 days truly offer “the highest level of protection,” or is this practice just an example of the illusory truth effect–a phenomenon where repeated exposure to false information makes it seem true? Unfortunately, disinformation can persist even after it’s debunked because our brains tend to equate familiarity with truth. This seems to be the case with how many organizations handle password lifecycles. Despite numerous recommendations—and even mandates—from respected agencies and experts, backed by ample empirical evidence, many organizations still hold on to the belief that passwords should be rotated on a fixed schedule.
Back in 2015, one of the organizations that later became the UK’s National Cyber Security Centre (NCSC)1 published a list of recommendations titled “Password Guidance: Simplifying Your Approach." That document included seven tips that remain relevant today, with some adjustments made for the rise of remote workers and cloud-based services.
The seven tips:
- Tip 1: Change all default passwords
- Tip 2: Help users cope with password overload
- Tip 3: Understand the limitations of user-generated passwords
- Tip 4: Understand the limitations of machine-generated passwords
- Tip 5: Prioritise administrator and remote user accounts
- Tip 6: Use account lockout and protective monitoring
- Tip 7: Don’t store passwords as plain text
Let’s dig a little deeper into each of these tips:
Tip 1 is self pretty self-explanatory but just in case: default passwords should be changed immediately if there is any chance that a device will ever be accessed by anyone other than the intented user(s). Most obviously, this applies to anything that may be connected to a public or private network (including PCs, printers, IoT devices, etc.), as those passwords are known to every botnet and scanner in existence. However, this also applies to airgapped devices that may contain any kind of sensitive information or that could be used to collect it. Kiosks, libraries, that old electronic diary that’s in a box somewhere. The electronic recipe book with Oma’s secret recipe in it? Basically anything that can be perused, stolen, shared or otherwise accessed by anyone but a legitimate user of the system should have its default password changed and securely recorded. Which brings us to tip 2:
Tip 2 recommends using password managers (with appropriate caution, as they are valuable targets) and discarding the outdated practice of changing passwords on a fixed schedule.
Most administrators will force users to change their password at regular intervals, typically every 30, 60 or 90 days. This imposes burdens on the user (who is likely to choose new passwords that are only minor variations of the old) and carries no real benefits as stolen passwords are generally exploited immediately. Long-term illicit use of compromised passwords is better combated by:
- monitoring logins to detect unusual use
- notifying users with details of attempted logins, successful or unsuccessful; they should report any for which they were not responsible Regular password changing harms rather than improves security, so avoid placing this burden on users. However, users must change their passwords on indication or suspicion of compromise.
Tip 3 addresses the problems with human-generated passwords and advises against enforcing complexity rules, which often lead to predictable substitutions. Instead, the focus should be on blocking common passwords and educating users on how to create strong ones. Procella also recommends increasing the minimum password length and removing any maximum length restrictions for systems that support it, as long as those systems don’t truncate passwords.
Tip 4 suggests making machine-generated passwords memorable, though Procella generally advises against this. While machine-generated passwords offer significant security advantages, they can be hard to remember, placing unnecessary burden on users (see Tip 2). Procella instead recommends memorizing only a few key passwords, such as those for unlocking your computer or accessing your password vault, while securely storing the rest in the vault without attempting to memorize them.
Tip 5 advises against using administrator accounts for day-to-day operations, which remains best-practice advice. However, it limits the recommendation for additional authentication (such as tokens) to remote workers. Procella, on the other hand, recommends Multi-factor Authentication (MFA) or Passkeys for all human-operated accounts, not just those used by “remote workers.” With cloud services, every worker is effectively remote, regardless of their physical location.
Tip 6 suggests throttling failed login attempts rather than locking accounts, to improve user experience and prevent easy denial-of-service attacks by malicious actors. Additionally, there are now more effective ways to minimize brute-force attacks without disrupting users or business processes.
Tip 7 is completely self explanatory and could easily be considered a subpoint of TIp 1.
As illustrated by the NCSC list, the shift away from scheduled password rotations is not new. In fact, this advice is nearly 10 years old—a significant period in the evolution of information security—but it remains surprisingly relevant today!
The latest guidance from NCSC now has 6 tips:
- Tip 1: Reduce your organisation’s reliance on passwords - use Single Sign-On (SSO) and/or MFA
- Tip 2: Implement technical solutions - throttle, monitor for abnormalities and use deny lists for passwords
- Tip 3: Protect all passwords - encrypt in transit, hash at rest and protect the access management system
- Tip 4: Help users cope with password overload - password vaults and don’t force rotation except when compromise is known or suspected
- Tip 5: Help users to generate better passwords - focus on machine generated, do not enforce complexity rules, use a strength meter
- Tip 6: Use training to support key messages - don’t reuse passwords, what is a good password and how to use password vaults
Many of the tips are repeated, included Procella’s favorite: reducing reliance on passwords altogether.
Some strong guidance from the UK but how about the US?
In 2017, NIST published password guidance in Special Publication 800-63B, section 5.1.1 Memorized secrets. The language is verbose but had similar guidance to NCSC at the time. In August of 2024, NIST also published a draft update to 800-63B that simplified some of the language from the previous publication and strengthened a number of “SHOULD NOT” recommendations to “SHALL NOT” requirements, most notably related to password rotations and composition rules (e.g., requiring mixtures of different character types). In other words, to comply with NIST standards (as emphasized by Procella), users must not be required to change passwords periodically.
The updated requirements include:
3.1.1.2 Password Verifiers
The following requirements apply to passwords:
- Verifiers and CSPs SHALL require passwords to be a minimum of eight characters in length and SHOULD require passwords to be a minimum of 15 characters in length.
- Verifiers and CSPs SHOULD permit a maximum password length of at least 64 characters.
- Verifiers and CSPs SHOULD accept all printing ASCII [RFC20] characters and the space character in passwords.
- Verifiers and CSPs SHOULD accept Unicode [ISO/ISC 10646] characters in passwords. Each Unicode code point SHALL be counted as a single character when evaluating password length.
- Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.
- Verifiers and CSPs SHALL NOT require users to change passwords periodically. However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.
- Verifiers and CSPs SHALL NOT permit the subscriber to store a hint that is accessible to an unauthenticated claimant.
- Verifiers and CSPs SHALL NOT prompt subscribers to use knowledge-based authentication (KBA) (e.g., “What was the name of your first pet?") or security questions when choosing passwords.
- Verifiers SHALL verify the entire submitted password (i.e., not truncate it).
Many other organizations, including Microsoft and the US FTC, have adopted similar policies and/or made similar recommendations while quoting numerous studies and other empirical evidence. Passkeys and other technologies that either replace or supplement traditional passwords continue to gain traction. However, many companies still require their customers and users to follow outdated and unsafe practices for managing their credentials. If only Sophocles were alive to offer his guidance.
In closing, in case you were wondering, the site that was the impetus for this post does have its own set of password requirements:
Minimum 8 characters Must not contain username in any part of it Cannot be the same as any of the last 10 passwords used At least 3 of the 4 following conditions must be present: One upper case One lower case One number One special character (~!@#$%^&*_-+=`|(){}[]:;.?/)
Unfortunately, in addition to several of their requirements not being NIST-compliant, they also do not offer MFA or any security stronger than a password, relying instead on the implicit trust typically given to healthcare providers to justify its questionable policies. This underscores the importance of considering the source when evaluating advice.
Should the healthcare organization in question update their password policy? Probably, since they are claiming compliance where it doesn’t exist. Should you rush to change your password policy? Perhaps, but it’s likely you’ll need to adjust other policies as well, and prioritizing this within your already busy cybersecurity program can be challenging. Procella provides assessments and expert guidance to help you develop a strategic roadmap for enhancing your security posture.
-
The original guidance has since been updated and folded into the 2018 document: https://www.ncsc.gov.uk/collection/passwords However, the 2015 date comes from this 2016 blog post: https://www.ncsc.gov.uk/blog-post/problems-forcing-regular-password-expiry ↩︎