The reason password expiration policies exist, is to mitigate the problems that would occur if an attacker acquired the password hashes of your system and were to break them. These policies also help minimize some of the risk associated with losing older backups to an attacker.
For example, if an attacker were to break in and acquire your shadow password file, they could then start brute forcing the passwords without further accessing the system. Once they know your password, they can access the system and install whatever back doors they want unless you happen to have changed your password in the time between the attacker acquiring the shadow password file and when they are able to brute force the password hash. If the password hash algorithm is secure enough to hold off the attacker for 90 days, password expiration ensures that the attacker won’t gain anything of further value from the shadow password file, with the exception of the already obtained list of user accounts.
While competent admins are going to secure the actual shadow password file, organizations as a whole tend to be more lax about backups, particularly older backups. Ideally, of course, everyone would be just as careful with the tape that has the backup from 6 months ago as they are with the production data. In reality, though, some older tapes inevitably get misplaced, misfiled, and otherwise lost in large organizations. Password expiration policies limit the damage that is done if an older backup is lost for the same reason that it mitigates the compromise of the password hashes from the live system. If you lose a 6 month old backup, you are encrypting the sensitive information and all the passwords have expired since the backup was taken, you probably haven’t lost anything but the list of user accounts.
I have argued before that it doesn’t improve anything. From that post:
Obviously the attacker does not know
your password a priori, or the attack
wouldn’t be brute-force; so the guess
is independent of your password. You
don’t know what the attacker has,
hasn’t, or will next test—all you know
is that the attacker will exhaust all
possible guesses given enough time. So
your password is independent of the
Your password, and the attacker’s
guess at your password, are
independent. The probability that the
attacker’s next guess is correct is
the same even if you change your
password first. Password expiration
policies cannot possibly mitigate
So why do we enforce password
expiration policies? Actually, that’s
a very good question. Let’s say an
attacker does gain your password.
The window of opportunity to exploit
this condition depends on the time for
which the password is valid, right?
Wrong: as soon as the attacker gains
the password, he can install a back
door, create another account or take
other steps to ensure continued
access. Changing the password post
facto will defeat an attacker who
isn’t thinking straight, but
ultimately a more comprehensive
response should be initiated.
So password expiration policies annoy
our users, and don’t help anyone.
Before answering whether it does help or it does not help, it makes sense to look at specific scenarios. (That’s often a good idea when dealing with security measurements.)
In what situations does a forced-password-change mitigate impact?
The attacker knows the password of a user but has no backdoor. He does not want to be discovered, so he does not change the password himself.
Let’s see if this scenario is likely:
How might he have learned the password?
- The victim might have told him (e. g. a new intern who should start working before he gets his own account setup, another person who should level an account in an online game
- The attacker might have watched the keyboard
- The attacker might have had access to another password database in which the user used the same password
- A one time only login using a computer owned (prepared) by an attacker.
What might have prevented him from setting up a backdoor?
- The service in question may not provide a way for backdoors, for example an email inbox or common web applications
- The privileges of the user may not have sufficient permission to install a backdoor
- The attacker might miss the required knowledge (in the online game Stendhal most “hacks” are done by angry siblings who just want to destroy some toy)
- The attacker might not have turned evil yet. (e. g. an employee that will be fired next month but does not suspect anything at the moment).
Why not use forced password expire?
It can be very annoying to users causing them to just add a counter at the end. This might decrease the entropy of passwords. According to my experience it generates additional support costs because people forget their new password more often than usual. I guess that is caused by the change password prompt catching them off guard while they are busy thinking about something else.
It is far from a cure-all and it has a negative impact on usability, but it does make sense to balance that against the likelihood and impact of scenarios similar to the one I described above.