Re: Current Best Practice regarding Password Change policy

[John Ladwig <John.Ladwig () CSU MNSCU EDU>]

Not to gainsay, but thinking longer-term and wider, man-in-the-browser is widely reported to have obsoleted several 
flavors of 2-factor AuthN (through form-appending, response-editing, amongst other tricks), though admittedly for 
high-value targets, which our systems probably don't qualify as.  At least yet.

But the malware construction toolkits are pretty impressive, so the friction involved in adding a new site is getting 
lower and lower every day.

I think you allude to one of the more  promising controls; account activity monitoring.  I'm just not sure how 
cost-effective that is to develop on an institution-by-institution (or, worse, system-by-system) basis.  The card 
system has a *very* effective implementation, but not (yet) do we see a very effective one in retail banking.  And 
those sectors are, far more than we, very nearly *made* of money.

Finding the drones rented out to a spambot-herder is a lot easier than finding the Zeus-like drones you have looking 
for financial-accounts or other high-value information resources.  Those are gonna be *way* stealthy, on average, to be 
effective.  And they're almost certainly not going to be the same drones with both sets of payloads, except by 
accident.  Or maybe the drones that have paid off in mid- to high-value operational modes get resold to the spam guys.  
That's a scary thought.

   -jml

> > > Joel Rosenblatt <joel () COLUMBIA EDU> 2010-09-24 15:22 >>>
I have to say that your argument falls apart if you start looking at the mechanisms that the passwords are being 
compromised by:

1) keyloggers
2) phishing

Neither of these are really mitigated by changing the password every 90 days, or for that matter, changing it at all.

Password changing is on a check list that the auditors have .. and that's why your changing it - if you can convince 
them that it doesn't really help, they you 
don't have to change it unless it gets compromised.

We monitor all authenticated logins on all servers and look for compromised accounts - they come from phishing or from 
logging in from a questionable system. 
Most compromised accounts are used to send spam or to steal library resources - both are detected by automated 
processes we have in place. We have seen that 
stolen accounts are typically used within hours or even minutes of the compromise.

For my money, I believe that the only way to semi-solve this problem is to implement a two factor authentication system 
- which we have done for most central 
system administrators. I would like to do this for everyone - it's only a simple matter of money.

My 2 cents

Joel Rosenblatt

Joel Rosenblatt, Manager Network & Computer Security
Columbia Information Security Office (CISO)
Columbia University, 612 W 115th Street, NY, NY 10025 / 212 854 3033
http://www.columbia.edu/~joel 




--On Friday, September 24, 2010 3:31 PM -0400 Dexter Caldwell <Dexter.Caldwell () FURMAN EDU> wrote:

> 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
> <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 <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] On Behalf Of Valdis Kletnieks
> > Sent: Friday, September 24, 2010 7:53 AM
> > To: 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/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?)



Joel Rosenblatt, Manager Network & Computer Security
Columbia Information Security Office (CISO)
Columbia University, 612 W 115th Street, NY, NY 10025 / 212 854 3033
http://www.columbia.edu/~joel