Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!ittatc!dcdwest!sdcsvax!ucbvax!wisdom.BITNET!mike
From: mike@WISDOM.BITNET (Mike Trachtman)
Newsgroups: net.crypt
Subject: Re; foiling password crackers
Message-ID: <8602271858.AA11517@ucbvax.berkeley.edu>
Date: Thu, 27-Feb-86 15:07:48 EST
Article-I.D.: ucbvax.8602271858.AA11517
Posted: Thu Feb 27 15:07:48 1986
Date-Received: Sat, 1-Mar-86 17:52:29 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: University of California at Berkeley
Lines: 49

To me it seems, that the object should be to
1) frustrate the person trying to break into the system,
        so that he will not tie up the line,
2) without giving him to many clues as to which passwords are wrong.

I would therefore suggest the following mix, which
is just a combination of things mentioned by others

have three random variables

var_incorrect,var_hangup, and var_numcalls

var_numcalls, is determined at system boot.

what happens is as follows:

When a user calls, then var_incorrect, and var_hangup are chosen

let var_hangup >= var_incorrect.

after var_incorrect attempts on the current call, elapse,
then the system will say 'login incorrect', regarless
of whether the supplied password is correct.

after var_hangup attempts, it just hangs up.

After var_numcalls, of unsuccesfull logins on that line,
then it will disable those accounts that had been attempted
more than var_incorrect (or someother random number) of times.

These accounts, should reactivate after one of the following
conditions:

1) a certain timeout period has elapsed. (one hour maybe,
        except at night, then at the next morning).
2) somebody has succesfully logged in on that line, for more
        than ten minutes.

of course, the history of what occured should be sent to
the appropiate (console,file,user or whatever).

This should cause very little information, to be passed on
to the cracker, and yet keep the phone line open, and the
account almost active, for the correct user.

p.s. var_incorrect should be >3 or so...

enough rambling...
mike