Re: Password Complexity and Aging

["Basgen, Brian" <bbasgen () PIMA EDU>]

Dexter,

 The house analogy is interesting. Who changes their house locks every 90 days? Instead, locks are changed only in the 
case of an adverse event (break-in, lost keys, etc). The same security model for a password would mean no mandatory 
changes.

 Frequent change intervals imply passwords with relatively low entropy, while infrequent intervals may not sufficiently 
address the risk. The often cited risk seems to be around the idea of a compromised sleeper account. I'm very 
interested to know if people have data on this, how often it has occurred at your institution, etc.

~~~~~~~~~~~~~~~~~~
Brian Basgen
Information Security
Pima Community College
Office: 520-206-4873

From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Dexter 
Caldwell
Sent: Monday, April 13, 2009 11:01 AM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] Password Complexity and Aging

I have to second that.

Furthermore.  If your house is repeatedly burglarized, should you refuse to change your locks anymore just because the 
recent trend in house robberies has been to kick the door in?  How long would it be before the intrustion industry 
realized that if there's no need to make such a mess.  They just use the first key they made last time they kicked the 
door in.  That way you'd never know they were there in the first place until much later.  The big problem with the 
"other methods" is still that they tend to be badly coded or require so much stacked software (trojans, rootkits, then 
the actual exploit) that they are often detected for other reason than the point of the exploit.  Password changes can 
remediate the fact that someone got in and got your passwords through an exploit.    Finally the most important thing 
is that we all know common sense would tell us in the aforementioned example to change our passwords, but users often 
will remember (perhaps inaccurately) that "you told me" that password changes aren't that important.  This helps 
alleviate the culture of passivity so I agree that a good balance of frequency with realistic evaluation risk is best.

Dexter

The EDUCAUSE Security Constituent Group Listserv <SECURITY () LISTSERV EDUCAUSE EDU> writes:
I agree completely with Doug and Gary.

You don't want to have intruders having uninterrupted control of your
institutional user accounts for years and years (even if they aren't
malicious :-)

Not only are there valid security concerns and auditors to worry about,
there is far too much liability in terms of IT compliance regulation
today
to allow an account with single-sign-on access to financial, student
and other confidential data remain compromised -potentially forever.

Implementing regular password changes will also "flush" out cases
where people have been knowingly or unknowingly sharing passwords
(often against institutional policy) as they will seek a more stable
solution
to their "business problem" which requires shared access.

I'm also looking towards (and working on) two-factor authentication as
an even more secure solution for employees who need to work with
highly confidential data.

Morrow

On Apr 13, 2009, at 8:48 AM, Doug Markiewicz wrote:

> > 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.