There’s one legitimate use case for password expiration policy that often gets ignored.
If a password is compromised the attacker can possibly quietly access a system behind a user’s back and siphon out information for years and years.
For example the CEOs email password has been compromised and a hacker establishes a script to siphon out and archive messages which could last for years.
A password expiration policy limits this risk by setting a time window.
If you don’t have that you can potentially get into situations where you can not reliably determine what has been compromised and what hasn’t been.
Password expiration gives you a frame of reference for when the compromise could and could not have happened.
The problem with this reasoning is that it ignores the initial attack vector; how did the attacker compromise that password in the first place? It doesn’t just magically fall out of the sky once and then never reappear again.
Very often you’ll find that the password was obtained by compromising a victim’s computer, breaking into an auxiliary system that shares the same passwords, and so on. In these cases it is absolutely useless to change the password, because the attacker could just as easily obtain the new password and continue their business.
There’s a small set of cases where a time window might limit exposure, such as reused passwords in password dumps; but 1) these cases are better mitigated by preventing low-entropy passwords, 2) you’re still vulnerable for 3 months or whatever your window is, which is more than enough time to siphon out all information from most networks, 3) you’d be much better protected by just having proper monitoring of user sessions in the first place.
Is there theoretically a nonzero benefit to password expiry? Yes, but only if your security is already otherwise lacking, and even then it’s not a common case, and at that point it’s absolutely not worth it considering the big downside of forced password expiry: it incentivizes people to pick worse passwords, because remembering complex passwords is a big time investment that’s no longer worth it.
This would indeed work if you can use a password manager at that point. If it is at the login prompt, you usually can’t use a password manager. If web service X has a policy to change password every Y months, it wouldn’t be much trouble, I just use my password manager. I do that occasionally (manually) anyway for social accounts.
Also, as the article suggest, for the particular threat you mention, you’d better use 2FA to mitigate that.
Just got an email internally telling us the password expiration window has been reduced from 180 days to 90 days. There’s no use sending this article to the powers that be internally, somewhere there’s a checkbox in a security window dressing form that requires 90 days expiration and that’s what it’s going to be.
It’s doubly awful when you have a couple of disjoint authentication domains, say an AD arena and a UNIX one, and they have inconsistent expiration periods, length & complexity requirements, and reuse policies.
Best of all are the systems where you can’t change your password until it expires, thus making it impossible to keep in sync with other domains.
I wonder how many of these “best practices” are simply word-of-mouth beliefs handed down from management to management with little control over exactly how well they’re sourced.
Oh well next password change here will be a passphrase. I’ve been relying on a little C program that generates nicely pronounceable passwords but it’s time to uppgrayed I think.
There are usually numbers and special characters required where passwords expire. Then it ends with this required number being incremented with wraparound near N. Where N is remembered passwords count to prevent reuse. Also I heard about changing passwords N times few days before expiration, so you can use then the same password.
There’s one legitimate use case for password expiration policy that often gets ignored.
If a password is compromised the attacker can possibly quietly access a system behind a user’s back and siphon out information for years and years.
For example the CEOs email password has been compromised and a hacker establishes a script to siphon out and archive messages which could last for years.
A password expiration policy limits this risk by setting a time window.
If you don’t have that you can potentially get into situations where you can not reliably determine what has been compromised and what hasn’t been.
Password expiration gives you a frame of reference for when the compromise could and could not have happened.
The problem with this reasoning is that it ignores the initial attack vector; how did the attacker compromise that password in the first place? It doesn’t just magically fall out of the sky once and then never reappear again.
Very often you’ll find that the password was obtained by compromising a victim’s computer, breaking into an auxiliary system that shares the same passwords, and so on. In these cases it is absolutely useless to change the password, because the attacker could just as easily obtain the new password and continue their business.
There’s a small set of cases where a time window might limit exposure, such as reused passwords in password dumps; but 1) these cases are better mitigated by preventing low-entropy passwords, 2) you’re still vulnerable for 3 months or whatever your window is, which is more than enough time to siphon out all information from most networks, 3) you’d be much better protected by just having proper monitoring of user sessions in the first place.
Is there theoretically a nonzero benefit to password expiry? Yes, but only if your security is already otherwise lacking, and even then it’s not a common case, and at that point it’s absolutely not worth it considering the big downside of forced password expiry: it incentivizes people to pick worse passwords, because remembering complex passwords is a big time investment that’s no longer worth it.
This would indeed work if you can use a password manager at that point. If it is at the login prompt, you usually can’t use a password manager. If web service X has a policy to change password every Y months, it wouldn’t be much trouble, I just use my password manager. I do that occasionally (manually) anyway for social accounts.
Also, as the article suggest, for the particular threat you mention, you’d better use 2FA to mitigate that.
Just got an email internally telling us the password expiration window has been reduced from 180 days to 90 days. There’s no use sending this article to the powers that be internally, somewhere there’s a checkbox in a security window dressing form that requires 90 days expiration and that’s what it’s going to be.
It’s doubly awful when you have a couple of disjoint authentication domains, say an AD arena and a UNIX one, and they have inconsistent expiration periods, length & complexity requirements, and reuse policies.
Best of all are the systems where you can’t change your password until it expires, thus making it impossible to keep in sync with other domains.
I wonder how many of these “best practices” are simply word-of-mouth beliefs handed down from management to management with little control over exactly how well they’re sourced.
Oh well next password change here will be a passphrase. I’ve been relying on a little C program that generates nicely pronounceable passwords but it’s time to uppgrayed I think.
You just caused some repressed memories to come back. Glad I’m out of enterprise now.
There are usually numbers and special characters required where passwords expire. Then it ends with this required number being incremented with wraparound near N. Where N is remembered passwords count to prevent reuse. Also I heard about changing passwords N times few days before expiration, so you can use then the same password.