Xref: utzoo news.sysadmin:1275 comp.unix.wizards:12254
Path: utzoo!attcan!uunet!husc6!mailrus!ames!pasteur!agate!math!greg
From: greg@skippy.berkeley.edu (Greg)
Newsgroups: news.sysadmin,comp.unix.wizards
Subject: Re: How to stop future viruses.
Message-ID: <16768@agate.BERKELEY.EDU>
Date: 9 Nov 88 23:46:05 GMT
References: <16722@agate.BERKELEY.EDU> <2178@cuuxb.ATT.COM>
Sender: usenet@agate.BERKELEY.EDU
Reply-To: greg@math.Berkeley.EDU (Greg)
Organization: UC Berkeley
Lines: 28

In article <2178@cuuxb.ATT.COM> dlm@cuuxb.UUCP (Dennis L. Mumaugh) writes:
>In article <16722@agate.BERKELEY.EDU> greg@math.Berkeley.EDU (Greg) writes:
>     The obvious solution is to  optimize  crypt(3)  as  much  as
>     possible,  and  then decide how many encryption passes there
>     should be.  Since 40  x  25  =  1000,  I  recommend  several
>     thousand  passes.
...
>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.

Firstly, there is no way that a virus would beam all passwords to
one central computer to be processed there.  

Secondly, your approach will no longer work with the advent of the
salt, the 12 random bits stored in the clear with the encrypted
password.  You would have to encrypt the dictionary 4096 times, or be
content with cracking a much smaller portion of the password file.  It
would be good to expand the salt to 36 bits, just to make sure that you
can't preencrypt even a small dictionary.

Lastly, I'm not arguing that my suggestions will prevent password guessing
completely, just that it will make it harder.  I limited my suggestions
to easy fixes for Unix.
--
Greg