OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
NFR Wizards Archive: Re: password aging

Re: password aging

Stephen P. Gibbons (steveaztech.net)
Tue, 01 Sep 1998 01:51:30 -0700

Joseph,

Joseph S. D. Yao wrote:

> > 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.
>
> I have two problems with this.
>
> First, it is rather user-UNfriendly to NOT tell the user why the
> password is being rejected. If it's because of soundex, and the user
> doesn't realize it, they may continue entering similar patterns until
> they're sick of it. You'll get sick of the trouble calls, too.

This is true. It's also "standard" practice...One of the goals of my group
is to _reduce_ the number of calls
to the help-desk. Please keep in mind that this is only a _proposed_
change, and it hasn't been approvee yet.

> Of course, if you remove the "obscurity" layer, you also remove its
> "protection" of the system-wide password lookup.
>
> HOWEVER, this is still not a good idea. It reduces the space that a
> user has in which to find a good password, while NOT increasing the
> cracker's search space. In fact, it decreases it! The fact that user
> A has chosen "bLue.dRess" as a password (from the song) doesn't have
> anything to do with the face that user B has chosen "bLue.dRess" as HIS
> password (for some other reason). Both are reasonably good passwords.
> But there should be no a priori connection between those two choices.
> On the other hand, if you limit user B from choosing it, then the
> cracker knows that he doesn't have to bother checking any future
> passwords against it.
>
> [NOTE: use of the male password above should be considered as also
> encompassing the female, if anyone still worries about this.]
>
> Consider this analogy. I have a re-settable lock with three dials,
> each of which may have 0-9 as its setting. It takes me about 30
> seconds to align the dials and perform the funny little motion that I
> have to use to open it. I have to change its combination every few
> months, for various reasons. Now, let's say that I had 50 of these
> locks. I record the combinations that ALL use, and put them on a
> computer, so that I can make sure that I don't re-use ANY of the
> combinations on ANY of the locks. Let's see: after 4 years, of the
> 1000 combinations possible initially, I'm down to only 200 possible
> combinations! Did I mention that my DBMS could eliminate an already-
> used combination in 1 millisecond? So, in 1 second I eliminate the
> 800 used combinations, and then it takes me less than an hour and a
> half to get into any one of the locked rooms. And in three months, it
> will take me about an hour. And by the end of the year, there are no
> combinations I can use, and I'll have to leave the rooms unlocked. ;-)
>
> The argument doesn't scale perfectly. But, in combination with the
> argument that the cracker doesn't gain anything if a second user
> randomly happens to use an old password of the first user, it should
> suggest that a system-wide password history file is NOT in fact the
> greatest thing since sliced French toast. ;-)
>

Scalability is an issue. We're talking about (at least) a 128 bit
keyspace. 

--
Steve

> --
> Joe Yao                         jsdycospo.osis.gov - Joseph S. D. Yao
> COSPO Computer Support                                          EMT-A/B
> -----------------------------------------------------------------------
> This message is not an official statement of COSPO policies.

This archive was generated by hypermail 2.0b3 on Sat Jul 17 1999 - 07:11:46 CDT