Re: Password Expiration

[Alan Amesbury <amesbury () OITSEC UMN EDU>]

Resurrecting an older thread.....  First, to further highlight the
important and current relevance of reusable passwords, I'd like to point
out a couple recent incidents:

http://www.washingtonpost.com/wp-dyn/content/article/2006/07/13/AR2006071301551.html
http://isc.sans.org/diary.php?storyid=1482
http://isc.sans.org/diary.php?storyid=1479


RUMOR:  I've heard through informal channels that Debian administrators
have since cracked some of the passwords used on their systems, and
closed a number of accounts with weak passwords.  (Whether that's true
or not is immaterial.  I would expect the intruder(s) to do crack
passwords, and would expect Debian's admins to be smart enough to
recognize the possibility and act accordingly.)

With that in mind.....

Gene Spafford wrote:

[snip]
> 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).
[snip]
> 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.
[snip]

I respectfully disagree with your statement that periodic password
changes don't significantly reduce threat.  Sure, as a sole security
practice, it sucks.  However, in conjunction with other practices, I
think it *does* help.  (Unfortunately, I realize this sort of has the
makings of a religious argument, as I don't think there's hard,
uncontested proof either way.  Still, I think discussing it has merit.)

I think forcing password changes periodically is most useful when
combined with password strength checkers, and with periodic cracking
attempts by an authorized administrator.  I think these complement each
other nicely.  Weak passwords that somehow get past the strength checker
will hopefully get caught by one of the periodic audits, particularly if
the administrator is updating the attacks to reflect state-of-the-art
actually being used.  Those that don't get caught there will eventually
expire anyway, and be forced to be changed.  I agree that this won't
catch *all* the problems, but believe it catches enough low-hanging
fruit that it actually *does* improve your security stance.  In
practice, I've found that this allows me to ignore the more obvious
ankle-biter attacks and concentrate on other things, e.g., more
resourceful adversaries.

In addition to forced password changes, I'm also a fan of forced account
expiration.  An account with a password that never changes is a dormant
account as far as I'm concerned.  I lock (and eventually remove) dormant
accounts as part of routine maintenance.

Sure, these strategies won't keep a determined, resourceful adversary
out forever... but that's not a reasonable goal anyway.  My focus is to
use these tools and strategies to delay adversaries long enough to get
detected and eradicated through other means.  This, I believe, is a
reasonable approach to systems security, and one that I think works well
in the real world.  For me, periodic password changes seem to help.

On the other hand, there's definitely too much of a good thing.
Anecdotal evidence abounds regarding Post-It notes with passwords stuck
to monitors, under keyboards, etc.  I think the key is to tune your
policy to fit circumstances, yet I don't think there's an easy HOWTO
guide on doing so.  However, as long as we're stuck with reusable
passwords (and I think we're going to be, at least until someone can
point to a spreadsheet definitively showing cost savings by switching
away from them), we're better off not being stuck with the *same* ones
forever.

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

I, too, have had some long-lived passwords.  However, the systems on
which I've kept them have tended to be ones where the user base is very
small and well-controlled, or where the OS uses password hashing
algorithms of great expense (e.g., Blowfish).  However, even though
there's never been a security incident on the system(s) involved, I
still periodically change my password there.


--
Alan Amesbury
University of Minnesota