Annual password discussion was Re: 15 character minimum passwords

[Gary Flynn <flynngn () JMU EDU>]

Todd Gunter wrote:

> Has anyone adopted the use of 15 character minimum passwords?
>
> We are going to start using this password format when we migrate
> to Windows 2003.  I was wondering if anyone has started to use
> this format and what, if any, issues you had using them?
>
> We see this as a simpler approach to passwords.  Fifteen character
> password with complexity is simply 'Ihaveabigmouth.'.  They are
> also supposed to much harder to crack.
>
> Please let me know your experiences with this move and any bumps
> in the road to look out for.

We have not tried to enforce a 15 character password length and I'd
love to hear how your plans work out.

Since passwords always generate a lively discussion here, I'm going
to throw in my $0.02 worth.

One must take into consideration:

1) the size of the user population
2) the make-up of the user population
3) how many accounts are exposed by one compromise
4) the privileges their accounts hold
5) whether some type of single/same sign-on is in effect
6) the types of attacks you're trying to foil.

I don't know how a 15 character phrase would be accepted among
the general user community of a large population. We recommend
long, random passwords for elevated access accounts which rules
out simple english phrases. We recommend a mnemonic phrase to
ease memory requirements. But the 15 character password would
certainly seem to be a workable solution for a limited,
professional population.

I'd feel a little uncomfortable with all lower case alpha
characters, even with 15 characters. NIST estimates entropy
of a 15 character, all lower case user chosen password at
about 28 bits.
NIST Electronic Authentication Guideline (appendix A)
http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63v6_3_3.pdf

If the user only has to remember one password for thirty accounts,
then perhaps that would justify expecting them to devote the time
and effort to remember a better password. In that case, it may
sell itself.

If tens of thousands of password hashes can be exposed, as on an
e-mail or student registration system, there is justification
for protecting them better (possibly from each other?). However,
by nature of such a system, protecting them individually by using
long passwords impacts a large population.

Consider the ways a password may be compromised:

1) Found on paper, shoulder surf, given out (phone,phish,whatever),
   keyboard logger, sniffed clear text off network, found stored
   clear text on computer

   Doesn't matter too much what kind of reusable password
   it is.

2) Password guessing

   The primary defense against this should be an account lock,
   or at least a notification, once the number of unsuccessful
   login attempts reaches a specified number. It can probably
   be a fairly large number (say, 20) and still be effective
   and, at the same time, not be a nuisance to the fumble
   fingered.

   Of course, this has to be backed up with at least a minimum
   amount of password complexity *enforcement* so you don't
   have passwords like "password", "administrator", "root",
   [username], and [blank].

3) Man in the middle attacks allowing access to clear text

   SSH1, SSL, and VPNs that don't use unique client keys are all
   susceptible. SSH1 and SSL will give a warning. Again, if the
   passwords are clear text, length and complexity don't matter.

4) Hash sniffed off network, hash obtained from compromised
   host file, hash from man-in-the-middle compromised VPN that
   uses supplementary authentication.

   This, then, is where our discussion about long passwords makes
   the most sense. Note that the network or a system has to be
   compromised, or at least operated maliciously by an insider,
   for these to work. Making everyone have long passwords to
   protect against this higher complexity, presently lower
   probability attack (questionable assumption on my part) would
   be a hard sell. Certainly, though, it makes sense for sensitive
   accounts.

   There are a lot of variables in this scenario and places where
   infrastructure can add additional preventive and detection
   mechanisms without affecting the user:

   a) What preventative measures must be hurdled before the
      compromise can take place?
   b) When will the compromise be discovered?
   c) When will the accounts be forced to change their passwords
      after the compromise is discovered?
   d) How long will it take to crack the passwords?
   e) When will password expiration force a password change?
   f) Will ongoing monitoring notice the use of an account from
      an odd location, an odd time, or an odd frequency?
   g) Will network access controls permit access to the system
      holding the account from unauthorized systems?
   h) What impact does loss of a standard user account (as opposed
      to an administrator's account which is expected to be protected
      by a better than average password) have? Does it have shell
      access allowing unpatched defects to be exploited to gain
      privilege? Does it expose the hashes of other accounts?


The ideal security solution (as opposed to production/support/
financial solution) for authentication? An application that
requires:

1) A physical smart card/time-token/OTP device which requires a
   biometric signature to activate
2) A memorized PIN

Something you are, something you have, and something you
know all at once. For some accounts, its probably cost/support
justified. For others, probably not until the infrastructure
gets much more universal. Maybe the DMV will issue them, desktop
makers will all include readers (I don't believe in "software
tokens"), and systems/applications providers will all write
to them. :)

To answer someone else's question, we are informally looking into
token based products for use by folks who access elevated privilege
accounts or folks who access sensitive data from home computers.

Note also that there are free, software based OTP solutions
out there. We used OPIE along with fwtk many years ago without
problems other than training for folks who wanted higher than
normal access to central systems.

--
Gary Flynn
Security Engineer
James Madison University

**********
Participation and subscription information for this EDUCAUSE Discussion Group discussion list can be found at 
http://www.educause.edu/cg/.