Let’s explore the risk and some of the pros and cons of periodic password rotation. I’ll try to explore both arguments for and against rotation so you can decide if it makes sense for you or your organization.
Why would you ever want to change a password?
Changing passwords is an effective way to revoke access to users who are not authorized. If you change a password correctly, the old password is no longer useful. There are two main scenarios where this would be strongly recommended if not required:
Scenario #1: An authorized user who had access leaves the organization, and should no longer have access.
Even if an ex-employee isn’t disgruntled and left on peaceful terms, they may be curious and test their access. This is especially risky for systems which are accessible externally like SaaS applications or VPN.
Scenario #2: The password is leaked
If a password has been leaked (meaning it was disclosed or stolen), it should always be changed immediately. A leak could happen with hard-coded credentials in application code, or if a user has notepad.exe open with all of their passwords in it and is sharing their screen, or if they were phished (the most likely malicious scenario).
Why periodic password rotation?
So as far as you’re aware nobody has been phished recently, no employees have left the organization recently.. So why would you want to force changes to passwords?
Here are the arguments for password changing, either automatically or manually:
Reason #1: You don’t know what you don’t know.
Unless you’re directly responsible for managing all of the passwords for your organization, you have no guarantee they were not disclosed within the last 30, 60, or 90 days.
Reason #2: Limit attack surface
Simply put: the older a password is, the more likely it has been re-used elsewhere and was seen in some data breaches and has been cracked, or your users were phished. Additionally, if an attacker is on your network, they will likely slowly start to accumulate valid credentials. There is a chance that rotating the passwords can stop or at least slow down an attack which increases the chance of the attacker making a mistake and triggering a security alert.
Reason #3: Process (Special case for service accounts)
While ensuring users know how to reset their password is useful, it’s even more important to have system administrators be able to successfully rotate service or system account passwords. Having service or system account passwords changed regularly (manually or automatically) means it’s a known process and is possible to do without irreparable harm.
In other words, there may be urgent situations where a highly privileged production system account password is compromised and needs to be reset. Administrators need to be familiar with dependencies and it shouldn’t bring down systems for an unreasonable amount of time if a password is changed.
Reason #4: Individual attribution (Special case for shared accounts)
This is unique to shared accounts–but password rotation for shared accounts (check-in / check-out) can provide attribution and accountability because only one person knows the correct password at a time. In other words, you know who was using the shared account in case something bad happens. Usually this is automated with a privilege access management (PAM) solution.
Is periodic password rotation harmful?
Are the perceived benefits really benefits? Do they outweigh the cons?
Here are the arguments against periodic password rotation:
Reason #1: Rotation Frequency - Forced rotation comes too late, and doesn’t stop attacks.
Initial access happens fairly quickly after credentials are compromised. Once an attacker is in the network, they are going to spread laterally and set up persistence. Password rotation is not going to do much to stop them. (Especially because it’s not hard to guess what the next password is going to be if the current one is something like P@sswordQ12022)
Reason #2: User accounts - Nobody has time for the regularly scheduled password reset so they do a bad job
Your employees have work to do, so chances are they aren’t following password best practices when their work is interrupted by a password change prompt. Password changes interrupt their work-flow, and the path of least resistance is to set less secure passwords.
Put yourself in the shoes of a non-technical user. Memorizing “good” passwords takes work. Human memory is not made to remember computationally secure random passwords which is why most passwords chosen will likely not be random. Coming up with truly unique passwords also takes work. Someone might come up with a great password the first time they set it. The next time they set it, it’s probably not going to be unique from the last one, and if it is the chances are high it’s less secure. Most of the time oldpassword becomes oldpassword1 (or Oldpassword1! to meet the complexity requirements)
Because the user needs to change passwords as soon as they’ve remembered the one they set, a large percentage will take the current variation and write it down (or even worse, store it on their computer in plaintext) so they can remember.
Reason #3: Service accounts - The passwords are as long as encryption keys and nobody has them
In some cases, passwords may have been set using a randomly generated password, 64+ characters long with the full character set of symbols, numbers, upper-case, and lower-case. It’s set once, vaulted, and forgotten. It’s accessed only occasionally for new integrations.
Does changing the password in this case even matter or does it just waste time? All of the same risks still apply in this case, but there’s a strong argument to be made that changing the password is not necessarily going to improve security. In fact, it might increase distribution of the password because the security conscious system administrator cannot reasonably reset everything themselves in a reasonable time-frame.
Reason #4: Perspective from NIST SP-800-63B
Disclaimer: It’s important to provide some context here, NIST SP-800-63B is targeted at federal agencies implementing identity services. In other words, government websites whose users are the general public or are accessing the networks over the open internet.
If you’re trying to solve this problem for a public facing service where subscribers are accessing your content, it may make sense to consider the guidance from SP-800-63B.
From NIST SP-800-63B, Digital Identity Guidelines: Authentication and Lifecycle Mgmt:
“[…] 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.”
“Verifier” in this case is referencing the site or service which accepts an account password
“Memorized Secret” and “Authenticator” in this case both refer to an account password
In other words, NIST is recommending that password rotation (change) not be enforced periodically, but if any only if there is indications that a password has been leaked.
Conclusion
Rotating passwords is important, but forcing users to reset passwords may not actually improve security. At the end of the day, it’s important to consider your organization’s security controls and to show that the consideration and research has been done regardless of which way you choose to go.