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