[Infowarrior] - Security Myths and Passwords

[Richard Forno]

 Security Myths and Passwords
April 19th, 2006 by spaf in General, Secure IT Practices
Prof. Eugene Spafford

http://www.cerias.purdue.edu/weblogs/spaf/general/post-30/

(This is an updated version of a contribution I made to the Educause
security mailing list last week.)

In the practice of security we have accumulated a number of ³rules of thumb²
that many people accept without careful consideration. Some of these get
included in policies, and thus may get propagated to environments they were
not meant to address. It is also the case that as technology changes, the
underlying (and unstated) assumptions underlying these bits of conventional
wisdom also change. The result is a stale policy that may no longer be
effectiveŠor possibly even dangerous.

Policies requiring regular password changes (e.g., monthly) are an example
of exactly this form of infosec folk wisdom.

>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, although it is far too pervasive to actually ignore.

Disclosure is a systemic threat on the platforms involved, as well as in 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. Another example is where generated passwords are employed
and the generation algorithm is predictable.

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. Another example is when someone accidentally types his password
during a demonstration and it is exposed on a projection screen to a class.

Loss is when someone forgets his or her password, or (otherwise) loses
whatever is used to remind/recreate the password. This introduces overhead
to recover the password, and may induce the user to keep extra
reminders/copies of the password around ‹ leading to greater exposure ‹ or
to use more memorable passwords ‹ leading to more effective guessing
attacks. It is also the case that frequent loss opens up opportunities for
eavesdropping and social engineering attacks on the reset system as it
becomes more frequently used: safeguards on reset may be relaxed because
they introduce too much delay on a system under load.

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 is
unlikely to 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, and these are clearly the better method to use for
authentication, although they do introduce additional cost and, in some
cases, increase the chance of certain forms of lost ³password.²

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

One of my favorite Dilbert cartoons (from 9/10/05) ends with the
pointy-haired boss saying ³Šand starting today, all passwords must contain
letters, numbers, doodles, sign language and squirrel noises.² Sound
familiar to anyone?