Re: Current Best Practice regarding Password Change policy

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

Tim,
I appreciate the reply and I do not see that we substantively disagree in
that I see your critiques to be completely accurate.  It's possible we are
a tad out of sync as to whether or not the analogy has any sufficient
basis for comparison.  I appreciate though this entire thread though in
that it helps me develop a better evaluation of our own needs.

I do have a few responses.

1) My statement was "If I had � 5 live-in guests in my house each of which
had their own different key to my home...."  (Again an intentional
scenario that is not 100% representative of real-world, but that is
intended to provide a basic framework of mental reference for the analogy)
2) My analogy was merely to cut to the chase about what password changes
do/can help accomplish. I considered a discussion on the differences
between the physical and the virtual but decided against it for brevity
and because I did not see that it significantly compromised the greater
point- which was simply that it's a useful tool when used properly (as
definted by each organization), but that discussions based on entropy
often seem to conclude with "no usefulness because it does not provide
sufficient pre-exposure defense" which may ignore other its other merits.

3)  I do think that one could argue that the difference you describe in
the virtual vs. physical nature of this analogy with respect to not
necessarily knowing when an exposure occurs with passwords is actually
more of a reason to consider the non-eternal password policy than a reason
to challenge it. 

I also very much agree that a highly important (perhaps the most
important) variable of interest in password change policy can be how much
turmoil it causes.  I did not intend to ignore this fact though I did not
dwell on it.  This is what I was referring to as part of  "effort", "cost"
 and "impact".  I was not so much focused on what the policy could or
should be as I was focused on whether or not having one can be of
significant value despite its relativity or lack thereof to entropy or to
brute force defense.

Dexter

The EDUCAUSE Security Constituent Group Listserv
<SECURITY () LISTSERV EDUCAUSE EDU> writes:
> First, I want to emphasize that I agree with a lot of what you say, but
> there are two points I would like to respond in counter to.
>
> You start with “I want a balanced security policy that protects my
> organization and does not itself become the greater threat” (well put).
> Interestingly, a charge levied by critics of periodic password changes is
> that it *does* weaken overall security. Your discussion never mentions
> this possibility as being evaluated, but instead appears to use the
> argument that “while it does not address a particular security concern,
> but it does address another.”
>
> That is well and good (and I think it is important to not get stuck on
> requiring complete solutions or endlessly debating the incremental
> gain/loss of particular methods), but the argument-by-analogy doesn’t
> work when the things being discussed are not analogous. You compare a
> password to a physical key used to access a house with live in guests.
> There are two critical differences: 1) the key is physical, passwords are
> not and 2) the key (encoding) is shared, (most) passwords are not/should
> not be.
>
> Physical: a key is a token. A user doesn’t care about the encoding it
> represents, they present the token and are granted access. One way to
> improve the security of a lock is to increase the number of “bits”
> used to open it. It makes the key a little longer, but it is still just a
> key. A user *does* care about a password – they have to remember it.
> The “encoding” becomes very significant and if you increase the
> security by extending the number of characters it (generically) becomes
> harder to remember. Another difference is that a key, being physical,
> becomes clear at some point that it is lost. A password is “lost”
> when the user forgets it, but it can be exposed/compromised/what have you
> without any clear way to tell that someone else has knowledge of it and
> can use it to gain unauthorized access.
>
> Shared: I’m not aware of people with shared living arrangements* who
> preventively have their lock re-keyed every month, six months, year or in
> fact on any periodic basis. Locks are typically changed when a person
> leaves or a key is lost (if then)**. Shared passwords are generally not a
> good idea, but they happen for a variety of reasons. When a person with
> knowledge of the shared password leaves the shared password should be
> changed. But in the typical case where the password is not shared the
> use-case of change-with-personnel is not relevant.
>
> I’m not meaning to argue for or against periodic password changes. For
> many institutions they are a fact due to external requirements so the
> question is moot for them anyway. But I think it is very risky to use an
> analogy, for illustration or argument, when the points of comparison are
> so dissimilar as physical objects and matters of knowledge are.
>
> * a security facility might very well have such a requirement, for
> example, to cover the case of a key being copied, but that does not
> follow the “live in guest” analogy presented, nor does it follow the
> typical case where passwords are not supposed to be shared.
>
> ** and if there were frequent thefts my experience is that instead of
> mandating periodic lock changes additional/different measures would be
> put in place, such as evicting guests/firing employees, installing
> cameras or silent, monitored alarms (particularly after losses with no
> break in).
>
> Tim Doty
>
> � 
>
> � 
>
>
>
> From: The EDUCAUSE Security Constituent Group Listserv
> [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Dexter Caldwell
> Sent: Friday, September 24, 2010 2:31 PM
> To: SECURITY () LISTSERV EDUCAUSE EDU
> Subject: Re: [SECURITY] Current Best Practice regarding Password Change
> policy
>
>
>
> � 
>
> I have to agree. � On this issue, I view password aging as simply a part
> of a set of tools for managing passwords. � Because of the changes in
> password threats over the years- one thing seems clear. � If we as an
> industry fail to � to use any of our very few defense methods, the
> attackers will soon figure it out and eventually it will become a point
> of weakness if for no other reason that it becomes an easier entry point
> as other methods are shored up against attack.
> � 
> With respect to auditors, we all need auditors to help drive security
> initiatives to some degree and add weight or perspective to our
> recommendations, however, I try to to keep in mind, I are not here to
> argue brute force statistical differences in password quality or the
> mathematical superiority of one adjustment or another. � I am here to
> provide a means of real world protection to the organization. � Any
> exposure potentially puts at risk everyone in an entire system and at
> worst everyone in the entire organization not to mention the enterprise
> (non-person related) business data that the system may hold. � � In that
> sense, once I'm within compliance (legal, auditor, or what have you)-
> then it doesn't matter what the auditors say. � What matters to me is how
> can I best protect the assets I'm focused on.
> � 
> My logic is really quite simple. � I want a balanced security policy that
> protects my organization and does not itself become the greater threat.
> � Imho, password changes help do that in one major way. � They reduce the
> time of exposure. � They do not or may not prevent the risk of exposure.
> � Nevertheless, there are other tools for that. � The other thing
> password changes provide is that they can be a tool that is one of your
> best and most basic security awareness initiative altogether in that they
> get people thinking about security and their access if only once a year,
> once every 6 months, once a month- whatever works for you. � When managed
> properly password changes I think increase your protection and help
> influence awareness.
> � 
> If I had � 5 live-in guests in my house each of which had their own
> different key to my home, and I knew that regardless of my preaching,
> that occasionsly someone would distribute an unauthorized key, or lose
> their key, � or that the house gets broken into with no signs of forced
> entry, then � I might feel that changing locks and distributing new keys
> occasionaly was not a bad thing. � It might not increase lock strength,
> but that's not the point. � The point is if I've been compromised and I
> know that my whole house was violated, it helps me have greater assurance
> that when my house was entered that 1 the exposed key no longer works and
> two, if they copied other keys lying around compromised other locks, I
> know that it won't be that way forever. � In other words, for my
> situation, they add a significant layer of protection to my home to be
> worth the some effort. � � But that effort itself is a configurable
> variable to some degree. � I might not change the locks every thirty days
> (high effort) unless I had a breakin or attempted breakin events
> happening with a frequency that warranted that change. � A good balance
> might be every 6 months (lower cost, lower impact, etc.) � If I had a
> thousand locks and a higher frequency of attack or exposure, I might see
> fit to put more effort into changing locks because of the greater cost
> and likelihood of the risk of exposure. � At least then I have a policy
> that 1) provides reasonable security without throwing away tools. � 2)
> Have a policy I can defend in the event we have have a serious costly
> security event and every know-it-all security pundit in the world begins
> to question every thing we do with phrases like 'gross negligence' and
> "Well everyone knows..." and "best practices indicate...30 days,but this
> organization had NO CHANGE POLICY WHATSOEVER?!" � � All this to say in my
> opinion we spend too much time debating things and trying to prove things
> that are not worth proving. � It's just common sense that at the very
> least password changes reduce an exposed password, therefore it seems to
> me to be a good tool for controlling that particular variable of security
> threats and that is what I use it for. � � Therefore it's irrelevant
> whether or how much it impacts entropy. � The real problem is that
> passwords are and outdated form of security in the first place, but there
> are not many fully developed alternatives that globally provide the same
> ease of use, ability to work with all of our applications (and users),
> � at similarly reasonable cost of management as usernames and passwords.
> � 
>
> The EDUCAUSE Security Constituent Group Listserv <[
> mailto:SECURITY () LISTSERV EDUCAUSE EDU ]SECURITY () LISTSERV EDUCAUSE EDU>
> writes:
> I agreed with this line of thinking in 199[78], before watching intruders
> hand-code password-recording trojaned versions of sshd and ssh on rooted
> UNIX systems during the course of an investigation. � The code did a nice
> job of host/client/account/password capture and loggin, which was *way*
> more efficient than the ad-hoc telnet/pop/ftp packet sniffers of the day.
> � 
> � 
> In the current environment of rampant keyloggers and man-in-the-browser
> crimeware, I'm completely over the line of thinking that the best way to
> get credentials is to attack a server's store of them. � I think the bad
> guys have pretty much moved on, as well.
> � 
> Grudgingly, I come to agreement with the Standard Audit Advice, though
> not for the reasons it was written in the first place.
> � 
> I see it as a hygienic measure; way to reap compromised credentials
> *eventually*, rather than letting them go on indefinitely, somewhat
> sooner rather than later for some classes of accountholders. � Given how
> easy it is to steal credentials client-side, you may actually force a
> change before it gets used (due to the size of the pile of booty), though
> I certainly wouldn't depend on that. � 
> � 
> I don't know whether that puts me on the white or black side of the
> issue. � :-)
> � 
> � � -jml
> � 
> > > > Roger Safian <[ mailto:r-safian () NORTHWESTERN EDU
> ]r-safian () NORTHWESTERN EDU> 2010-09-24 09:31 >>>
> I'd suggest that password aging should be based on the risk that somebody
> could obtain, and crack, the password hashes. � It's not a 
> black and white issue, regardless of what the Auditors, Spaf, or I say
> about
> it.
> � 
> -----Original Message-----
> From: The EDUCAUSE Security Constituent Group Listserv
> [[ mailto:SECURITY () LISTSERV EDUCAUSE EDU
> ]mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Valdis Kletnieks
> Sent: Friday, September 24, 2010 7:53 AM
> To: [ mailto:SECURITY () LISTSERV EDUCAUSE EDU
> ]SECURITY () LISTSERV EDUCAUSE EDU� 
> Subject: Re: [SECURITY] Current Best Practice regarding Password Change
> policy
> � 
> On Fri, 24 Sep 2010 08:28:02 EDT, Barbara Deschapelles said:
> � 
> > We currently require all, Students, Faculty and Staff, to change 
> > passwords every 90 days and we are enforcing unique passwords (no 
> > repeats). This is a relatively new requirement here and we are getting 
> > a lot of push back on the change. � I'd like to get a feel for what 
> > people accept as current best practice for password change intervals 
> > and other related policies, and also, if it is different than the best 
> > practice what people are actually doing (if you wish to share that :-)
> � 
> There's "what everybody is doing because auditors insist" and "what
> actually
> makes sense in today's computing environment". � Make sure to read what
> Gene
> Spafford wrote about it:
> � 
> [ http://www.cerias.purdue.edu/site/blog/post/password-change-myths/
> ]http://www.cerias.purdue.edu/site/blog/post/password-change-myths/ 
> [ http://www.cerias.purdue.edu/site/blog/post/passwords-and-myth/
> ]http://www.cerias.purdue.edu/site/blog/post/passwords-and-myth/� 
> � 
> (Anybody want to publicly admit they were able to sell the auditors on
> what
> Spaf said, and managed to eliminate mandatory changes?)