To expire a password or not to expire?

Let’s discuss one of my more “unpopular” opinions.

Microsoft states in its documentation the following:

Password expiration requirements do more harm than good because these requirements make users select predictable passwords, composed of sequential words and numbers that are closely related to each other. In these cases, the next password can be predicted based on the previous password. Password expiration requirements offer no containment benefits because cybercriminals almost always use credentials as soon as they compromise them.

Source: Password policy recommendations – Microsoft 365 admin | Microsoft Learn

If you go deeper into the secure score recommendation that are displayed in the security portal, there they add nuance to their password expiration:

Research has found that when periodic password resets are enforced, passwords become less secure. Users tend to pick a weaker password and vary it slightly for each reset. If a user creates a strong password (long, complex, and without any pragmatic words present), it should remain just as strong in the future as it is today. It is Microsoft’s official security position to not expire passwords periodically without a specific reason, and recommends that cloud-only tenants set the password policy to never expire.

Source: security.microsoft.com > secure score

So in the secure score they recommend that disabling the password expiry is only for cloud-only tenants. That is a big nuance! But what is now the correct statement of Microsoft? The one in the docs or the one in the Secure score of the security portal? (see screenshot)

My (potential) unpopular opinion

And here may come my unpopular opinion, but it is based on real-life experience that I encountered in security incidents or helping customers.

Do you detect breaches real-time, always and every time?

They mention that threat actors almost immediately use the passwords when compromised. But how many organizations discover all of their breaches? I’m not claiming that a password expiry protects you from breaches, but the impact of the breached password is at least limited in time.

Password re-use

While reusing passwords is a bad practice, in reality, it is expected to happen more often than we wish. End-users might often start with a common password. For example, they will reuse the password of their personal email address to initially set the password of their working account. A password expiry would, over time, force the user to deviate from the original and similar password of their private email address.

Password dumps / password manager breaches

Have you seen those password dumps on the dark web? They contain lists of passwords. And each time they publish a new list, all of the older passwords are copied into the new list with the freshly compromised accounts. If you are never forced to change your password and you don’t know that somebody is looking along, well, the next buyer of the password might get lucky if he tries the older combinations. What about the lastpass breach that leaked all of those passwords? Password expiry is a way that these passwords will organically rotate over time.

Shared accounts

Password expiry also deals with those pesky ‘shared accounts’ in production environments. Be honest, have you completely gotten rid of them? Do you still want that a former employee still knows the password of the account that that is crucial for your production?

Is your offboarding perfect?

How many companies have a perfect offboarding procedure where they remove all access to all of the accounts the user had access to?

SSPR is a first aid skill!

The password change wizard closely resembles the SSPR flow. Understanding self-service password reset (SSPR) is just as crucial as implementing MFA. If users never need to change their passwords, they may struggle with performing a reset when necessary. This can become a significant hurdle when a Conditional Access policy mandates a password change during high-risk situations, causing frustration for end-users. Moreover, when users doubt the security of their accounts, a password change is a proactive step that never causes harm.

Solutions

Now, let’s explore potential solutions that contribute to more safety:

  • Implement robust Conditional Access baselines to enhance security measures. Passwords shouldn’t be your only line of defense.
  • Utilize password managers to mitigate concerns about predictable password changes. If user don’t have to remember passwords then they don’t need to small changes that make them predictable.
  • Enforce a strong password policy, emphasizing length and complexity, and encourage the use of sentences.
  • Consider implementing solutions like Entra ID password protection to block common password words and their variations to enhance overall password security.
  • Go passwordless ❤️

I’m not saying you should do a password change every 3 months. NIST takes the standpoint that a password change every year is a good practice or when an account is breached.

Source: NIST Password Guidelines 2024 | AuditBoard

My standpoint

Some people are supporters of “password never expires” for regular users; If you have a SOC and you have everything Entra ID integrated and a perfect offboarding procedure, sure.

But in reality, for companies who lack all of this, I’m not fond of it 🙂

Disclamer:

I am taking a stance to encourage an educational discussion and opening my mind to perspectives from individuals with differing or like minded opinions.

Leave a Reply

Your email address will not be published. Required fields are marked *