Re: Password Complexity and Aging

[Dexter Caldwell <Dexter.Caldwell () FURMAN EDU>]

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.