Xref: utzoo news.sysadmin:1387 comp.unix.wizards:12338
Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!oliveb!olivey!jerry
From: jerry@olivey.olivetti.com (Jerry Aguirre)
Newsgroups: news.sysadmin,comp.unix.wizards
Subject: Re: How to stop future viruses.
Message-ID: <32444@oliveb.olivetti.com>
Date: 11 Nov 88 22:19:48 GMT
References: <16722@agate.BERKELEY.EDU> <2178@cuuxb.ATT.COM>
Sender: news@oliveb.olivetti.com
Reply-To: jerry@olivey.UUCP (Jerry Aguirre)
Organization: Olivetti ATC; Cupertino, Ca
Lines: 41

In article <2178@cuuxb.ATT.COM> dlm@cuuxb.UUCP (Dennis L. Mumaugh) writes:
>Still a bad approach.  A work factor assumes that one has  do  do
>this  on  line.  When  Ken  Thompson  did  his password attack he
>sucked the password file back to  his  home  system  and  did  it
>there.  [Nowdays  one  could  use a CRAY]. When I did my password
>attacks I  encrypted  the  dictionary  FIRST.  Then  it  was  one
>encrypt  and  a fgrep.  From start to finish (copy of /etc/passwd
>until printing of list of lognames and password was 45 minutes!).

Several people have mentioned using a Cray to crack passwords.  From
what I have read, and from benchmark results, the Cray is not a very
fast CPU for non-vector operations.  So, unless the password
encryption can be vectorized, the Cray is not likely to be very fast at
doing it.  Now maybe one of those Amdahl systems...

Someone else posted that the Unix salt was really restricted to 400
values.  I checked my (4.3BSD) systems.  Out of 774 unique encryptions
there were 702 unique salts.  (Many times the same password is used on
different systems so we copy it, salt and all.) I assume that the 400
salt bug either applies to some other version or is untrue.  A larger
salt would be a good idea though.  Multi gigabyte, even terabyte storage
is available today so a precomputed password dictionary, indexed for
fast access, becomes more and more practical.

Hiding the real passwords in a second copy of the /etc/password file
that can only be read by root sounds easy to implement and should
protect against private copies of crypt running.  It also limits
legitimate use of the password, the "gone" program for example.

You also return to the situation the Unix password system was designed
to avoid.  If someone EVER gets root access, even if only read access,
then they can mail the password file to themselvs.  And how about that
extra root dump you keep handy for booting systems?  Is it locked up
tight?  My point is that this requires new procedures to fully implement
it.  Of course, even if it leaks, security is no worse than with
publicly readable passwords.

Me?  I am fighting to get our users to use passwords, preferably
something different from their login name.

					Jerry Aguirre