Re: Password checking

"Fuat C. Baran" <> Wed, 04 April 1990 21:08 UTC

Received: from by (5.61/2.2) id AA22256; Wed, 4 Apr 90 17:08:36 -0400
Received: by (5.59/FCB) id AA04591; Wed, 4 Apr 90 17:08:17 EDT
Date: Wed, 4 Apr 90 17:08:15 EDT
From: "Fuat C. Baran" <>
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: <>

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


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