Never expire passwords? Why we shouldn’t ditch password expiry just yet.
Resetting passwords via service desk tickets and support calls is an everyday burden on IT teams. Users are equally frustrated when the ‘time to change your password’ notification pops up during a busy work day – especially when they realize they can’t simply add ‘!’ to the end of their old password. But despite IT team and user frustration, enforcing password expiry at regular intervals has been standard practice in organizations for some time.
In recent years this practice of regular expiry has been challenged, with Microsoft even stating that password expiration ‘does more harm than good.’ However, getting rid of regular password expiry, while attractive to an overburdened IT team, isn’t the best choice for most. The biggest reason? Lack of confidence in being able to detect compromise. Since most organizations lack the ability to detect account takeover incidents immediately, regularly expiring passwords remains an important mitigation tool for protecting against the danger of password reuse.
Let’s take a look at the state of password expiry, the reality of the attacks it can help protect against, and the alternative options available to IT teams.
Where does the standard 90-day reset come from?
It’s rare to store passwords as plain text in modern times – organizations using Active Directory store them as hashes. This means their list of employee’s true passwords are scrambled via cryptographic hash function (CHF). When an employee enters their password, the organization has to run it through the CHF and confirm the result matches the hashed password stored in their database. Because of the one-way nature of these hashing algorithms, attackers need to use cracking methods.
Essentially, hackers need to try and guess passwords through brute-force attacks. They’re forced to work out the hashing algorithm that’s being used and then test possible passwords by running them through the algorithm and comparing the result to the hashed password accepted by the platform. Organizations can complicate the process further through salting – a technique where a random string of characters is added to each password before hashing.
Brute-force attacks aren’t an exact science, especially when hashing and salting have been employed. The time to crack a password depends on a few factors including the computational power available to the cybercriminal and the strength of the password. However, the general thinking from security specialists was that 90 days offered the best balance between out-pacing brute force attacks and not forcing users into too frequent password changes. Of course, IT advances quickly, and recent advances in automation and hardware have reduced cracking time.
This time-to-crack security thinking led to many recommendations and compliance standards including the 90 day expiry requirement. Until about six years ago, a 90-day expiry was the standard recommendation from NIST – and is still the current recommendation for PCI.
Why do organizations want to get rid of password expiry?
One argument against regular expiry is that they encourage people to re-use weak passwords, making slight incremental changes to the same password each time. For example, Mallorca1! becomes Mallorca2! as the employee wants to keep the memorized password they’re used to using every day. The real issue with this argument though is the organization’s policy allowing weak passwords, rather than the act of resetting itself.
But what if people are forced to regularly reset to a unique, strong password? User experience can be a barrier here, with people getting frustrated at having to think of new, strong passwords, especially if the organization isn’t using a reset platform that offers help or guidance. Ultimately though, it’s a relatively small annoyance factor for employees – nobody is going to dust off their résumé because they had to reset a password. The real problem with forcing regular expiry is the service desk burden that often comes with it.
From the organization’s standpoint, there’s a cost factor to resets. According to Gartner, between 20-50% of IT help desk calls are for password resets. Data from Forrester Research estimates that the labor cost for each password reset is around $70 – which adds up when people keep forgetting passwords after being forced to pick a new, unique one. And of course, once reset, the cycle begins again with the user needing to create another new password.
Do we need regular password expiries at all?
You’d never want to be without an effective and fast system for resetting passwords, as there’ll inevitably be occasions when they need to be immediately changed. For example, if an account was hacked, credentials were leaked in a data breach, malware is found on a device, or an unsecured network was used. There are even occasions when a mass ‘reset all Active Directory passwords’ is needed for a whole organization.
So, if we have fast effective ways of resetting passwords when needed, what purpose does an expiry policy serve?
Password reuse is one reason why expiry can be useful. Let’s say an organization has a strong password policy and has enforced every employee to create a strong passphrase. What happens if the employee decides to use this password for their Facebook, Netflix, and all other personal applications too? A study by Google found 65% of people reuse passwords. The risk of the password being compromised increases a lot, regardless of the internal security measures the organization has in place.
‘Never expire passwords’ offer opportunities for hackers, especially when so many fail to meet basic security requirements. Hackers can stay under daily lockout attempts for longer, having more time to guess. And even if a password is strong, it can still become compromised through a phishing attack, data breach, or other cybersecurity incident without the user’s knowledge. Our 2023 Specops Weak Password Report showed that 83% of compromised passwords satisfied the length and complexity standards of regulatory password standards.
It’s not always possible to tell when credentials have been compromised until an attacker has struck. The Ponemon Institute estimates it takes an organization an average of 207 days to discover a breach. A forced password expiry might help, but realistically an attacker has likely done what they intended to before the expiry comes around. This is why NIST, and other standards tell organizations that they only recommend setting passwords to never expire if tools are in place to detect compromised accounts.
What can organizations do instead?
Password expiries can help prevent password reuse, but they need to be used as part of a wider password strategy. The best approach an organization can take is to put a policy in place that guides users to create strong passphrases of 20 characters containing different character types. As the below table shows, this can greatly reduce your vulnerability to a brute force attack.
One way to encourage users to create longer passwords is through length-based aging. The idea behind length-based aging is longer, stronger passwords can be used for a greater period of time before expiring. So, there’s no need for a one-size-fits-all expiry time of 90 days (save for needing to comply with a standard like PCI), as long as end users are willing to meet the password policy settings an organization sets.
However, even strong passwords can be compromised and there need to be measures in place to detect this. As once compromised, the cracking time for a password in the bottom right of the above table turns to ‘instantly.’ Organizations need a joined-up strategy to make sure they are covering themselves against both weak and compromised passwords.
If you’re interested in managing all of the above in an automated way from a simple-to-use interface within Active Directory, Specops Password Policy could be a valuable tool in your cybersecurity armory. Through its Breached Password Protection service, Specops Password Policy can continuously check and block the use of more than 4 billion unique known compromised passwords.
(Last updated on February 23, 2024)