What is it about a secure password that makes us think it’s secure?
Traditionally, for businesses it’s been things like complexity, minimum length, avoiding known bad passwords, and how often passwords are changed to counter the possibility of undetected compromise.
And yet, recently, the last of those orthodoxies – password expiration – has started to crumble.
In 2016, the influential US National Institute of Standards and Technology (NIST) broke with generations of received wisdom by recommending that scheduled password change should be dropped from the list of good practice on the basis it now does more harm than good.
This week, the mighty Microsoft joined them in no uncertain terms in a blog explaining the company’s security baselines for the forthcoming Windows 10 version 1903, due in May. Microsoft’s Aaron Margosis didn’t mince his words:
Periodic password expiration is an ancient and obsolete mitigation of very low value, and we don’t believe it’s worthwhile for our baseline to enforce any specific value.
Windows baselines aren’t just a set of recommendations written down somewhere that nobody reads – defining how the world’s most popular business OS should be secured by businesses, these matter.
At the last count, Windows 10 had 3,000 of them (including many not related to security) implemented as Group Policy Objects. Having these parameters set up means that IT staff don’t have to configure everything from scratch as well as helping with the ordeal of compliance.
If NIST downgrading the importance of password expiration was a big marker, Microsoft doing the same signals that change is coming in the real world.
Why password expiration doesn’t help
At first glance, password expiration sounds sensible because, as numerous security compromises demonstrate, passwords today are often stolen and abused long before their owners realise.
Logically, then, changing them on a schedule should minimise the risk by reducing the length of possible compromise to a defined period of weeks or months.
In the consumer space, it’s become such an accepted part of security that password managers urge users to update their passwords regularly and offer mechanisms to automate this for big internet sites.
The problem is that this can have unintended consequences, which can render the effort worthless. As Microsoft’s Margosis writes:
When humans are forced to change their passwords, too often they’ll make a small and predictable alteration to their existing passwords, and/or forget their new passwords.
In effect, users are not really changing their passwords, just tweaking them so they’re easier to remember. In the worst-case scenario, this might include using the same tweaked password across multiple sites, a habit that fuels password-stuffing attacks.
Notice that although Microsoft no longer recommends a specific password expiration value, there’s nothing to stop organisations implementing one if they want to.
It could be that Microsoft’s angst over its baseline is really asking a deeper question – should baselines and the endless compliance that follows in their wake be that important anyway? Margosis again:
Removing a low-value setting from our baseline and not compensating with something else in the baseline does not mean we are lowering security standards. It simply reinforces that security cannot be achieved entirely with baselines.
As recent announcements from Microsoft have made clear, everyone would do better to move to more sophisticated forms of authentication.
Stuart
So true, I see the password patterns at work, just add another number, easily guess-able! The other problem though is some institutions, like our BACS auditors, insist on a password expiry policy otherwise we fail the audit and lose our accreditation!
Simon McAllister
Absolutely. Don’t ‘force’ users to change passwords unless known to be compromised/breached. But ensure users can change passwords (and know how to) if/when the need to arises.
However, the caveat is: unknown password breaches e.g. Yahoo. So the above should partner with 2FA.
Eddie
I see your point but i think that the users who will change their passwords without being forced are the ones that will not fall for phishing emails and other scams as easy. The staff i worry more about are the ones who never change their password because its easy and it works. In my (albeit limited) experience these are the users i worry more about giving their password out.
Simon McAllister
If they choose to change their passwords without being forced Eddie, then they are probably ‘comfortable’ to do so – and I assume they have their own reasons to change them. For staff that you are concerned about, you can implement control policies that prevent using ‘easy’ passwords, backed up by a written company policy that enforces it further. For users giving out their passwords; 2FA can help prevent that
Robert Smith
Sound reasoning for this policy, but need to watch that IT and Development teams do not fall into bad habits. Our organisation changed to a non expiring password policy last year. It just enabled the admin IT and DEV teams to start following poor operational practices by using their own accounts for running services, tasks and scripts. Then when they left all the services they had built stopped working when the account was disabled.
Bryan
ouch. What a crappy dead man’s switch. Not always entirely unintentional.
John Lukes
Hi Robert
I see your point but shouldn’t services be run with service accounts, thus mitigates that risk?
Bryan
That was Robert’s point. Some administrator or coder creates a recurring job to perform a daily (hourly? monthly?) function. During the test phase, the user’s account is easier, since you’re already logged in, and you won’t be prompted for the same password 50 times after this or that step fails on a typo or unanticipated permission challenge.
After the job is proven to be roadworthy, it’s important to remember updating to the proper credentials.
For testing I prefer to be logged in as the account who’ll eventually run the task, but that’s not always possible, and it comes with drawbacks too.
Bryan
I meant to add… expiring passwords will reveal with 90 (45, 30, 180) days that final step was forgotten.
Ron
Another point that seems to be missed with password rotation is that if your password is compromised, it’s already too late. Hackers don’t waste time. Once they’re in and chaining exploits, you’re pwned within a few hours at most. If it’s not compromised, continuing to use it correctly will not lead to it being compromised. Thus rotation has zero benefit.
Anonymous
I guess I have mixed feelings about this. When using Microsoft Authentication 2FA, we are shifting the security from the user to the device. Gaining access to the device provides access to the accounts and authentication, even without a user or their password. Microsoft wants to push for users to use their app which allows them to collect behavioral data, which has a lot of value on these days… I don’t want to make my users cautious about another app…
William Randleman
The article fails to point out that NIST-800-63B also recommends MFA for moderate impact information, such as PII.
The NIST recommendation is not simply to drop maximum password life.
Anonymous
While i used to agree about password changes being more trouble than any real world prevention, my thoughts on this has changed in the last year or so. The reason for this is while yes most of the time you would know about any compromise immediately this would be only for certain areas like banking, gmail, outlook, mobile phone companies etc.. other sites, corporate are more likely not be affected immediately.
And I would probably take a guess that 95% of users use the same password/email combo across everything therefore if 1 website has a breach then everything is compromised. So from a corporate point of view I now ensure password expiry/changes until we implement some 2fa because we cannot trust users to use a different combo from other sites.
While most users probably just change 1 detail be it a number or something, you can implement stricter changes that require more than that to be different. and by time a would be infiltrator breaks in hopefully the security measures have locked out the account after x attempts, or geo locking ips, working hours etc…
But just how far you go to secure your systems? 2fa seems like the happy medium to solve this for the most part, just about educating end users to the risks and make it as pain free for them as they are generally your security weakness.
RiC 'n' Wrestling (@ViolentRiC)
Something I *really* want security systems to move away from even more than this is forcing you to create a password you’ve never used before even when it’s never been compromised. This is maddening because it perpetuates a cycle of not remembering your password (particularly if you rely on autocomplete and don’t have those cookies), resetting it (instead of it being revealed via e-mail/text etc.—keeping in mind you’d be granted access either way so why not reveal your existing password instead of a new one?), having to choose something you’ve never used before, forgetting that password because it’s not one from your pool of personal passwords, resetting it again, having to add more variations that you’ll forget, and eventually running out of ideas for things to tack on just so it will be accepted and later forgotten because it’s variation #63.
The two problems with passwords are:
1) The solution to non-memorably passwords is to record them somewhere. If you store that list on a computer or phone then that could potentially be accessed like a treasure trove giving access to everything, and if it’s work related then you can’t keep them written down anywhere so it has to be on a hard drive of some sort.
2) You can’t go through your entire pool of favourite passwords either because you’ll be locked out after a few incorrect entries.
3) Any system is only as secure as its method for resetting passwords when forgotten, and the more you force people to come up with new passwords the more they’re going to be forgotten.
It’s reached the point where I’ve just stopped using some sites/accounts because I’ve passed that tipping point of having to create so many new passwords that even if I could remember every password in my personal pool, it’s so large that I have no idea which one it is for any given site/e-mail address etc.