Firewall Wizards mailing list archives
Re: password aging
From: "Joseph S. D. Yao" <jsdy () cospo osis gov>
Date: 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 jsdy () cospo osis gov - Joseph S. D. Yao COSPO Computer Support EMT-A/B ----------------------------------------------------------------------- This message is not an official statement of COSPO policies.
Current thread:
- Re: password aging Paul McNabb (Sep 01)
- Re: password aging Stephen P. Gibbons (Sep 01)
- <Possible follow-ups>
- RE: password aging Rick Smith (Sep 01)
- Re: password aging Joseph S. D. Yao (Sep 01)
- Re: password aging Stephen P. Gibbons (Sep 01)
- Re: password aging Joseph S. D. Yao (Sep 01)
- Re: password aging Stephen P. Gibbons (Sep 01)
- Re[2]: password aging Steve . Bleazard (Sep 02)
- Re: Re[2]: password aging Alec Muffett - SunLabs (Sep 02)
- Re: Re[2]: password aging Aleph One (Sep 02)
- Re: Re[2]: password aging Ryan Russell (Sep 03)
- Re: Re[2]: password aging Michael Shields (Sep 06)
- Re: password aging Paul McNabb (Sep 03)
- Re: password aging Stephen P. Gibbons (Sep 06)