Path: utzoo!utgpu!watmath!clyde!att!pacbell!ames!ncar!tank!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: How to stop future viruses.
Message-ID: <14647@mimsy.UUCP>
Date: 20 Nov 88 06:26:43 GMT
References: <17575@adm.BRL.MIL> <31@microsoft.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 52

In article <31@microsoft.UUCP> w-colinp@microsoft.UUCP (Colin Plumb) writes:
>I repeat: security assumes the attacker knows as much as you do.  This
>is what's fundamentally right about the existing Unix password system.
>The *only* piece of information it's possible to extract from the system
>is whether user "foo" has password "bar".  This applies no matter what
>knowledge of privelege level you have.

`Security' is not really an absolute.  The security of a system can
only be estimated, and even then, only with some assumptions in mind.
While there is substantial merit in the existing scheme (which does not
assume that `unreadable' shadow files are in fact unreadable), there is
also considerable merit in multiple barriers.

>Putting extra barriers in the face of the naive doesn't increase your real
>security one bit, and does distract you from your main goal.

Define `your real security'.  We have people who more or less idly try
to log in (`user fred, password fred; user mike, password mike; oh well,
so much for that'), people who make a slightly more determined effort
(get a listing of actual login names and full names, perhaps by reading
over professors' shoulders, and work from that: these people usually
find it simpler instead to get *paid* to use the machine: i.e., become
an RA or TA), and, rarely, a real attack from someone who knows something
about Unix systems.  We already have adequate protection against the first
two types---not perfect, but adequate; we would like to have protection
against the third.  Shadow password files are a step in that direction.
They may not keep everyone out, but they are likely to help.  Nothing
we do will keep out the NSA, or even the Marines [hi rab! :-) ], but
that is not our objective.  Our objective is to keep out the `average'
attacker, whose ability to decrypt Unix-style encrypted passwords is
on the rise.

>If we keep the password function sufficiently simple that it can be
>computed in a reasonable amount of time (1/4 sec?) on an 11/750 or
>similar wimpy machine, assuming I have a Sun/4 (10 times as fast?) and
>a week or two to spend at it. . . .

Would you like to suggest such a function?  Software DES is nowhere
near that hard.  Besides, you may have access to a network of hundreds
of machines hundreds of times faster, and more than just a week or two
to spend.  This is where shadow files, password aging, multi-level
(`ring') schemes, ACLs, and (eventually) all the rest of the high level
security schemes come in.  They all have some cost; the proper design
of a security system selects the one with the most value for the least
cost.  The value of shadow files is low, but so is the cost; it is
(now, suddenly) seen as within our budget.

(Actually, we are thinking of using the MIT Kerberos stuff instead, here.
It has a somewhat higher cost, but has more value too.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris