trb@haddock.UUCP (02/06/86)
This would be better in a security newsgroup, but there isn't one, so this will have to do. We have all heard of losers who try to break into systems by calling up, and trying to log in by exhaustively trying groups of possible passwords. Some login programs hang up the phone after a number of attempts. A simple refinement which I've never heard mentioned would be to have the login program simply disable the ability to log in successfully after a number of attempts, without notifying the user. This would let the unsuspecting loser keep trying to log into your system while you had plenty of time to trace his phone line without your having to worry about his gaining entry to your system. Andrew Tannenbaum Interactive Boston, MA 617-247-1155
moroney@jon.DEC (Mike Moroney) (02/07/86)
>This would be better in a security newsgroup, but there isn't one, so >this will have to do. >We have all heard of losers who try to break into systems by calling >up, and trying to log in by exhaustively trying groups of possible >passwords. Some login programs hang up the phone after a number of >attempts. A simple refinement which I've never heard mentioned would >be to have the login program simply disable the ability to log in >successfully after a number of attempts, without notifying the user. >This would let the unsuspecting loser keep trying to log into your >system while you had plenty of time to trace his phone line without >your having to worry about his gaining entry to your system. > Andrew Tannenbaum Interactive Boston, MA 617-247-1155 VMS V4 already has this. (Lots of other security goodies, too) -Mike
andersa@kuling.UUCP (02/08/86)
In article <100900001@haddock.UUCP> trb@haddock.UUCP writes: >passwords. Some login programs hang up the phone after a number of >attempts. A simple refinement which I've never heard mentioned would >be to have the login program simply disable the ability to log in >successfully after a number of attempts, without notifying the user. >This would let the unsuspecting loser keep trying to log into your >system while you had plenty of time to trace his phone line without >your having to worry about his gaining entry to your system. This behaviour can be selected in version 6 of DECs not-to-be-continued TOPS-20, which has been around for a while. After the user has provided N invalid passwords within M minutes of real time, every password given thereafter will be considered "invalid", until the job is logged out. A message is also sent to the system console and to the error log file. The time limit exists in order not to penalize weak typists after a few hours of work, and both N and M are easily selected by the system manager. -- Anders Andersson, Dept. of Computer Systems, Uppsala University, Sweden Phone: +46 18 183170 UUCP: andersa@kuling.UUCP (...!{seismo,mcvax}!enea!kuling!andersa)
lauren@vortex.UUCP (Lauren Weinstein) (02/08/86)
Turning off the ability to successfully login on a dialup line (even only for awhile) seems like a good way to allow password crackers to tangle up enough dialup lines to make it hard for legit users to log in. There are people who would just love doing things like that just to cause trouble. --Lauren--
trt@rti-sel.UUCP (02/10/86)
> ... . A simple refinement which I've never heard mentioned would > be to have the login program simply disable the ability to log in > successfully after a number of attempts, without notifying the user. It sounds good but I think it would confuse and frustrate legimate users who are poor typists or have flakey keyboards/communications. I suggest that people who wish to harden their system's security first enhance login to drop connections after 3 failed attempts and add an 'external security' password on modem lines. If that is considered inadequate one can then (be careful!) harden the password-setting program (e.g. BRL's 'passwd') and enhance login to note failed attempts. It would be real nice if 4.3 BSD had that. After these basic things are out of the way more elaborate steps can be considered. Tom Truscott
dpw@rayssd.UUCP (Darryl P. Wagoner) (02/10/86)
> > attempts. A simple refinement which I've never heard mentioned would > be to have the login program simply disable the ability to log in > successfully after a number of attempts, without notifying the user. > This would let the unsuspecting loser keep trying to log into your > system while you had plenty of time to trace his phone line without > your having to worry about his gaining entry to your system. > I think a good hacker would get wise before to long. Almost all login programs have a limit. I would worry about one that didn't. This would also mean that the SA would have to let the users know that this would happen and by doing this would more than likely let the hacker know as well. We have put in a notice that someone has tried to login to your account at login time with the number of unsuccessful attempts. We also limit the number of tries to three. -- Darryl Wagoner Raytheon Co.; Portsmouth RI; (401)-847-8000 x4089 ...!decvax!brunix!rayssd!dpw ...!allegra!rayssd!dpw ...!linus!rayssd!dpw
gwyn@brl-smoke.ARPA (Doug Gwyn ) (02/10/86)
In article <879@vortex.UUCP> lauren@vortex.UUCP (Lauren Weinstein) writes: >Turning off the ability to successfully login on a dialup line (even >only for awhile) seems like a good way to allow password crackers >to tangle up enough dialup lines to make it hard for legit users >to log in. There are people who would just love doing things like >that just to cause trouble. Exactly right. "System security" should include protection against disruption of operations. Funny how people keep wanting to believe that there is a simple solution.
sewilco@mecc.UUCP (Scot E. Wilcoxon) (02/10/86)
In article <974@decwrl.DEC.COM> moroney@jon.DEC (Mike Moroney) writes: >>... >>be to have the login program simply disable the ability to log in >>successfully after a number of attempts, without notifying the user. >>... >> Andrew Tannenbaum Interactive Boston, MA 617-247-1155 > >VMS V4 already has this. (Lots of other security goodies, too) > CDC's NOS has had that for five years. I think I also remember MULTICS having it for much longer than that. We used to have a large CDC machine for hundreds of high schools to use. One of the things I did to reduce foolishness was to write a little program which reported the time (hours, days, years) required to go through all the combinations on a password. I then made the source public and rather well-known in that machine. All the variables were clearly documented so people could try different password lengths, retry times, etc. I was told by several kids that before they looked at that program they hadn't realized the huge number of possible passwords. -- Scot E. Wilcoxon Minn. Ed. Comp. Corp. quest!mecc!sewilco 45 03 N / 93 15 W (612)481-3507 {ihnp4,mgnetp}!dicomed!mecc!sewilco
kwh@bentley.UUCP (KW Heuer) (02/11/86)
In <100900001@haddock.UUCP> haddock!trb (Andrew Tannenbaum) writes: > A simple refinement which I've never heard mentioned would >be to have the login program simply disable the ability to log in >successfully after a number of attempts, without notifying the user. >This would let the unsuspecting loser keep trying to log into your >system while you had plenty of time to trace his phone line ... Trouble is, (a) no serious cracker will actually make guesses to the login program. (b) If he knows about this feature, the cracker can turn it to his advantage by locking out all the administrators. This was analyzed in, I think, the October 1984 issue of the _AT&T_Technical_Journal_ (special UN*X issue); but I can't find a copy to verify it. Karl W. Z. Heuer "The Walking Lint"
moroney@jon.DEC (Mike Moroney) (02/12/86)
>Turning off the ability to successfully login on a dialup line (even >only for awhile) seems like a good way to allow password crackers >to tangle up enough dialup lines to make it hard for legit users >to log in. There are people who would just love doing things like >that just to cause trouble. With many phone systems they can do this anyway, the called line is NOT released until the CALLER hangs up. All such a person needs to do on such a system is call the modem and leave his phone off the hook. If you are curious if your phone system is like this, try the following: 1) Call a friend. 2) Have friend hang up. You do not hang up. 3) Have friend pick up his receiver again. 4) If you are still connected, you have this type phone system. This will not work with long distance. -Mike Moroney
ken@birtch.UUCP (Ken B) (02/12/86)
In article <974@decwrl.DEC.COM> moroney@jon.DEC (Mike Moroney) writes: > > >>We have all heard of losers who try to break into systems by calling >>up, and trying to log in by exhaustively trying groups of possible >>passwords. Some login programs hang up the phone after a number of >>attempts. A simple refinement which I've never heard mentioned would >>be to have the login program simply disable the ability to log in >>successfully after a number of attempts, without notifying the user. >>This would let the unsuspecting loser keep trying to log into your >>system while you had plenty of time to trace his phone line without >>your having to worry about his gaining entry to your system. > >> Andrew Tannenbaum Interactive Boston, MA 617-247-1155 > >VMS V4 already has this. (Lots of other security goodies, too) > >-Mike What if the hacker tries to login to root? does the login program change the password? or does it just mark that one phone line? If it changes the password, that could be trouble! Ken Brown -- uucp: ...{!glacier!oliveb,!trwrb!scgvaxd} !felix!birtch!ken These ramblings are my own, and are surely not those of my employer.
hes@ncsu.UUCP (Henry Schaffer) (02/12/86)
The article in The Oct. 1984 AT&T Bell Labs Technical Journal might be "UNIX Operating System Security" by F. T. Grampp and R. H. Morris (p. 1649-1672.) It mentions that some systems will count the login attempts and if there are too many will disable the *account*. This makes more sense than disabling the line, but still leaves an opening for mischief, e.g.: "For the intruder who has already gained access to the system, and who wants to get rid of the system administrator, the feature is a blessing: login: guru password: foo repeated the appropriate number of times will assure the intruder of privacy for at least a little while." --henry schaffer n c state univ
jay@imagen.UUCP (Jay Jaeckel) (02/13/86)
Mike Maroney suggests this experiment: > . . . the called line is NOT > released until the CALLER hangs up. . . . . . . If you are > curious if your phone system is like this, try the following: > 1) Call a friend. > 2) Have friend hang up. You do not hang up. > 3) Have friend pick up his receiver again. > 4) If you are still connected, you have this type phone system. > > This will not work with long distance. > At least with the phone systems I've used, this is not quite so. Rather: (1) If the callER hangs up, the connection is broken at once. (2) If the callEE hangs up, the connection is not broken for about 30 seconds or so. Then it is. -- Jay Jaeckel ...{decwrl,ucbvax}!imagen!jay
andersa@kuling.UUCP (Anders Andersson) (02/13/86)
In article <588@bentley.UUCP> kwh@bentley.UUCP writes: >In <100900001@haddock.UUCP> haddock!trb (Andrew Tannenbaum) writes: >>This would let the unsuspecting loser keep trying to log into your >>system while you had plenty of time to trace his phone line ... > >Trouble is, (a) no serious cracker will actually make guesses to the >login program. (b) If he knows about this feature, the cracker can >turn it to his advantage by locking out all the administrators. a) Besides the "serious" crackers, there are probably a lot of non-serious dito, rather not knowing very much at all about "how to do it". They're not seeking money or secret information, instead they ask for a special kind of excitement, "on the border of what's unallowed" (really they have plunged right into it), maybe making trouble for others, knowing that they have found some backdoor or whatever. I'll rather *bore* them to death than put a lot of fancy gizmos into operation in front of their smiling faces. b) I don't think Tannenbaum suggested locking out the *target* of the intruder, but rather the intruder himself. Knowing about the feature, he'll probably give up guessing passwords before he started. And yes, there might be those fools finding it fun to occupy a modem. Sure anybody who hasn't logged in within a reasonable amount of time should be hanged up. I suggest we shouldn't give any extra clues by letting people measure differences in time depending on whether the last username tried was valid or not. -- Anders Andersson, Dept. of Computer Systems, Uppsala University, Sweden Phone: +46 18 183170 UUCP: andersa@kuling.UUCP (...!{seismo,mcvax}!enea!kuling!andersa)
ddl@tardis.UUCP (02/13/86)
But please, whatever you do, don't disable individual accounts (vs. individual sessions) based on failed login attempts, as some not-to-be-mentioned systems do. Think of the happy cracker who types the system administrator's login and random passwords a few times... Then maybe root for good measure. Now untroubled by anoying authority... Dan Lanciani ddl@tardis.*
lauren@vortex.UUCP (Lauren Weinstein) (02/14/86)
Unlimited calling party hold only exists these days in EXTREMELY old Step-by-step offices. All ESS, Crossbar, and most Directorized SXS exchanges will break the connection after the CALLED party hangs up, after a timeout interval. The called party must stay on hook for a period ranging from 10 seconds to a minute or so, depending on a variety of equipment specifics, for the line to clear in this manner. So only in the crudest old central offices, and then only for local calls, can the calling party clog up a phone line simply by refusing to hang up. --Lauren--
rab@well.UUCP (Bob Bickford) (02/18/86)
In article <1075@decwrl.DEC.COM>, moroney@jon.DEC (Mike Moroney) writes: > > >Turning off the ability to successfully login on a dialup line (even > >only for awhile) seems like a good way to allow password crackers > >to tangle up enough dialup lines to make it hard for legit users > >to log in. There are people who would just love doing things like > >that just to cause trouble. > > With many phone systems they can do this anyway, the called line is NOT > released until the CALLER hangs up. All such a person needs to do on such > a system is call the modem and leave his phone off the hook. If you are > curious if your phone system is like this, try the following: > 1) Call a friend. > 2) Have friend hang up. You do not hang up. At this point, you forgot to say "wait at least 30 seconds". Many phone systems will 'hold' the line for a few seconds, to avoid glitches (read: disconnections) in the case of a bad line. I believe this works for both the caller and the receiver (but am not sure). Then, resuming with Mike's instructions: > 3) Have friend pick up his receiver again. > 4) If you are still connected, you have this type phone system. > > This will not work with long distance. > Robert Bickford (rab@well.uucp) ================================================ | I doubt if these are even my own opinions. | ================================================
mnh@duts.UUCP (Mark Haynie) (02/19/86)
> In article <974@decwrl.DEC.COM> moroney@jon.DEC (Mike Moroney) writes: > > > > > >>We have all heard of losers who try to break into systems by calling > >>up, and trying to log in by exhaustively trying groups of possible > >>passwords. Some login programs hang up the phone after a number of > >>attempts. A simple refinement which I've never heard mentioned would > >>be to have the login program simply disable the ability to log in > >>successfully after a number of attempts, without notifying the user. > >>This would let the unsuspecting loser keep trying to log into your > >>system while you had plenty of time to trace his phone line without > >>your having to worry about his gaining entry to your system. Some MVS systems do exactly that! After 12 login attempts your ID is disabled. Since MVS systems tell you when you have invalid user-ids before you enter the password, you can write a program which will find all the user ids on a system and then quickly turn them off. Manual interventions is required to turn ids back on -- requiring several hours for all ids of a corporation. Shutting down a computer center in this way is about as bad as breaking into one. -- mark haynie
henry@utzoo.UUCP (Henry Spencer) (02/21/86)
> The article in The Oct. 1984 AT&T Bell Labs Technical Journal > might be "UNIX Operating System Security" by F. T. Grampp and > R. H. Morris (p. 1649-1672.) ... That article is very much worth reading, in fact, purely for its discussion of why various seemingly-attractive security ideas DON'T WORK in practice. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
tgl@a.sei.cmu.edu (Tom Lane) (02/21/86)
Quite a few people have objected to the concept of permanently
disabling logins to a particular account after seeing several
erroneous login attempts on that account. I agree that that's
a bad idea, but when I read Tanenbaum's original post I thought
he meant something rather different, to wit:
After seeing more than N erroneous login attempts on a dialup
line, refuse to honor any further login attempts ON THAT LINE
until the connection is broken.
As far as I can see, this would have NO impact on the genuine owner
of the account, who could still log in any time he comes along.
Ditto for subsequent users of the same dialup line.
Naturally, to make this properly confusing the machine should still
appear to be considering further userid/password pairs; it should
simply always say "improper login" even if, by chance, a valid
combination is entered. Then the attacker can have no certainty
that he has in fact performed an exhaustive search of the password
combinations: he might have tried the right one, but had it rejected
anyway. (To make life harder, the precise value of N should
be unpublicized, and perhaps even randomly variable. It's also
necessary not to say "improper login" more quickly after exceeding
N attempts than beforehand.)
With this plan, all the attacker accomplishes in the way of
denial-of-services is to tie up one dialup port, which he will probably
get tired of once he notices how his phone bill is mounting.
tom lane
-----
ARPA: lane@{CMU-CS-A.ARPA|A.CS.CMU.EDU}
UUCP: ...!seismo!cmu-cs-a!lanedas@ucla-cs.UUCP (02/22/86)
Or, if your system can support it, how about this:
After N bad attempts at guessing a password, voila`! The penetrator
succeeds at logging in. Of course, what he really gets is a special
shell that logs everything (and notifies the appropriate administrators);
of course, his userid is not that of any real user. The special shell looks
real enough to keep the bad guy occupied for a while (the better to collect
evidence). Obvious things to do include giving doctored responses to requests
to see the password file or to see what programs are available. Intriguing
program names or logon ids might keep him interested longer.
To keep him fooled even longer, the first thing to do after login could
be to say, "Some commands restricted because of dialin; password for full
regular access:" or something like that. Since he won't get that password
right (it doesn't exist, of course), he won't be surprised when he can't do
everything that he might know the OS is capable of, so he won't question as
hard any "command not permitted" responses that the special shell gives
whenever he asks to do something you didn't bother to implement a fake reply
for.
A nice touch would be to have a fake bulletin board system with a few
messages about interesting phone numbers to call. In that way you might
induce him to call a real person (you or a friend of yours) who might be
able to extract some personal data about him in the course of a friendly
conversation about pirate BBS's, dial-a-joke lines, etc.
Or let him read netnews. He'll spend a lot of time on that, time he
would otherwise spend trying to mess up your system.
-- David Smallberg, das@locus.ucla.edu, {ihnp4,ucbvax}!ucla-cs!daskludge@gitpyr.UUCP (Scott Dorsey) (02/23/86)
In article <9281@ucla-cs.ARPA> das@ucla-cs.UUCP (David Smallberg) writes: >Or, if your system can support it, how about this: > > After N bad attempts at guessing a password, voila`! The penetrator >succeeds at logging in. Of course, what he really gets is a special >shell that logs everything (and notifies the appropriate administrators); >of course, his userid is not that of any real user. The special shell looks >real enough to keep the bad guy occupied for a while (the better to collect >evidence). Obvious things to do include giving doctored responses to requests >to see the password file or to see what programs are available. Intriguing >program names or logon ids might keep him interested longer. I have seen similar systems with exactly the opposite purpose; they prompt a user for his account and password, mail the information to a given user (to pick up later), then give a message saying that the system is overloaded, and to try again. Then they log out and the user tries to log in again, this time successfully. In fact, I got caught by one of them a while back. Just a short little diversion to say that perhaps they might recognize their own methods. ------- Disclaimer: Everything I say is probably a trademark of someone. But don't worry, I probably don't know what I'm talking about. Scott Dorsey ICS Programming Lab, Georgia Insitute of Technology, Atlanta Georgia, 30332 ...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!kludge
ugbowen@sunybcs.UUCP (Devon Bowen) (03/08/86)
> > >>We have all heard of losers who try to break into systems by calling > > >>up, and trying to log in by exhaustively trying groups of possible > > >>passwords. Some login programs hang up the phone after a number of > > >>attempts. A simple refinement which I've never heard mentioned would > > >>be to have the login program simply disable the ability to log in > > >>successfully after a number of attempts, without notifying the user. > > >>This would let the unsuspecting loser keep trying to log into your > > >>system while you had plenty of time to trace his phone line without > > >>your having to worry about his gaining entry to your system. 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. I hear IBM's mainframe has a fool-proof way of dealing with hackers. The computer stores each users phone number in memory. When the user calls in and completes the login correctly, the mainframe hangs up and calls the user back. This way the hacker would have to be at the users house to do any hacking! Devon E
fetrow@entropy.UUCP (David Fetrow) (03/11/86)
There are ways around callback units, not all of which require diddling
with wires on the part of you or the phone company. Since I'm not in the
business of making techniques public I won't.
NEVER trust a piece of hardware with all your security. They can be difficult
to crack but once cracked, the system is too open. Some callback units aren't
even difficult.
--
- Dave Fetrow
{ ihnp4, fluke, tektronix, uw-june }!uw-beaver!entropy!fetrow :UUCP
entropy!fetrow@uw-june.arpa :ARPA
fetrow@UWALOCKE :BITNET
74175,1724 :Compuserve