Re: Password Complexity and Aging

[Gary Dobbins <dobbins () ND EDU>]

Some landlords do change locks after a tenant leaves, and can then assure the new tenant they (and the landlord) have 
the only copies of the key.  Otherwise, no one could be assured they hadn't kept a copy of the key for use in a future 
burglary.


> -----Original Message-----
> From: The EDUCAUSE Security Constituent Group Listserv
> [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Basgen, Brian
> Sent: Monday, April 13, 2009 2:21 PM
> To: SECURITY () LISTSERV EDUCAUSE EDU
> Subject: Re: [SECURITY] Password Complexity and Aging
>
> 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.