Risk Assessed Password Policies – Password Rotation

Sep 25th, 2007

Comments: 0
Category: Uncategorized

Risk Assessed Password Policies – Password Rotation

I’ve been meaning to blog about some of the reading I’ve been doing recently on password policies, but an article in the latest Insecure Magazine tipped me over the edge into writing..
In the article on password management on page 59 the author mentions some elements of a “best practices” password policy which include password rotation every 30 days as a good thing.
I’ve seen this repeated in many places but I’m not sure where it came from. My opinion is that, in many cases, 30 day password rotation is actually a very bad thing, both from a user experience point of view and also from a security point of view. It’s one of those things that gets put in password policies without any real thought of the consequences.
The reasons I’ve seen stated for rotating passwords are

  1. Mitigate password sharing. This doesn’t really hold any water, if a user shares their password then they can just share the next one. A much better control is to educate the users never to share their password no matter who asks. This also has the side effect of helping mitigate some social engineering attacks
  2. Reducing the window that someone has to crack a password hash. There may be some circumstances where this may help out but really who’s to say that it’ll be a specific number of days for a password crack. From my experience of auditing windows passwords, you either get it real quick with a hybrid dictionary attack or rainbow tables(in which case the rotation doesn’t really help, or you don’t get it at all (if you’ve set password length over about 9 characters most attackers won’t be able to brute force a password with a decently designed algorithm.
    A better mitigation for this risk would be to ensure that password hashes are protected in transit (eg with SSL) and on hosts.

Also password rotation has several possible side-effects which actively reduce security

  1. Sequence passwords. Most users when faced with a password rotation will choose a sequence password eg ([password1], [password2], etc), so once an attacker knows one password for the user, they’ll pretty easily guess the next one.
  2. Helpdesk password reset fatigue. Password rotation (along with some other aspects of password policies I’ll come onto later) causes a large number of calls to a help desk. From a security standpoint, we want a password reset request to be an alert that someone is trying to attack one of our systems, but if the people being made aware of that alert (the helpdesk) are swarmed with “false positives” in the form of users forgetting their passwords, inevitably real alerts will be lost in the morass. In order to make password resets an effective control, we should be trying to minimize the number of times that the process is invoked (while maintaining the security of the password system obviously)

There are other elements of “classical” password policies that are just about as annoying, but I’ll leave them for next time.

Add a comment

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