mike@WISDOM.BITNET (Mike Trachtman) (02/27/86)
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...
mikeks@svo.UUCP (03/14/86)
/* Written 7:49 pm Mar 7, 1986 by ugbowen@sunybcs.UUCP in svo.UUCP:net.crypt */
I think a better way to ensure that you have time to trace the call
would be to set up a mock account as a default account that would be
automatically logged into after a number of unsuccessful attempt. This
account could have seemingly important files and programs. This would
encourage the hacker to stay on the system for a long period of time.
Logging into this account would also alert security and they could
trace the call.
...
Devon E
/* End of text from svo.UUCP:net.crypt */
This, of course, is (almost) the way that the folks at one ARPAnet site
dealt with an intruder. I will try to pull up and post the old archived
copy of an article which reid@Glacier sent me about it. Essentially,
they baited the intruder (who was exploiting a bug on a UNIX system
whereby the default PATH included a directory which was world writable;
you can guess the rest). Each day he would find new 'powers' and would
allow the law enforcement community to track the intruder.
Unfortunately, just as the FBI was about to close in, the person stopped
calling--very coincidentally with the arrest of several hackers in Los
Angeles CA, which is point from which the calls were rumored to have
originated. The intruders used several network entry points, including
Telenet and ARPAnet hosts, and 'old' accounts, to travel on the Internet.
This is one reason why I believe that Internet access should be more
closely audited by the various NOCs, and physical security should be
more robust. I will make this point more clear in a related posting
in RISKS-FORUM shortly...
What are your views? Do you care about information security? Cryptology
is a very important part of creating reasonable access control, authenti-
cation, and validation!
Cheers.
Kurt F. Sauer
Tulsa, Oklahoma