Re: Password expiration Process ?

[Gary Flynn <flynngn () JMU EDU>]

> From: Theresa Semmens [mailto:theresa.semmens () NDSU EDU]
>
> We are about to enable the Password Expiration process on our student
> administration self-service portal.  Grades, course registration and
> financial aid are among the functions that the student can access.  As soon
> as we 'flip the switch', all passwords expire, and the fun begins.
>
> My question is two-fold.  First, are any of you using a password
> expiration process in a student self-service environment?   We have gone
> for some time without this, so the password problems we have are the normal
> 'I forgot' situations.
>
> Second, were there any repercussions after password expiration had been
> enabled?  Was it accepted as a standard business practice, or viewed as just
> another obstacle in the path of the student, faculty and staff?

Theresa,

Our home grown LDAP based identity management/authentication
system is used for self-service as well as a multitude of
other applications. People manage their "JMU eID" password
through a web application. The system has always provided
for password expiration so we didn't face the situation
of having to turn it on.

There is a "secret question" function tied to it that will
reset the password to a default known ( hopefully ) only to
the account holder. This decreases the number of helpdesk
calls but I don't know the figures. I do know that password
related calls are the number one or number two source of
helpdesk calls making up about 20% of the total. If the
person does not have a secret question set up, they must
physically visit the helpdesk and present picture ID to
have the password reset to the known pattern.

For the past several years, we used a 190 day password
expiration time but switched last semester to a 90 day cycle.
I believe this was due to state recommendations. We send
email notifications as the expiration time approaches.

During the password change process, people go through a web
based security awareness presentation. Both the password
change process and the security awareness material injected
into it has drawn its share of ire but some folks have also
had a positive reaction. In any case, we have not yet had
a mutiny.

We are researching alternative and supplemental
authentication systems for various populations.

----------------------------------------------------------
<ambivalent musings>

I started writing this to defend password expiration policies.
By the time I finished, I think I talked myself out of it and
into believing we need something much more effective. It wasn't
a complete waste of my employer's time as it gave me a chance
to think more about two-factor authentication which is a
project that I need to start on soon anyway. :)

The primary purposes of periodic password changes are:

1) To reduce the time available to an attacker for a password
   guessing attack
2) To regain control of an account when a password has already
   been compromised
3) To limit damage when a password has been compromised
4) To deactivate an unused account. There are much better ways
   of doing this directly than by using password expiration
   so this purpose won't be mentioned again.

Lets look at each of the first three in turn.

********************************************************************
1) To reduce the time available to an attacker for a password
   guessing attack.
*********************************************************************
How do they guess?

a) Continually access the system trying different passwords. This
   should be adequately mitigated by inserting delays between
   unsuccessful login attempts. Additional mitigation can be provided
   by log monitoring and, at the risk of a denial of service, account
   lockouts.

b) Gain access to a password hash or encrypted password.

   1) Directly sniff the wire. Client configuration can partially
      mitigate this as can network design and application choices.

   2) Man in the middle. Client configuration and user practices
      can partially mitigate this. Client and server certificates
      can partially mitigate this. MAC address assignments to
      switches and ARP monitoring can partially mitigate this.

   3) From a client that freely provides a hash if the ( possibly
      malicious ) server asks. Client configuration can partially
      mitigate this.

   4) Compromise a client that stores encrypted authenticators
      locally. There is probably no need to guess here. The clear
      text authenticators are probably typed where a keylogger
      can grab them or they can be used directly in a replay
      attack.

   5) Compromise a host system where the hashes or encrypted
      passwords are stored. This has profound implications that
      go beyond password expiration.

In all cases, risk can be partially mitigated by using strong
passwords but they have to be *really* strong these days to be
effective. Processor speeds, distributed computing, and
precalculated dictionaries and tables make most of the passwords
in use today inadequate and crackable in a relatively short
amount of time and the situation is only getting worse.

Unless *much* more stringent password composition policies are
*enforced*, password expiration policies would have to be
ridiculously short - on the order of a few days - to be effective
at mitigating guessing attacks. The question then becomes how
effective such policies are at regaining control of an account
or limiting damage once a password is compromised.
*********************************************************************
*********************************************************************



*********************************************************************
2) To regain control of an account when a password has already been
   compromised
*********************************************************************
How effective are password expiration policies at this? How
helpful? That depends upon two things.

1) Was the password compromised in a way that will lead to the new
   password being compromised? If the desktop is compromised with a
   keylogger, the new password will also be compromised. If the
   password is synchronized with one used on a compromised host,
   the new password will be compromised.

2) Was the password compromised and the account or system
   subsequently backdoored eliminating the need for the new
   password?

In some cases, changing the password will lock out the intruder.
The question then becomes, will it be too late?
**********************************************************************
**********************************************************************



*********************************************************************
3) To limit damage when a password has been compromised
*********************************************************************
How effective are password expiration policies at this? How helpful?

That depends entirely on the motivation and capabilities of the
person compromising the account. Do they want to delay use of the
account past the password expiration date? Do they want to use it
now? Are they ready to use it now or do they need to do some
research and setup? Is it a one-time thing or do they want
perpetual use? Will they share or sell it to others? The same
questions then apply to the new owners.

How long are we willing to allow an account to remain compromised?

Is there a big database out there of compromised accounts
sold and traded like credit card numbers and saved for future
purposes?

**********************************************************************
**********************************************************************

How effective are password expiration policies at mitigating
password guessing attacks. Today, probably not much.

How effective are password expiration policies at regaining
control of an account or limiting damage? I don't know the answer
to that nor do I know of any studies. I've seen stories of systems
being compromised and used for long amounts of time but not
individual accounts. Anyone have any information?

What I do know is that we, to this date, have had no known
security incidents that would have been prevented by a
password expiration policy beyond a few days. Anyone else
care to volunteer similar information?

One has to ask whether the resources applied to dealing with
password expiration would better be applied to other mitigation
methods.

On the other hand, one also has to ask whether those resources
are insignificant or would be sufficient. Would other,
admittedly more effective, methods cause as much or more
support headaches and dissent as the password expirations and
consume more resources? Will an organization be willing to
assume the higher costs of a more effective solution? Setting
a password expiration policy may be the most painless
solution ( that isn't really much of a solution ) but gets
a check box signed off that was designed for the threat
environment of twenty years ago.

Today's threat environment is much different with ubiquitous
network computing, the Internet, accessible services,
intertwined business processes, universal, multiuse accounts,
and the growing sophistication of today's criminal.

Very few laymen can effectively maintain and operate a desktop
computer in a secure manner these days and the statistics on
infections and BOT networks demonstrate that by the resulting
large number of compromised computers...and probably the
accounts accessed from those computers. Then you have to add
the folks that synchronize their organizational passwords
with eBay and AOL and type them into web forms, phishing
sites, open labs, and wireless hot spots.

Accounts will be compromised.

Even if the account holder doesn't care whether their account
information is compromised or that someone can drop a course
or perform other actions in their name, the organization must
protect itself on four fronts:

1) Constituents must be directly protected from compromised
   accounts that have access to third party information.

2) Constituents and the organization's infrastructure must
   be protected from the significant increase in risk posed
   by an attack against a system using a valid account versus
   an attack against a system by someone without a valid
   account.

3) Other organizations may be affected by a compromised account.
   Say, for example, an email, business process, or unix shell
   account. And if federated identity systems like Shibboleth
   are to have any value, then there must be some expectation
   about the integrity of local, organizational accounts.

4) Then there are passwords ( i.e. PINS ) protecting smartcards
   and hardware tokens. Likely as not, these devices are used
   to help protect particularly sensitive accounts. But if
   the password is compromised, because it is stored on a
   desktop, synchronized with others, or other ways, the token
   may as well be a credit card. And where does that leave
   PKI and digital signatures?

With many applications accessible world-wide, there is little
room for error.

The solution lies in:

1) Much, much, much better monitoring and response systems that
   can detect account use fraud in much the same way as banks
   detect credit card use fraud. Of course, this will lead to
   occasional account inaccessibility due to a false positive
   from something like someone studying abroad, remoting in
   multiple times through a sequence of computers, or
   misbehaved applications.

2) Authenticators that are stronger than memorized, multi use
   passwords. Typically, though not necessarily, 'something you
   have' whose use is typically authorized by typing a password.

   Replacing the authorization password with *token stored*
   biometrics may be the best solution assuming we're willing
   to accept the risk of a false positive on a stolen 'something
   you have' as well as the support headaches associated with
   an occasional biometric false negative. Passwords don't have
   to be typed into the suspect desktop and the biometric data
   does not get stored in a central database where privacy
   and mass biocompromise are issues nor stored on the desktop
   or transferred over the wire which presents similar issues.

   I think a OTP type token (i.e. SecureID) is probably more
   secure than a token that holds PKI information but the
   latter will probably be much more useful in the future. I
   think there are some that do both though not with biometric
   authorization yet.

   Of course, there is going to be a password associated with
   the fingerprint enrollment process that will have to be
   typed into the desktop, remembered, and protected. Can we
   ever get rid of them?

   Are we going to have password expiration policies on token
   PINS and biometric enrollment passwords? :) Should banks
   have PIN expiration policies on their ATM cards?

3) ( cough, ahem ) Secure desktops

Am I ready to say password expiration policies are totally
ineffective and should not be used? No. Particularly for high
value accounts that may be targeted where any little edge
is necessary and where the value is such that support headaches
are dwarfed by potential losses. On the other hand, I *am*
ready to say that password expiration policies are close to
being totally ineffective and should be replaced with other
mitigation methods ASAP. We're only fooling ourselves by
using them.

Whether real protection for the integrity and ownership of
our computer accounts will make palatable the extra support
requirements, costs, complaints, and procedures associated
with those measures only the future can tell. Typical
of security, eh? :)


</ambivalent musings>


--
Gary Flynn
Security Engineer
James Madison University
www.jmu.edu/computing/security

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature