Re: Password Complexity and Aging

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

Fair enough question.  I'd respond by asking whose network only gets
attacked once every 90 days ?   Few probably change their locks that
frequently, but I think you've answered your own question.  My only
primary point is essentially buried in your idea of matching the frequency
of change to the risk level.  No one who's truly watching their networks
properly would suggest that attacks (even if you narrowed it down to brute
force attacks) on your systems in a reasonably sized network only happen
every 90 days.   And when attacks to happen they are often bunched
together and happen and much more than a single attempt.  

D/C
The EDUCAUSE Security Constituent Group Listserv
<SECURITY () LISTSERV EDUCAUSE EDU> writes:
> 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.