poulin@polar.bowdoin.edu (Jeff Poulin) (04/22/91)
I think as long as a password file is available for anyone to read, there will be some abuse. Sure, it's dumb to use a word in the dictionary as a password, but I've seen ridiculously complicated passwords here these past few days. No matter how confuscated your password may be, it still boils down to a guessing game between you and the cracker. You try to pick a combination the cracker is not likely to try, and he (or she) will try to outsmart you by choosing it. If you're really worried about kids getting into your account (an adult who tries to pick people's passwords is considered a child in my book), then write a password program for yourself and run it from .cshrc (or whatever). That way, even if someone breaks into your account, they still have another password to crack before they have access to your files. If the second password is incorrect, your password program simply logs you out. Since the file with the password encryption resides in your account, you don't have to worry that someone is cracking your password on some PC somewhere. Jeff Jeff Poulin poulin@polar.bowdoin.edu jpoulin@bowdoin.bitnet
jeffs@soul.esd.sgi.com (Jeff Smith) (04/24/91)
In <26616@adm.brl.mil> poulin@polar.bowdoin.edu (Jeff Poulin) writes: >write a password program for yourself and run it from .cshrc (or That may help, but a resourceful hacker will easily get past that. You can often ^C to terminate the .cshrc, or replace the .cshrc via the network (with ftp). It's best to use good passwords. Some newer systems now split up the password file information so you can't read the encripted password without root authority. jeffs
sidana@neon.Stanford.EDU (Ashmeet S Sidana) (04/24/91)
In article <26616@adm.brl.mil> poulin@polar.bowdoin.edu (Jeff Poulin) writes: >write a password program for yourself and run it from .cshrc (or >whatever). That way, even if someone breaks into your account, they If you try this, make sure the first thing you do on login is turn off all interrupts! (Its not enough to turn off ^C in password program itself since the intruder may interrupt the shell). Even then there is a window ... ---Ashmeet Sidana sidana@cs.stanford.edu sidana@hpcc01.hp.com
bennett@mp.cs.niu.edu (Scott Bennett) (04/24/91)
In article <1991Apr23.182654.22452@odin.corp.sgi.com> jeffs@soul.esd.sgi.com (Jeff Smith) writes: > [text deleted --SJB] > >It's best to use good passwords. Some newer systems now split up the >password file information so you can't read the encripted password >without root authority. On some of our non-UNIX systems we use a security package that has another useful feature: after a certain number of bad passwords are given consecutively for a logonid, the logonid is suspended. No further access is allowed for that logonid until someone with authority to reactivate it has become involved. While this in itself offers an avenue for abuse, it pretty much closes the door on unauthorized use/access. Most users are further required to change their passwords at least once every {insert desired time period}. Users can set up or modify any access rules regarding their own files. If no explicit rule is currently defined when the system checks for one, the default is that the user has full access (i.e. read, write, allocate, execute) and nobody else gets anything. The entire data base used by the security system is accessible, but only by the systems programmers (i.e. us:-) or, conceivably, the computer operators with great bother, and the passwords are all encrypted anyway. In this particular case, our operators present no danger. We Know *and* We Watch anyway. :-) The security system also logs just about *everything*, e.g. file opens/closes, job start/end, disk space allocation/deallocation, access violations (including the logonid suspensions just described), logins/logouts, and, of course, anyone monkeying with the security system, so if we have to, we can follow an audit trail. While some versions of UNIX appear to support password expiration, and a few support limited versions of access control lists, UNIX in general doesn't. Most of these functions are missing from most versions of UNIX. Does anyone have experience with any of the third-party security packages for UNIX? Can you tell us what they offer that is missing in UNIX? > >jeffs Scott Bennett, Comm. ASMELG, CFIAG Systems Programming Northern Illinois University DeKalb, Illinois 60115 ********************************************************************** * Internet: bennett@cs.niu.edu * * BITNET: A01SJB1@NIU * *--------------------------------------------------------------------* * "Spent a little time on the mountain, Spent a little time on the * * Hill, The things that went down you don't understand, But I * * think in time you will." Oakland, 19 Feb. 1991, first time * * since 25 Sept. 1970!!! Yippee!!!! Wondering what's NeXT... :-) * **********************************************************************
fidelio@geech.gnu.ai.mit.edu (Rob J. Nauta) (04/24/91)
In article <26616@adm.brl.mil> poulin@polar.bowdoin.edu (Jeff Poulin) writes:
->I think as long as a password file is available for anyone to read, there
->will be some abuse. Sure, it's dumb to use a word in the dictionary as a
->password, but I've seen ridiculously complicated passwords here these past
->few days. No matter how confuscated your password may be, it still boils
->down to a guessing game between you and the cracker. You try to pick a
->combination the cracker is not likely to try, and he (or she) will try to
->outsmart you by choosing it.
->
->If you're really worried about kids getting into your account (an adult who
->tries to pick people's passwords is considered a child in my book), then
->write a password program for yourself and run it from .cshrc (or
->whatever). That way, even if someone breaks into your account, they
->still have another password to crack before they have access to your
->files. If the second password is incorrect, your password program simply logs
->you out. Since the file with the password encryption resides in your account,
->you don't have to worry that someone is cracking your password on some PC
->somewhere.
->
->Jeff
->
->
->Jeff Poulin poulin@polar.bowdoin.edu jpoulin@bowdoin.bitnet
Hi
What would stop someone who has your password, and noticed the custom
program kicks him out, to ftp to your account, examine .profile or .login,
and even remove/alter them, or the password program itself ?
Robsmb@ulysses.att.com (Steven Bellovin) (04/25/91)
In article <1991Apr24.004539.3881@mp.cs.niu.edu>, bennett@mp.cs.niu.edu (Scott Bennett) writes: } } On some of our non-UNIX systems we use a security package that has } another useful feature: after a certain number of bad passwords are } given consecutively for a logonid, the logonid is suspended. No } further access is allowed for that logonid until someone with authority } to reactivate it has become involved. While this in itself offers } an avenue for abuse Yup -- it's a great way to lock out the system administrators when you're ready to do some serious monkey business. Or you can lock out anyone else you don't like. This is known as a denial-of-service attack.
bennett@mp.cs.niu.edu (Scott Bennett) (04/25/91)
In article <14655@ulysses.att.com> smb@ulysses.att.com (Steven Bellovin) writes: >In article <1991Apr24.004539.3881@mp.cs.niu.edu>, bennett@mp.cs.niu.edu (Scott Bennett) writes: >} >} On some of our non-UNIX systems we use a security package that has >} another useful feature: after a certain number of bad passwords are >} given consecutively for a logonid, the logonid is suspended. No >} further access is allowed for that logonid until someone with authority >} to reactivate it has become involved. While this in itself offers >} an avenue for abuse > >Yup -- it's a great way to lock out the system administrators when >you're ready to do some serious monkey business. Or you can lock out >anyone else you don't like. This is known as a denial-of-service >attack. Of course. One cannot, it would seem, have it both ways. Therefore, one must choose the lesser of the evils. In our shop, we have taken the view that denial is better than unauthorized access because denial of access leaves everything intact, whereas that cannot be guaranteed in the case of unauthorized access. Lockout of systems programmers has not been a problem. Even if someone succeeded in doing that to all of the privileged logonids that our group uses, we would still have other ways to get back in, but those ways all require being in the computer room, which is a secured area. Also, if anything like that happened around here, there would probably be immediate involvement of law enforcement agencies and in the meantime no damage would have been done to data or programs. Scott Bennett, Comm. ASMELG, CFIAG Systems Programming Northern Illinois University DeKalb, Illinois 60115 ********************************************************************** * Internet: bennett@cs.niu.edu * * BITNET: A01SJB1@NIU * *--------------------------------------------------------------------* * "Spent a little time on the mountain, Spent a little time on the * * Hill, The things that went down you don't understand, But I * * think in time you will." Oakland, 19 Feb. 1991, first time * * since 25 Sept. 1970!!! Yippee!!!! Wondering what's NeXT... :-) * **********************************************************************
les@chinet.chi.il.us (Leslie Mikesell) (04/25/91)
>>} On some of our non-UNIX systems we use a security package that has >>} another useful feature: after a certain number of bad passwords are >>} given consecutively for a logonid, the logonid is suspended. >>Yup -- it's a great way to lock out the system administrators when >>you're ready to do some serious monkey business. I just had an umm... interesting... experience with password aging. This was on a spare 386 box that had been sitting around for a while without being turned on. When it started up, fsck complained a bit, then there were a few error messages from some of the rc files, but eventually a login prompt came up. I logged in as root and got the "password has expired, please choose a new one" prompt, but it didn't wait for me to enter anything before saying that it was changing root's password, and then it wouldn't let me log in. Then I repeated the sequence with the only other login that I know for the machine... It turned out that the machine had come up with something wrong with /dev/tty and the attempt to open /dev/tty to get the new password had failed, but the stupid program went ahead and accepted *something* from the failing read and installed it as the new password for root. Fun stuff, huh? I happened to have a boot floppy handy and this machine wasn't needed at the moment anyway, but it would not have been a nice way to start a day with a few dozen users screaming about having to get some work done. Les Mikesell les@chinet.chi.il.us
mitch@hq.af.mil (Mitch Wright) (04/25/91)
/* * On 25 Apr 91 00:03:23 GMT, * bennett@mp.cs.niu.edu (Scott Bennett) said: * */ Scott> another useful feature: after a certain number of bad passwords are Scott> given consecutively for a logonid, the logonid is suspended. No Scott> further access is allowed for that logonid until [...] Steve> Yup -- it's a great way to lock out the system administrators when Steve> you're ready to do some serious monkey business. Or you can lock out Steve> anyone else you don't like. This is known as a denial-of-service Steve> attack. Scott> [...] In our shop, we have taken the view that denial is better than Scott> unauthorized access because denial of access leaves everything intact, Scott> whereas that cannot be guaranteed in the case of unauthorized access. Scott> Lockout of systems programmers has not been a problem. It can *not* be guaranteed in *either* case. If I manage to break into your system and lock out everyone but the account I'm using, YOU are being denied service... not me. Scott> Even if someone succeeded in doing that to all of the privileged Scott> logonids that our group uses, we would still have other ways to get Scott> back in, but those ways all require being in the computer room, which Scott> is a secured area. Yeah, so. "rm -rf /" doesn't take much time to do sufficient damage. Not to even mention that you wouldn't be heading to the computer room until the intruder is detected. And what about the intruder that is on your system at 3am? -- ~mitch _______________________________________________________________________________ mitch@hq.af.mil (Mitch Wright) | The Pentagon, 1B1046 | (703) 695-0262 _______________________________________________________________________________
buck@sct60a.sunyct.edu (Jesse R. Buckley, Jr.) (04/26/91)
On Apr 24, 17:06, Steven Bellovin wrote: } Subject: Re: new password idea } In article <1991Apr24.004539.3881@mp.cs.niu.edu>, bennett@mp.cs.niu.edu (Scott Bennett) writes: } } } } On some of our non-UNIX systems we use a security package that has } } another useful feature: after a certain number of bad passwords are } } given consecutively for a logonid, the logonid is suspended. No } } further access is allowed for that logonid until someone with authority } } to reactivate it has become involved. While this in itself offers } } an avenue for abuse } } Yup -- it's a great way to lock out the system administrators when } you're ready to do some serious monkey business. Or you can lock out } anyone else you don't like. This is known as a denial-of-service } attack. }-- End of excerpt from Steven Bellovin I love this. Basically this is a way to show the 'brown shirts' that the fancy special accounting they have set up can be just as much of a problem to them as well... -- -Buck (buck@sct60a.sunyct.edu) "So this is a leap second?" -- Me at 6:59:60 pm on Mon Dec 31, 1990
jpe@egr.duke.edu (John P. Eisenmenger) (04/26/91)
In <26616@adm.brl.mil> poulin@polar.bowdoin.edu (Jeff Poulin) writes: >write a password program for yourself and run it from .cshrc (or I've always thought it would be nice if vendors made password checking a modular function. That is, something that an inventive individual could easily replace without OS source. Think about it -- password checking is the one piece of code you don't want everyone else to have... -John
gordon@sneaky.lonestar.org (Gordon Burditt) (04/26/91)
>If you're really worried about kids getting into your account (an adult who >tries to pick people's passwords is considered a child in my book), then >write a password program for yourself and run it from .cshrc (or >whatever). That way, even if someone breaks into your account, they This won't work. All the popular shells (csh, sh, ksh, tcsh) will *QUIT PROCESSING THE FILE* (whatever it's named: .cshrc, .login, .profile, etc.) and *GO INTO INTERACTIVE MODE* if they receive an interrupt character while they are processing the file. This weakness was also present in the old v7 restricted shell ("rsh", unrelated to the BSD remote-execution shell). This means that by pounding on the interrupt key, I can (eventually, it may not work every time) get a shell prompt without any of the file having been executed. It doesn't matter how many "trap" statements, invocations of "stty", or other such things there are in the file. The next thing the cracker probably does is delete the file. While there are ways of preventing a user from deleting files in his home directory, this will only annoy someone who has already successfully broken in. If you want to have secondary security, have the security program named in the shell field of the password file. The security program can demand all the passwords it wants, do challenge-response, try to time your keystrokes, etc. (Obviously this program needs its own database of users, passwords, encryption keys, preferred shell, etc., and this database probably should be both encrypted and kept secret. It also needs some commands to manipulate the database.) If you overwhelm it with interrupt characters and it hasn't ignored them, *YOU GET LOGGED OUT*. Most other things you can do: send a variety of signals, BREAK sequences, rapid fluctuations of carrier, cause the program to dump core with funny input, etc. will log you out. If you satisfy the program that you're the real user, the program sets up various environment variables suitably (if $SHELL is defined, it shouldn't point at /etc/challenge-response, but at /bin/csh, /bin/ksh, or whatever). It's even OK if a non-admin user wants to own and maintain his own security shell. The admin may have to bail out the user if the security shell ever gets deleted, corrupted, or a new version has bugs in it. If a cracker gets in, he can take over the account (of course, with or without a security shell, the cracker could just change the primary password). For both the useless "security-in-startup-file" scheme and the "security shell" scheme, you have to prevent the users from changing their shell. Disable 'chsh' or remove it. In the "security shell" approach, a command similar to chsh (and set-uid root: with all the requirements for care in coding that that implies) could let a user select which interactive shell they wanted, assuming they are authorized for an interactive shell (and not something limited like a menu system or uucico) at all. Access to the account by means other than through the specified login shell bypasses the secondary security. Worry about the 'su' command and remote access over a network. Gordon L. Burditt sneaky.lonestar.org!gordon
jfh@rpp386.cactus.org (John F Haugh II) (04/26/91)
In article <1414@cameron.egr.duke.edu> jpe@egr.duke.edu (John P. Eisenmenger) writes: > In <26616@adm.brl.mil> poulin@polar.bowdoin.edu (Jeff Poulin) writes: >>write a password program for yourself and run it from .cshrc (or > >I've always thought it would be nice if vendors made password checking >a modular function. AIX v3 does exactly this. You specify authentication methods, and the system executes the specified program with the user name as the argument. It allows you to add all manner of interesting checks or bizarre schemes, such as the obscure "two man rule" where two people on different terminals must simultaneously login using the same password before launching the missles ... -- John F. Haugh II | Distribution to | UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) | Domain: jfh@rpp386.cactus.org "If liberals interpreted the 2nd Amendment the same way they interpret the rest of the Constitution, gun ownership would be mandatory."
al@escom.com (Al Donaldson) (04/27/91)
>>} On some of our non-UNIX systems we use a security package that has >>} another useful feature: after a certain number of bad passwords are >>} given consecutively for a logonid, the logonid is suspended. Once when I was testing someone's operating system, I thought it would be interesting to find out what really happen when I exceeded the bad password count for root. So I just sat there at the console blindly typing random junk for the root password. After a small number of tries (less than 10), it made me root. What I think happened was that on this release a novice maintenance programmer made a bad decision and handled an error condition by starting a shell. ("Well, I don't know what ELSE to do, and he DID say he wanted to be root....") Insufficient testing, wrong people working on critical code, and too many damn bells and whistles. There is something to be said for simplicity in critical programs like login. Specially if the vendor doesn't have time to test every release extensively and document it completely (or release the code). Al It's 10pm. Do you know what your system does..?
martin@mwtech.UUCP (Martin Weitzel) (04/27/91)
In article <1991Apr24.004539.3881@mp.cs.niu.edu> bennett@mp.cs.niu.edu (Scott Bennett) writes: >In article <1991Apr23.182654.22452@odin.corp.sgi.com> jeffs@soul.esd.sgi.com (Jeff Smith) writes: > On some of our non-UNIX systems we use a security package that has >another useful feature: after a certain number of bad passwords are >given consecutively for a logonid, the logonid is suspended. Looks nice on first glance but needs refinements. Note that someone can deliberately lock out someone else from the system! Given some bad guy found by chance the password of someone else. What would you the bad guy do if he wants to be sure that this other person will not disturb him? Assume Joe Hacker has just exploitet some security hole in the system and now wants to be undisturbed from the administrator for some time? A better way to go is to establish a period of waiting between consecutive bad logins, that doubles with every attempt. (After the first bad atempt you have to wait 1 second, after the second bad attempt 2 seconds, etc. This not only amounts to about 20 minutes after ten bad attempts, it also means that you need this long for 10 consecutive (bad) attempts. >Most users are further required to change their passwords >at least once every {insert desired time period}. Who will more likely pick a "good" (ie. hard to guess) password? The user who can think a little about it or the user who is forced at login time to select a new password because the old one just expired. Consider that said user may be in a hurry this particular day ... >Users can set up or >modify any access rules regarding their own files. If no explicit rule >is currently defined when the system checks for one, the default is that >the user has full access (i.e. read, write, allocate, execute) and >nobody else gets anything. Can you edit your .profile to contain a line: `umask 077' ? >The entire data base used by the security >system is accessible, but only by the systems programmers (i.e. us:-) >or, conceivably, the computer operators with great bother, and the >passwords are all encrypted anyway. Yeah, yeah we heard all this allready: Know that everybody who has the ability to install system programs can break any security barrier. BTW: Did you know that even `crypt(3)'ed files are not 100% protected from beeing read by the superuser (clear-text, I imply here)? Maybe the superuser changed the installed crypt-command a little so that it mails the clear-text of anything that is run through crypt to him or her! Many systems simlply `appear' to be secure because people do not have enough phantasy! Have I told you about that little board, maybe 2 by 2 inches sized and with a little electronic circuitry on it? That board finds easily some space in nearly any terminal and it takes not more than a few minutes to install it there and tap pins 2 and 3 of the famous RS 232 connector. Whenever it watches the strings "login:" and "password:" flow in, it stores the next few characters that flow out in some non- volatile memory. To remove this board from the terminal some weeks later also takes only a few minutes ... (and if you have a sufficiently intelligent terminal with it's own builtin microprocessor and little more NV-RAM than needed to keep the terminal's setup: Simply plant some new firmware into it, walk over there in the evening and, after entering you own special key combination, the terminal will nicely display all the passwords of the dayly users. To put it in other words: I know that many companies feel uncomfortable if there is not a number nifty-super-security-features built into their software. But do the same companies care to watch those people who clean their office in the evening? ("Why care - of course our computer is shut down during this hours and of course the room were the CPU is located is locked and not entered by the cleaning people ...") -- Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83
gwyn@smoke.brl.mil (Doug Gwyn) (04/27/91)
In article <1991Apr26.171549.10502@escom.com>, al@escom.com (Al Donaldson) writes: > After a small number of tries (less than 10), it made me root. Then there was the (Sixth Edition?) bug which would allow one to log in as the superuser merely by typing 100 zeroes at the password prompt. (Lack of a buffer overflow check.) I must by now have seen around a hundred distinct security loopholes in various UNIX implementations. I don't conclude that UNIX has more problems in this regard than do other operating systems, however; I have much more experience with UNIX security, and whenever I've looked for ways to break into other operating systems I've found them. I don't know what the solution to this category of problem is. None of the proposed security methodologies strikes me as quite right..
bennett@mp.cs.niu.edu (Scott Bennett) (04/27/91)
In article <1991Apr26.171549.10502@escom.com> al@escom.com (Al Donaldson) writes: >Once when I was testing someone's operating system, I thought it >would be interesting to find out what really happen when I exceeded >the bad password count for root. So I just sat there at the console >blindly typing random junk for the root password. After a small >number of tries (less than 10), it made me root. > > [text deleted --SJB] > >Insufficient testing, wrong people working on critical code, and >too many damn bells and whistles. There is something to be said >for simplicity in critical programs like login. Specially if >the vendor doesn't have time to test every release extensively >and document it completely (or release the code). This is hard to argue with, but really doesn't address the issue. The existence of broken and/or poorly designed software doesn't have much to do with the need for security. In other words, having a broken ratchet on your socket wrench doesn't mean you should try to make do with a pair of pliers. It means you should get a different socket wrench. > >Al > Scott Bennett, Comm. ASMELG, CFIAG Systems Programming Northern Illinois University DeKalb, Illinois 60115 ********************************************************************** * Internet: bennett@cs.niu.edu * * BITNET: A01SJB1@NIU * *--------------------------------------------------------------------* * "Spent a little time on the mountain, Spent a little time on the * * Hill, The things that went down you don't understand, But I * * think in time you will." Oakland, 19 Feb. 1991, first time * * since 25 Sept. 1970!!! Yippee!!!! Wondering what's NeXT... :-) * **********************************************************************
mike@BRL.MIL ( Mike Muuss) (04/27/91)
The term for this is "denial of service". It can be a serious threat, if your users actually have important work to do. First, if a particular user (say, the department chairman) was getting beaten upon by a hacker regularly (say, every other day), I think the bother of having to get the account reactivated would upset that user. Second, on the assumption that you support "remote" users (e.g. another campus), you are then (with the most secure policy) faced with needing a "secure channel" to verify their identity before reactivating the account, and (with the simplest policy) simply going to turn that account on again for another bout. The action of the law enforcement community might resolve your problem, but it could take months to work through it with them. On the several cases I've been involved with, the time units are YEARS. "Computer security should be strong enough to repell virtually any attack ***from the outside***, yet unobtrusive enough that the average user is unaware that he is being guarded by a strong defense." Best, - Mike Muuss