Password expiry policy may have reached its expiry date

[ZippFire]

Hi people,

I've read a document from the NCSC in the UK about, Your Password expiry policy may have reached its expiry date.

They state that....

I quote:

'Password expiry is an effective way of mitigating the risk when passwords have been deliberately (if illicitly) shared between users.'

or

'Password expiry can be used to make sure people don't forget that passwords do still need to be changed sometimes, just because they're no longer forced to do it regularly.'

These scenarios certainly happen, and password expiry could be one way of seeking to manage some of the risks. However, password expiry policies create vulnerabilities of their own. 

If we believe that if regular password expiry really looks like a good idea, that's a sign that your organisation has bigger problems and needs to look for correspondingly bigger solutions:

• If your users are deliberately sharing passwords despite being told not to, maybe they don't have workable official ways of securely sharing information? You can fix that by providing modern information-management tools that will boost your business productivity (and strengthen your security) far more than expiring passwords ever can.
• If your users aren't changing their passwords after sharing them with others, maybe they don't understand their important role in helping your organisation to secure its information, manage and audit access? If that's the case, forcing them to change their passwords won't help them to improve their overall approach to managing your organisation's information risk.
• If you think you need to keep expiring passwords regularly so that people won't forget how to change them when they do need to, that implies that your organisation's password change process is clunky and unintuitive. Any password change process that users can't instantly navigate with no training or background, is too clunky. In this case, we believe it is better to un-clunk the process rather than spend everyone's valuable time and energy trying to train them to clunk it better.

In all of these cases, password expiry might initially look like a quick and easy way of helping to manage the risks. However, it rarely delivers the headline benefits it promises, and mostly just creates fresh vulnerabilities instead. It pushes people towards using weaker passwords, writing them down, re-using them across different systems and changing them only in tiny ways (eg adding 1 to the number on the end every time). Attackers can and do exploit all these dodges. It disrupts our workflow, reduces our productivity and increases helpdesk costs.

I think it's true, if people need to change their passwords, then 40% will come to the helpdesk with the problem of changing their passwords.

If we help the users to create a strong password and educate them trought awerness training and face to face talks, that they dont's write down passwords or tell them to others. I think it's better then just changing te password with a subsequent number.

What are you thoughts about this?

[Badfilemagic]

Forced password rotation and artificial complexity rules generally lead to users picking a password that meets the requirements, typically with digits at the end, and then incrementing the digits. More complex requirements lead to writing them down.

I am in favor of longer allowed passwords to allow for more unique pass phrases, enforcing a minimum conplexity but also requiring multifactor authentication with smart cards or some other token. 2FA, even for local logins, is less of a burden on the user than password rotation and prevents people from making habitually bad choices that at nearly indistinguishable from doing nothing except from the false sense of having done something that they provide.

NIST guidelines in the US have been revised to remove the recommendations for password reuse (finally) for the same reasons. It doesn’t work and is user hostile.

On the other hand, if you have a no password rotation except on compromise or user initiated request policy and then suddenly force an organization-wide password reset, then people who don’t necessarily need to know will probably figure out something is up. That may or may not matter to you.

[Early_Adopter]

"Let me generate a strong password for you..." 🙂

It's very probable that the cadence of change should be varied to the threat you are expecting, too much disruption is a bad thing.

AS WDF points out If you have the luxury of resources to do so you should seek to use 2FA and besides smart cards you support user's passwords with other factors like known devices with certificates, proximity of mobile devices(use smartphones for active push of approval as well), UEBA, biometrics etc and step-up the analytics around authentication if just a password is being used. Modern IDPs and using trusted devices means you probably do not put so much emphasis on passwords being changed.

Maybe an random offset for change window between 6-12 months would address the problem of inference about a unscheduled password reset, while letting users keep passwords for a more reasonable legnth of time.