Password checking

art@dinorah.wustl.edu Wed, 04 April 1990 20:15 UTC

Received: from wupost.wustl.edu by cert.sei.cmu.edu (5.61/2.2) id AA21982; Wed, 4 Apr 90 16:15:25 -0400
Received: by wupost.wustl.edu (5.61++/WUSTL-0.3) with SMTP id AA21398; Wed, 4 Apr 90 15:10:37 -0500
Return-Path: <art@dinorah.wustl.edu>
Date: Wed, 04 Apr 1990 15:13:42 -0500
From: art@dinorah.wustl.edu
Message-Id: <9004042013.AA04393@dinorah.wustl.edu>
To: ssphwg@cert.sei.cmu.edu
Subject: Password checking

Just to start a topic...

    Except for a few truly isolated hosts (who are not a concern of
ietf anyway 8^) ) all our computers' security is only as good as their
passwords.  It is disturbing how easy it is to break into a unix host
if you have a copy of its /etc/passwd file and don't mind crunching
for a while.

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

    Is this the safest way to run it?  My program always sends mail to
root on startup and completion, and whenever it finds a hit (that is
the only notification of a hit!).  Is that safe enough?  If an evil
person gets the program and is a superuser on their own machine this
doesn't help.

    How do we tell the system managers how to check for obvious
passwords without giving the same advice to malfeasors?  Hiding a
problem is NOT security -- that has been shown lots of times in the
past -- but neither is advertising flaws widely.

    BTW, please do not request a copy of the program from me, I will
not send it unless I know you (in person or by reputation) -- e.g., I
might send it to Phil Gross or Doug Gwynn or others that I know from
the net (if they want them), but not to just anyone who asks.  Perhaps
some consideration should be given to how to distribute "sensitive"
information within this working group (have I just disqualified
myself? 8^) ), and how to authenticate "members." 

    Pardon me if this is all obvious.  I've heard these problems
before, but never any (good) solutions.

    	    art smith
 (art@dinorah.wustl.edu     -or-    ...!uunet!wucs1!dinorah!art)