Re: password aging

["Stephen P. Gibbons" <steve () aztech net>]

Respectfully, I don't think you've read a word that I've written.
(and this discussion probably doesn't belong here.)

Paul McNabb wrote:

> But this doesn't work either.  You have to assume that your users
> have an idea of what a "well formed password" is.  If they don't,
> I suspect you'll have a lot of unhappy users who struggle with
> finding an acceptable password.  Certainly an attacker will know
> or can find out what is well formed.  If a password is rejected
> it will be fairly easy to determine why.

The password policy is clearly outlined, and presented to the userif a new
password fails the policy.  Guidelines and techniques for
choosing "strong passwords" are presented at that time as well.

It would be extremely difficult for an attacker to distinguish
between a password that was rejected due to a global history check
vs. one that was rejected due to a particularly paranoid set of pattern
checks and dictionary checks, especially when soundex is figured into
the equation.  In any event, the password wouldn't gain the attacker
anything since (by definition) it's on the list of historical, not-to-be-used
passwords and won't gain access to an active account.  As I mentioned
previously, the password history should be stored in an irreversible
format (hashed) and not exposed to read access.  In my particular case,
it would be protected from access by end users by several other layers
and housed on a secure machine (think KDC).  Similar restrictions would
be placed on access to the dictionary(ies).

> But the whole idea of a system-wide password history is useless
> at best and dangerous in practice.  You gain *absolutely nothing*
> with system-wide histories.  Each person's password history had
> better be completely independent of every other user's history,
> or else you have a much, much bigger problem.  If people are
> picking passwords from a bad (easily guessed) set, then all you
> should do is tighten up your definition for acceptable passwords
> to exclude the weak set of passwords.  System-wide password histories
> just tell everyone that someone is using those weak passwords.
> Since reusable passwords (and their attendant weaknesses) represent
> the biggest single threat to most systems, system-wide password
> histories make your weakest link even weaker.

I as much as admitted that passwords were the weakest link in theentire setup.
They are not the only authentication mechanism used
by the system that I was speaking of.

What's gained is on-the-fly adaptability of the system: Silly stuff that might
not make it into a dictionary "BH90210@900" works itself out of what's
allowed to be used as a password.

> Over the years most vendors were convinced to never store the actual
> passwords, only hashed passwords.  We then were successful in getting
> most vendors to completely hide the hashed passwords.  System-wide
> password histories are a giant leap back in time to give users info
> about what passwords are or have been used on the system by other
> users.

Implemented naively, I would agree.

> System wide password histories are one of those things that sound
> good at first, but the more you look at it the more problems you
> begin to see.  It's like the site that was doing an XOR to "encrypt"
> their data, and decided that to make it stronger they'd XOR the data
> twice with the key.  I suppose that doing "quadruple encryption" would
> seem very impressive and sound incredibly secure to management.  ;^)

So does double-DES.  ;-)  So does triple-DES EDE with three keys thatcan inter
operate with single-DES.

> Again, system-wide password histories are a security hole and
> should be avoided at all cost.  If you are ever doing a security
> audit of a site and find they are using a system wide password
> history, you had better flag it as a problem and recommend that
> they close that hole in their system.

I disagree.  You need to look at the entire system, and how thevarious pieces
interact.

I've faced several big time audits, and the general consensus is
that my code base is best characterized as "paranoid."

--
Steve

> >  From steve () aztech net  Fri Aug 28 09:49:49 1998
> >
> >  System-wide password histories shouldn't be used unless
> >  you are also doing dictionary/pattern checks.  Given those
> >  constraints, and the soundex + hashing that I mentioned in
> >  my previous message, it will be difficult for an end-user to
> >  determine exactly why their new password choice was
> >  rejected by the system. Your example of "sleepy7" could
> >  have been rejected at any stage of the "sanity checks".
> >  The specific reason for rejecting the new password should
> >  not be reported to the user, they only need to be told that
> >  the new password is probably weak.
> >
> >  Think of the global history as an adjunct to a dictionary check.
> >  The dictionary, in this case just happens to match your user-
> >  base's actual use very closeley, and it changes over time.
> >
> >  Paul McNabb wrote:
> >
> >  > >  From: "Stephen P. Gibbons" <steve () aztech net>
> >  > >
> >  > >  Storing the hashes system-wide so that user2 wouldn't be
> >  > >  allowed to use a password that had been previously used
> >  > >  by user1 or user3 is another option.  Use a strong hash, and
> >  > >  chmod 0600 the history file if you do this.  Yeah, an HMAC
> >  > >  would work better, but then you can't easily combine histories
> >  > >  and have to protect the key used.
> >  >
> >  > Having a "system wide" password history is an EXTREMELY bad thing
> >  > to do!  It is much worse than doing nothing at all!  The reason
> >  > for a password history mechanism in the first place is because you
> >  > want to break up (as much as possible) the password selection
> >  > mechanism so that passwords are more random (and harder to guess)
> >  > for a user.
> >  >
> >  > If your users are not telling each other their passwords, then any
> >  > passwords reused by other people are purely random anyway.  And if
> >  > a user ever gets a "hit" on a password, then he/she knows something
> >  > about the password selection habits of someone on the system.  For
> >  > example, if a user can't choose the password "sleepy7" because someone
> >  > else has used it, it may be a reasonable guess that someone is using
> >  > a "Snow White" theme in choosing passwords.
> >  >
> >  > System wide password history mechanisms remove randomness from the
> >  > password set being used, and they *secretly* pass information about
> >  > one user's passwords to another user.
> >  >
> >  > It should be obvious that if the password history includes the current
> >  > passwords, then if I get a "hit" when trying to select a new password,
> >  > I am fairly sure that some account on the system has the password I
> >  > just tried!
> >  >
> >  > The moral?  NEVER, NEVER, NEVER USE SYSTEM WIDE PASSWORD HISTORIES!!
>
> ---------------------------------------------------------
> Paul McNabb                     Argus Systems Group, Inc.
> Vice President and CTO          1809 Woodfield Drive
> mcnabb () argus-systems com        Savoy, IL 61874 USA
> TEL 217-355-6308
> FAX 217-355-1433                "Securing the Future"
> ---------------------------------------------------------