Re: Password checking
"Fuat C. Baran" <fuat@cunixf.cc.columbia.edu> Wed, 04 April 1990 21:08 UTC
Received: from cunixf.cc.columbia.edu by cert.sei.cmu.edu (5.61/2.2) id AA22256; Wed, 4 Apr 90 17:08:36 -0400
Received: by cunixf.cc.columbia.edu (5.59/FCB) id AA04591; Wed, 4 Apr 90 17:08:17 EDT
Date: Wed, 04 Apr 1990 17:08:15 -0400
From: "Fuat C. Baran" <fuat@cunixf.cc.columbia.edu>
To: art@dinorah.wustl.edu
Cc: ssphwg@cert.sei.cmu.edu
Office: 712 Watson, (212) 854-5128
Subject: Re: Password checking
In-Reply-To: Your message of Wed, 4 Apr 90 15:13:42 CDT
Message-Id: <CMM.0.88.639263295.fuat@cunixf.cc.columbia.edu>
> To avoid this predicament, I have just implemented a password >checker running at low priority all the time to check our systems' >passwords. It generates around 1/2 million passwords from the >"obvious" choices (these choices are not suitable for discussion in >this public medium!!) and checks them against the password files. Why not do one complete sweep (making sure no one changes their password in the meantime (disable /bin/passwd perhaps)), and then modify /bin/passwd to reject bad choices for new passwords? At the time the user is typing in the password it is in plaintext and you don't have to encrypt it... We consult a rather large dictionary of bad passwords. Alternatively you can hack up /bin/login (or add a front-end to it) which also gets the password in plaintext, and check it out against a dictionary. When a bad password is used, force the user to change their password. If you had some additional information on the user that you can ask for id verification, use that as well. (When we swept our system we changed broken users' shells to a program that forced them to change their password when they next logged in, and that program asked for additional information (their University ID number). This combined with the modified /bin/passwd would slowly eliminate bad passwords of active accounts (but would not affect unused accounts which are typically the ones that "crackers" use). You could then do your brute force attack on all infrequently used accounts (hopefully a significantly smaller subset of users than the whole passwd file). >If it finds a hit, it sends mail to root advising him/her of the >situation. I would much rather find these holes myself rather than >have some villain find them! Don't send the broken password through the mail, just the username with the bad password. And don't take too long doing something about it (i.e. read root's mail often). Also consider using "shadow" passwords to reduce the chances of an attack on your /etc/passwd file. --Fuat Internet: fuat@columbia.edu U.S. MAIL: Columbia University BITNET: fuat@cunixf Center for Computing Activities UUCP: ...!rutgers!columbia!cunixf!fuat 712 Watson Labs, 612 W115th St. Phone: (212) 854-5128 Fax: (212) 662-6442 New York, NY 10025
- Password checking art
- Re: Password checking Paul Pomes, UofIllinois
- Re: Password checking Fuat C. Baran
- Re: Password checking Ken Leonard
- Re: Password checking Philippe Prindeville