Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version nyu B notes v1.5 12/10/84; site acf4.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!seismo!cmcl2!acf4!tihor
From: tihor@acf4.UUCP (Stephen Tihor)
Newsgroups: net.followup
Subject: Re: Hackers at dutesta (with solution) (no solution really)
Message-ID: <590003@acf4.UUCP>
Date: Mon, 25-Mar-85 21:43:00 EST
Article-I.D.: acf4.590003
Posted: Mon Mar 25 21:43:00 1985
Date-Received: Thu, 28-Mar-85 01:32:52 EST
References: <531@inset.UUCP>
Organization: New York University
Lines: 16

dave@inset sez:

>Read the AT&T Bell Laboratories Technical Journal (yawn) Oct. '84 UN*X issue,
>there's a paper there on UN*X security which explains what's wrong with this:
[disabling accounts with some high % of failures]
>If you do this for root, you've got problems ...

Thats only true if you implement the naive mode of a single counter for all
each account and include everyone...etc.
There is some interesing discussion of this issue in the VMS guide to system 
security.  The solution implemented there was to allow (1) local control
over all the parameters, (2) an emergency entrance at the physical console 
to let root have at the system when all else fails since physical access to 
the console implies control of the system anyway, (3) couts login failures
in most cases on a SOURCE X USERNAME basis and then support disabling for
a variable period of time after the last failure of suspicious set of failures.