🚀 go-pugleaf

ckd@eff.org (Christopher Davis) writes:
>
> Wes> 	- I can set a simple policy that says "this system is not to be used
> Wes> 	  for the development or use of password cracking software".  My users
> Wes> 	  are Engineering students; they have no curricular need to develop
> Wes> 	  such software on our systems.  
>
>
>Or you could run shadow passwords, and run Crack yourself, and have a
>proactive password checker.

I run Crack and COPS on a regular basis; a real-time password checker
is in the works.  8)

>This also benefits everyone, because it means that people are less
>likely to have their accounts broken into, you don't get into problems
>with people being duped into giving out your /etc/passwd for Joe Cracker
>to run through Crack on his 486/50 (or on the SS2 he broke into last
>week), and even if someone does get your shadow file, your passwords
>will have some degree of strength.
>
>I realize that this isn't always doable, but it's a big improvement.

There are external factors to be considered........

Here's a "real world" problem:

Earlier this year, I received a call from an admin at another university.  
He found a user cracking his (and other) systems, and proceeded to follow 
the normal procedures for disciplinary proceedings.  During the ensuing 
investigation, it was discovered that this individual had copies of password
files from many sites; system accounting records revealed that he had also
been running Crack.  During the auditing of his files, electronic mail 
archives indicated that some of those password files may have come from my 
university; the admin requested my assistance in tracking down the (possibly) 
compromised systems.

Thankfully, none of the systems here were compromised (or even attacked).
However, I discovered that this cracker had accumulated password files
from at least 10 different systems in 5 states.  

{ Enter philosophical mode }

Many people have spoken of the "cooperative spirit" of networking.  We've
discussed policies, shared code, and helped each other through problems.

I've been a sysadmin for 4 years, and I've used Unix for 11 years.  However,
many sites' admins are inexperienced; indeed, many of them become sysadmins
by default.  (How many times have we seen postings such as "I've just been
told that I'm going to be administering our Sun workstations, so....."?)  Many
of those novice sysadmins depend on the assistance of their more experienced
colleagues. 

In some ways, we *are* our 'brother's keeper'.

Why, then, should our assistance be restricted to reactive functions?
If I can take steps to prevent potential problems WITHOUT affecting
my core mission (Engineering education, in my case), why *shouldn't*
I do so?  

[As I mentioned in an earlier posting, some sites may have a curricular
 (or professional) obligation to provide facilities for cryptographic
 work.  Were I in such a situation, I would find some means of isolating
 them from 'live' systems.  This university recently offered a CompSci class 
 entitled "Computer Security"; in the course of instruction, the students 
 were given a copy of Crack.  At the request of the instuctor, I created a 
 dummy /etc/passwd file which was completely devoid of "real world" informa-
 tion.  The appropriate warnings against extracurricular use of the program 
 were issued, the course proceeded, and everyone was satisfied.]

I believe that I, as a sysadmin, have a certain obligation to the other
systems using our common network(s).  Why should I allow my system to be
used as a 'forward base' from which to attack other systems?  Should I
adopt an attitude such as "well, he's not cracking MY password file, so
I don't care"?  If I found someone attempting to crack the password file 
for kragar.eff.org, wouldn't you want me to notify you?  If so, why shouldn't 
I prevent it in the first place, if such a goal is (relatively) attaniable?

{ Exit philosophical mode }

-- 
MORGAN@UKCC         |       Wes Morgan       |        ...!ukma!ukecc!morgan 
morgan@ms.uky.edu   | Engineering  Computing |   morgan@wuarchive.wustl.edu
morgan@engr.uky.edu | University of Kentucky | JWMorgan@dockmaster.ncsc.mil
  Mailing list for AT&T StarServer S/E  - starserver-request@engr.uky.edu