Why changing passwords should be done regularly
A little birdie sent me a copy of today’s SANS ISC diary entry. That’s a good thing, because I’m at home sick with alleged piggy flu, and I’m not able to keep up with a whole lot.
The diary entry argues that regular changes of passwords are often done for no other reason than “because we’ve always done it that way”.
Apparently, people responsible for security policy have “read somewhere” that you’re supposed to change passwords every ninety days, and having no other basis on which to proceed, that’s the policy carved in stone.
When asked why this policy is the way it is, the usual response is “good security practice” – and in such environments it’s difficult to give a good response to someone who pushes back, arguing that changing passwords in their application is ‘difficult’ or, more often, ‘expensive’. This is, after all, business, and if one side pleads “expense”, while the other side pleads “good thing to do”, the latter side will lose.
So, why is it best practice?
One reason is that you have to recognise that for all that we tell users not to share their passwords, not to use the same password on multiple sites (aka “share their passwords”), etc, very often users will do exactly that. So, every ninety days, you change your password and you cut off everyone with whom you previously shared your password (to an extent).
Another reason is to allow changes in password policy to propagate out to new passwords. If you suddenly realise that passwords can be easily hacked if they are only six characters, you change the password policy to require punctuation as well, and then you realise that because no one has to change their password, the new policy will never be applied.
Those are the common arguments for regular password changes, and there are a few others, but there’s one I rarely hear being made.
What about when you do get an exposure?
In my professional career, I have seen, or heard of, a number of cases of exposure of password information. Sometimes it’s as simple as a departing employee who knows far too much information and may not be trusted, or as mind-boggling as a team sharing a list of important passwords, and one of the team members losing the list. Other times it’s more complex.
Each time, the response from security is the same – if the existing passwords are in danger of being used because of such exposure, then those passwords need to be changed.
Most times, the response from the business is the same – that the passwords haven’t been changed in so long, and they’re spread through so many different applications, that they have no idea what will be affected if they change the password.
Once you hit that scenario, it can be months before you get the password changed. Yes, months. And all during that time, the account may be compromised.
How do you prevent this?
Think of your disaster recovery drills – when there’s a process that needs to be followed quickly and correctly in an emergency situation, you achieve that by meticulous planning and regular exercise. You create the process and test it regularly, updating the process as you find there’s a need.
If you don’t change passwords on these high-value accounts once every 90 days (or so), how do you know that you’ll be able to change those passwords after an exposure or compromise? How will you guarantee that your password change procedures are current, without testing them? How will you enforce changes being documented if you don’t check the documentation against reality once in a while?