From: kadie@herodotus.cs.uiuc.edu (Carl M. Kadie)
Newsgroups: alt.comp.acad-freedom.talk
Subject: [comp.admin.policy] Re: Sysadmin for a Day, was Re: Banned Computer Material 1992
Date: 11 Oct 92 22:32:50 GMT
Followup-To: alt.comp.acad-freedom.talk,comp.admin.policy
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL

[A repost - Carl]

From: escott@JOHN-PARKER.ICS.UCI.EDU (Scott Menter)
Newsgroups: comp.admin.policy
Subject: Re: Sysadmin for a Day, was Re: Banned Computer Material 1992
Date: 10 Oct 92 19:14:53 GMT


 
I think you make some interesting points, Wes.  My observations are below.

> I offer alternatives in every situation.  For those interested
> in Crack, I offer various texts on cryptography, the DoD Password
> Management Guideline (which includes some interesting information),
> "sanitized" log files from my own runs of Crack, and the source code
> in hardcopy form.  [If someone can argue that the only way to under-
> stand Crack is to run it, I'd like to hear it.]

What about the guy at CMU who is doing research on password frequencies and
security?  You might not have such a person at your institution, but it seems
like that might be a resonable field of inquiry.

> Would you support a student who wanted to use the Chemistry lab to make
> nitroglycerin "for the heck of it"?  If you did support such an endeavor,
> wouldn't you implement certain safety precautions?  Wouldn't those pre-
> cautions be for the protection of ALL lab users?  Why shouldn't a com-
> puting facility be protected by similar procedures?
> 
> --Wes

Let me offer a competing analogy (dueling analogies? 8^).  The State
considers it necessary to limit drivers to 65mph on rural interstate
highways.  Two approaches to this are:  (a) post a speed limit, and nail
anybody who drives beyond the limit, or (b) prohibit cars from being sold in
the US that are capable of driving faster than 65mph.  These can be though of
as "direct" and "indirect" approaches to the problem, I guess.  (The indirect
approach is favored by religious institutions:  for example,
Sabbath-observant Jews, prohibited from writing on Saturday, are also
prohibited from picking up a pencil, lest they be led into writing.)

The problem with the indirect approach is that it creates a larger
enforcement problem than may be warranted.  If the goal of your policy is
that users not have illegal access to one another's accounts, there are ways
to enforce that directly, by observing who is logging in, when, and where
(let's save discussion on whether or not this observation is appropriate, for
now).  By trying to indirectly enforce that goal, that is, by seeking out
"crack" programs, it seems that you may  (a) create a bigger headache for
yourself, (b) create a negative impression with the users that you are
looking over their shoulders and at their files, and (c) you may walk into a
situation where you are interfering with legitimate activity.

In the specific case of password cracking programs you may have a stronger
case at a commercial institution, I think.

 - Scott


E. Scott Menter					escott%esm.com@uu4.psi.com
President						Phone 714-432-6307
Enterprise Systems Management                           FAX   714-432-6506
575 Anton Blvd., Suite 300
Costa Mesa, California 92626	    "Excellence in Open Systems Computing"

--
Carl Kadie -- kadie@cs.uiuc.edu -- University of Illinois at Urbana-Champaign
Newsgroups: alt.comp.acad-freedom.talk