Path: utzoo!mnetor!uunet!husc6!bloom-beacon!athena.mit.edu!jfc
From: jfc@athena.mit.edu (John F Carr)
Newsgroups: sci.crypt
Subject: Re: Unix Password Hacker
Message-ID: <3111@bloom-beacon.MIT.EDU>
Date: 21 Feb 88 05:40:05 GMT
References: <731@ddsw1.UUCP> <203@tijc02.UUCP>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: jfc@athena.mit.edu (John F Carr)
Distribution: na
Organization: Massachusetts Institute of Technology
Lines: 33

In article <203@tijc02.UUCP> pjs269@tijc02.UUCP (Paul Schmidt        ) writes:

>Our company has had the policy of assigning passwords and making them
>unchangeable to the employees.  These passwords are totally random so
>that this technique will not work.  When I first started working here
>I did not understand this philosophy.  But, now I do.
   [...]
>There are obvious ways for system administrators to detect crypt hackers.
>All they have to look for is CPU hogs.  (That is, unless the hacker uses his
>own machine (PC) which will probably run alot slower and he needs the crypt()
>routine on that machine).  Therefore, properly chosen passwords will currently
>almost gaurantee security on this brute force type attack.

>		Paul Schmidt
>		Texas Instruments

The problem with this method (random passwords) is that the user is much
more likely to write down the password.  I once worked at a company which
put a lot of effort into security.  They randomly determined passwords for
the system accounts.  They also had an operator who wrote down this 
random password to remember it.  Had I wanted to, I could have done a lot
of damage to the system (as the password belonged to several accounts on
different machines).

At the same time, I was debugging an assembly language program using a
debugger set to trace every instruction.  This caused a very high load
for a legitimate reason (high load: CPU time almost as great as real time).

Perhaps what we need is a better crypt(), though careful password selection
will never hurt.


  --John Carr   (jfc@ATHENA.MIT.EDU)