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

Joseph S. D. Yao (jsdycospo.osis.gov)
Mon, 31 Aug 1998 13:05:57 -0400 (EDT)

> 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.

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. ;-) 

--
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