Quite a few have implemented password aging as a security mechanism. With "password aging" I mean the practise of setting a maximum useful life on any given password (usually a time period of one month or three months, but specifics do vary).
In this sub-essay, I will explore the benefits and drawbacks of enforcing password changes in such a manner, from a security perspective.
There are several claimed benefits to password aging.
These are all and good seductive reasons to implement password aging. Let's explore these, in turn.
It is true that a password aging mechanism enforces this. It does so with a fairly coarse granularity and with the method most usually used, will allow anyone with the previous password to log on and change the password, anyway.
A better method to ensure that authentication is removed as people leave is to have procedures set down and having HR inform the people responsible for authentication systems and simply invalidating the account as the leaver is on his/her way out of the building.
It is frequently claimed that password aging is "industry best practise" and the nature of "best practice" is taht common acclaim makes it so.
For any company with a security qualification (say BS7799), following indistry best practice is a way of saying "we have done what we can, it is not our fault, we have procedures in place". From this angle, implementing password aging is fairly simple and does a whole lot of good.
This is, to an extent, true. Any password that has been captured at a point T and tried ata point T' has at least some chance of having been changed. It's not necessarily true, however.
Most password ageing mechanisms can set two tresholds, minimum password age and maximum password change. Usually, the maximum is set and the minimum is unset. Some (but not all) password systems also keep a history of previous passwords, usually limited to 3-5 previous passwords.
This means that a password captured at time T, with a password change before time T' (when it is tried) may well be the same at time T'. How?
let's look at Alice. Alice has a secure password (ASP), being the BASE-64 encoding of 48 bits of random data. Alice has memorised this password, so it is not written down. Alice also only use ASP for system S. The system S owner decides that password aging (maximum time 35 days, no minimum time) should be implemented and Alice needs to change her (secure) password every month. She finds that she will be unable to memorise random garbage at such a rate. System S keeps track of the last 5 passwords Alice has had.
When password-change time comes, Alice changes from ASP to the password "alpha123", she immediately changes to "beta234", then to "gamma345", then to "delta456", then to "epsilon567". After that, Alice changes password to ASP. The system is happy, since it can't recall Alice having had this password before. Alice is happy, because she has a secure password.
If we consider the case where there is a minimum password age (or, with similar outcome, someone who cannot be bothered to change through to have the same password again), we find1 that most people will pick one of two routes, either really simple passwords or a root password, with a time-dependent bit that changes (like, say, "Cockerel-2007-01" as password for January 2007 and "Cockerel-2008-03" as password for March 2008). Both of these results in a slightly less secure system.
The best possible outcome is that people choose sufficiently-hard passwords and remember them (or record them in a password safe). Almost as good, but less secure, is people choosing good passwords and writing them on a slip of paper, kept in a wallet (the method is sound, as long as there's more than one password on the paper and no account and system identification is on the paper).
On the balance, I think password aging gives a false sense of security, possibly to the point that careful account management is put aside in favour of blind, automatic mechanisms.
There are possible scenarios where password aging is, indeed, the right choice, but it should not be implemented without due consideration for the threat model and considering possible relaxation of the system security.
Back to the main essayAs luck has it, one study looking at the probability of cracking passwords under sme assumed password-change policies can be found here
Fred Cohen has another paper on the password-change issue.