Re: Password Expiration

[Steve Worona <sworona () EDUCAUSE EDU>]

My thanks, too, Gene, for bringing some analysis and academic rigor to the discussion. I wonder if we can push it a 
little further.

Regardless of the origin of the idea (and thanks for that background, too), proponents of password changing can argue 
that the practice does limit the length of time during which a bad guy can do damage. Now, this may be pointless, since 
one access may be all it takes to empty out a bank account or do other catastrophic damage, but the argument is made 
nonetheless. So let's ask the question directly: Since it's inevitable that passwords will fall into the wrong hands, 
how can we minimize the duration of the exposure?

One approach is to give the user feedback on recent accesses, hoping that s/he'll notice any illegitimate activity. 
This also goes back to mainframe days, when many systems' login displays included the timestamp of the previous login. 
We can extend this idea in two dimensions: First, track not just time, but things like MAC and IP addresses, geographic 
location, session duration, etc. And, second, automate the process. That is, have the system look for and flag 
anomalous activity. This may sound familiar: It's a variation on what the credit card companies do to detect fraud.

So instead of "brain-dead password change policies" (and I'm amazed no one has yet referenced 
http://www.smat.us/sanity/mordac.jpg), which at best limit the bad guys to weeks or months of illegitimate account 
access, I wonder if there's any work being done to notice compromised passwords in this or some other way.

Steve
--
Steven L. Worona
Director of Policy and Networking Programs
EDUCAUSE / 1150 18th St. NW suite 1010 / Washington, DC 20036
202-872-4200 x 5358 / 202-872-4318 fax / sworona () educause edu

-----
At 7:10 AM -0400 4/11/06, Harold Winshel wrote:
> Gene,
>
> Wow - thanks for the very detailed explanation.   And I wasn't aware of a lot of the background information on where 
> the password-changing policy had come from
>
> I also tend to lean against forcing the regular password changes.  To me, unless you have a very controlled 
> environment, which universities typically are not, some users will behave in ways that undermine - sorry, I mean 
> actually make it worse - the situation.
>
> To me it seems an issue of knowing not only how the machines work but how the people work.
>
> Thanks again!
>
> Harold
>
>
> At 10:25 PM 4/10/2006, you wrote:
> > I have found this discussion quite interesting, especially as our
> > campus has recently adopted a brain-dead password change policy.
> >
> > From a high-level perspective, let me observe that one problem with
> > any widespread change policy is that it fails to take into account
> > the various threats and other defenses that may be in place.
> > Policies should always be based on a sound understanding of risks,
> > vulnerabilities, and defenses.   "Best practice" is intended as a
> > default policy for those who don't have the necessary data or
> > training to do a reasonable risk assessment.
> >
> > Consider the underlying role of passwords: authentication.  Good
> > authentication is intended to support access control, accountability
> > and (in some cases) accounting.  Passwords provide a cost-effective
> > and user-familiar form of authentication.  However, they have a
> > number of failure modes depending on where they are used and the
> > threats arrayed against them.  Failure modes include disclosure,
> > inference, exposure, loss, guessing, cracking, and snooping.   In the
> > most general case, passwords (such as the security numbers on credit
> > cards, or mother's maiden name) are not sufficiently secret and are
> > simply too weak to use as strong authenticators.   I'll skip this case.
> >
> > Disclosure is a systemic threat on the platforms involved, as well as
> > the operational methods used to generate and transmit the passwords.
> > This cannot be addressed through changing the password.  Instead, the
> > methods used to generate and distribute passwords needs to be
> > examined to ensure that the passwords are not disclosed to the wrong
> > parties.   Most operating systems are currently designed so that
> > passwords are not stored "in the clear" and this reduces the chance
> > of disclosure.  Unfortunately, some 3rd-party applications (including
> > web-based systems) fail to adequately guard the passwords as they are
> > entered, stored, or compared, resulting in potential disclosure.
> >
> > Another form of disclosure is when the holder of the password
> > discloses the password on purpose.  This is an education and
> > enforcement issue.  (Anecdote:  at one location where a new policy
> > was announced that passwords must be changed every month, a senior
> > administrator was heard to moan "Do you know how much time I'm going
> > to waste each month ensuring that everyone on my staff knows my new
> > password?")
> >
> > Inference occurs when there is a pattern to the way the passwords are
> > generated/chosen and thus can be inferred.  For instance, knowing
> > that someone uses the same password with a different last character
> > for each machine allows passwords to be inferred, especially if
> > coupled with disclosure of one.
> >
> > Exposure is the case where accident or unintended behavior results in
> > a sporadic release of a password.  As an example, think of someone
> > accidentally typing her password as the user name in login, and it is
> > captured in the audit trail.  Or someone accidentally types his
> > password during a demonstration and it is exposed on a projection
> > screen.
> >
> > Loss is when someone forgets his or her password, or (otherwise)
> > loses whatever is used to remind/recreate the password.
> >
> > Guessing is self-explanatory.  Guessing is limited to choices that
> > can be guessed.  After a certain limited number of choices, the
> > guessing can only transform into a cracking attempt.
> >
> > Cracking is when an intermediate form of the password (e.g., an
> > encrypted form stored in the authentication database) is captured and
> > attacked algorithmically, or where iterated attempts are made to
> > generate the password algorithmically.  The efficacy of this approach
> > is determined by the strength of the obfuscation used (e.g.,
> > encryption), the checks on bad attempts, and the power and scope of
> > the resources brought to bear (e.g., parallel computing, multi- lingual databases).
> >
> > Snooping (eavesdropping) is when someone intercepts a communication
> > employing the password, either in cleartext or in some intermediate
> > form.  The password is then extracted.  Network sniffing and
> > keyloggers are both forms of snooping.   Various technical measures,
> > such as network encryption, can help reduce the threat.
> >
> >
> > Now, looking back over those, periodic password changing really only
> > reduces the threats posed by guessing, and by weak cracking
> > attempts.  If any of the other attack methods succeed, the password
> > needs to be changed immediately to be protected -- a periodic change
> > is likely to be too late to effectively protect the target system.
> > Furthermore, the other attacks are not really blunted by periodic
> > password changes.   Guessing can be countered by enforcing good
> > password selection, but this then increases the likelihood of loss by
> > users forgetting the passwords.    The only remaining threat is that
> > periodic changes can negate cracking attempts, on average.  However,
> > that assumes that the passwords choices are appropriately random, the
> > algorithms used to obfuscate them (e.g., encryption) are
> > appropriately strong, and that the attackers do not have adequate
> > computing/algorithmic resources to break the passwords during the
> > period of use.   This is NOT a sound assumption given the
> > availability of large-scale bot nets, vector computers, grid
> > computing, and so on -- at least over any reasonable period of time.
> >
> > In summary, forcing periodic password changes given today's resources
> > does not significantly reduce the overall threat -- unless the
> > password is immediately changed after each use.   This is precisely
> > the nature of one-time passwords or tokens.
> >
> > So where did the "change passwords once a month" dictum come from?
> > Back in the days when people were using mainframes without
> > networking, the biggest uncontrolled concern was cracking.
> > Resources, however, were limited.  As best as I can find, some DoD
> > contractors did some back-of-the-envelope calculation about how long
> > it would take to run through all the possible passwords using their
> > mainframe, and the result was several months.  So, they (somewhat
> > reasonably) set a password change period of 1 month as a reasonable
> > means to defeat systematic cracking attempts.  This was then
> > enshrined in policy, which got published, and largely accepted by
> > others over the years.   As time went on, auditors began to look for
> > this and ended up building it into their "best practice" that they
> > expected.  It also got written into several lists of security
> > recommendations.
> >
> > This is DESPITE the fact that any reasonable analysis shows that a
> > monthly password change has little or no end impact on improving
> > security!     It is a "best practice" based on experience 30 years
> > ago with non-networked mainframes in a DoD environment -- hardly a
> > match for today's systems, especially in academia!
> >
> > The best approach is to determine where the threats are, and choose
> > defenses accordingly.   Most important is to realize that all systems
> > are not the same!   Some systems with very sensitive data should
> > probably be protected with two-factor authentication: tokens and/or
> > biometrics.   Other systems/accounts, with low value, can still be
> > protected by plain passwords with a flexible period for change.   Of
> > course, that assumes that the OS is strong enough to protect against
> > overall compromise once a low-privilege account is compromised....not
> > always a good bet in today's operating environment!
> >
> > And, btw, I've got some accounts where I've used the same password
> > for several years with nary an incident.   But in the spirit of good
> > practice, that's all I'm going to say about the passwords, the
> > accounts, or how I know they are still safe. :-)
>
> Harold Winshel
> Computing and Instructional Technologies
> Faculty of Arts & Sciences
> Rutgers University, Camden Campus
> 311 N. 5th Street, Room B36 Armitage Hall
> Camden NJ 08102
> (856) 225-6669 (O)