Re: Password Complexity and Aging

[Doug Markiewicz <dmarkiew+educause () ANDREW CMU EDU>]

> We actually didn't have to fight our auditors on expiration at all.  I
> suspect this is because we were more prepared than our auditor.  ;)  As
> part of our policy, we included the math to determine the keyspace,
> along with how long it would take an attacker to brute force the
> keyspace (lower limit known, as we enforce account lockout after N
> attempts).  This was acceptably long given our number of accounts, and
> provided no reason for us to enforce a short expiration period.

This assumes brute force attacks are the only reason to implement password expiration.  Another argument for password 
expiration is the notion that, over time, passwords get revealed unknowingly and periodic changing helps to mitigate 
the misuse of those passwords.  For example, a user might accidentally type their password into the username field 
which could have the side effect of logging that password.  Granted changing your password 30 days from that point 
won't stop misuse immediately, but its perhaps a reasonable control?  Maybe not.  It's an argument we tossed around 
though.

For the most part, we expire passwords to satisfy regulatory obligations not to improve security (with the assumption 
that ISO 27002 is a model for evaluating vague regulatory requirements).  Maybe we get better security along the way, 
maybe not.  As others have said, the important thing is to understanding why you're doing it.  I'm happy with where we 
ended up changing passwords for enterprise apps only.  I'll be happier when we implement two-factor auth.