wreck@fmsrl7.UUCP (Ron Carter) (06/24/91)
In article <1991Jun24.041435.5423@athena.cs.uga.edu> mcovingt@athena.cs.uga.edu (Michael A. Covington) writes: >This is getting ridiculous. Our policy is that students are *not* allowed >to obtain passwords without the consent of the password owner, by any means >whatever. Can't you draw a distinction between: a.) Obtaining another user's password, and b.) Seeing if certain security-critical passwords are obtainable by dictionary search? The first is definitely a problem if done other than accidentally, the second is essential to the user knowing if their usage of the system is likely to be disrupted or not. It is arguable that if #1 is accomplished accidentally as part of determining #2, that it is not a harmful act. It is certainly not malicious. Why don't you just run COPS yourself every so often, and have it send mail to the users whose passwords are easily broken? You won't have to worry about crackers using dictionary searches on your system ever again.
kdenning@genesis.Naitc.Com (Karl Denninger) (06/25/91)
In article <44260@fmsrl7.UUCP> wreck@fmsrl7.UUCP (Ron Carter) writes: >In article <1991Jun24.041435.5423@athena.cs.uga.edu> mcovingt@athena.cs.uga.edu (Michael A. Covington) writes: >>This is getting ridiculous. Our policy is that students are *not* allowed >>to obtain passwords without the consent of the password owner, by any means >>whatever. Note, however, that COPS does NOT give you the "guessed" password. It only tells you that the password was easily compromised, not WHAT it is. Therefore, it would be OK for me to run COPS on your systems. But you have said that it isn't. Why? -- Karl Denninger - AC Nielsen, Bannockburn IL (708) 317-3285 kdenning@nis.naitc.com "The most dangerous command on any computer is the carriage return." Disclaimer: The opinions here are solely mine and may or may not reflect those of the company.
df@sei.cmu.edu (Dan Farmer) (06/25/91)
In article <foo>, kdenning@genesis.Naitc.Com (Karl Denninger) writes: > Note, however, that COPS does NOT give you the "guessed" password. It only > tells you that the password was easily compromised, not WHAT it is. Just a note from the source code/man page: -p: print the password when guessed In any case, even if this wasn't there, it'd be trivial to put in. -- d
gl8f@astsun9.astro.Virginia.EDU (Greg Lindahl) (06/25/91)
In article <44260@fmsrl7.UUCP> wreck@fmsrl7.UUCP (Ron Carter) writes: >Why don't you just run COPS yourself every so often, and have it >send mail to the users whose passwords are easily broken? You >won't have to worry about crackers using dictionary searches on >your system ever again. I should note in passing that if you have a small enough set of users, it's probably better to contact them personally and give them a lecture on how to pick a good password. Novice users are often confused by email, and a cracker will get a laugh out of such a notice, but a phone call is hard to ignore and will often tell you whether or not the account has been broken into. "Gee, I haven't logged in in the past week..."
craig@b11.ingr.com (Craig Presson) (06/25/91)
In article <1991Jun24.173743.11003@Firewall.Nielsen.Com>, kdenning@genesis.Naitc.Com (Karl Denninger) writes: |> In article <44260@fmsrl7.UUCP> wreck@fmsrl7.UUCP (Ron Carter) writes: |> >In article <1991Jun24.041435.5423@athena.cs.uga.edu> mcovingt@athena.cs.uga.edu (Michael A. Covington) writes: |> >>This is getting ridiculous. Our policy is that students are *not* allowed |> >>to obtain passwords without the consent of the password owner, by any means |> >>whatever. |> |> Note, however, that COPS does NOT give you the "guessed" password. It only |> tells you that the password was easily compromised, not WHAT it is. |> |> Therefore, it would be OK for me to run COPS on your systems. But you have |> said that it isn't. Why? |> |> -- |> Karl Denninger - AC Nielsen, Bannockburn IL (708) 317-3285 |> kdenning@nis.naitc.com |> |> "The most dangerous command on any computer is the carriage return." |> Disclaimer: The opinions here are solely mine and may or may not reflect |> those of the company. Below is the header from the relevant source file (this is not from the most current COPS), the last line: * -p: print the password when guessed tells a story. One can't condemn the authors for this, since it would be easy to modify the program to do it, or just run it under an interactive debugger (after all, a good one can execute a "macro" at a conditional breakpoint, which accomplishes the same thing without source). In principle, with more trouble, one could do the same thing to a stripped executable. In any case, it seems we must assume the curious/careful user under discussion has brought his own password guesser. Why would he trust yours if he's trying to audit your system for security? [Intergraph hat on] I don't know what the final answer is here, but Intergraph and many other vendors distribute COPS (possibly adapted and augmented for the environment) and encourage sysdamins to run it. We have it embedded in our Distributed System Manager (DSM) which expects to be run by uid 0, so by implication we are not encouraging non-privileged users to run it. My own opinion [Intergraph hat off] is that sysadmins would do well to run COPS, or their favorite equivalent, periodically and post a summary (full output may contain sensitive stuff!) for all users to read, making it clear that security auditing is an administrative function. I'm thinking mainly of production and commercial sites here -- a system that serves, say, CS researchers, might expect less of its admin. quote from COPS src (pass.c): /* * Warning: this program burns a lot of cpu. */ Many thanks for the refreshing honesty :-) /* * Insecure - find accounts with poor passwords Date: Tue, 29 Nov 83 18:19:32 pst From: leres%ucbarpa@Berkeley (Craig Leres) Modified by Seth Alford, Roger Southwick, Steve Dum, and Rick Lindsley for Tektronix */ /* [source control noise ...] * * * By default, this program only checks for accounts with passwords the same * as the login name. The following options add more extensive checking. (The * tradeoff is cpu time -- with all options enabled it can run into the 100's * of MINUTES.) Any argument that does not begin with a "-" is assumed to be * a file name. (A single '-' means stdin.) If no file name is given, * /etc/passwd is used. * * Options: * * -v: verbose -- list all guesses on stdout * -u: output the username on the line of the password file * currently being checked. If the program stops * abruptly you will then know how far it got. * -w file: use the list of words contained in "file" as likely * passwords. Words in the file are one to a line. * -b: check all guesses backwards too * -g: use the Full Name portion of the gecos field to * generate more guesses * -s: check the single letters a-z, A-Z, 0-9 as passwords * -c: with each guess, check for all-lowercase and * all-uppercase versions too. * -n: complain about null passwords (default is to keep quiet) * -p: print the password when guessed */ -- ****************************************************** ** Craig Presson pressonc@ingr.com ** ** Intergraph Corporation MS CR1104 ** ** Huntsville, AL 35894-0001 (205) 730-6176 ** ** FAX: (205) 730-6011 ** ******************************************************
john@csrnxt1.ae.utexas.edu (John R. Schutz) (06/25/91)
kdenning@genesis.Naitc.Com (Karl Denninger) writes: >Note, however, that COPS does NOT give you the "guessed" password. It only >tells you that the password was easily compromised, not WHAT it is. Arg arg, me matey. That is incorrect. See the -p option of pass.c. Did you not take time to read the source? Even if it wasn't there, it would not be hard to add. So a user would just have to install their own version of the password checker. For the record though, I am for users being able to run COPS. john -- | John R. Schutz | Email&NeXTmail: | | A learning NeXTie | john@csrnxt1.ae.utexas.edu | | (512)328-0587 | The 23rd periodic element is Vanadium | | 3009 Hatley Dr., Austin, TX 78746 | 'V'. V is roman numeral for 5. Hmmm |
mcovingt@athena.cs.uga.edu (Michael A. Covington) (06/26/91)
In article <1991Jun25.132820.9303@athena.toronto.edu> dwivian@uga.edu (Dwivian Unterschreiber) writes: >And, I have a question: Not long ago I was informed that the transmission >of knowledge that would allow a person to break into a computer system was a >felony. No. Only when the person's actual intent is to assist in a break-in. What matters is not so much the nature of the knowledge, as the intent of the act. In law this is called "mens rea". I notice a pattern here. A lot of defective legal reasoning is seen on this newsgroup, and the defect is almost always that people think only in terms of technology and mechanical acts, not about intent. From the viewpoint of the law, intent is very, very important. One can become an accessory to a felony by such simple things as holding a door open for somebody, if the intent is thereby to cooperate with a crime in progress. This does not mean there is a law against holding doors open! -- ------------------------------------------------------- Michael A. Covington | Artificial Intelligence Programs The University of Georgia | Athens, GA 30602 U.S.A. -------------------------------------------------------
learn@ddsw1.MCS.COM (William Vajk) (06/28/91)
In article <1991Jun24.041435.5423@athena.cs.uga.edu> Michael Covington writes: >In article <231749.25498@murdoch.acc.Virginia.EDU> Greg Lindahl writes: >>In article <234109.25051@athena.cs.uga.edu> Michael A. Covington writes: >>>a sysadmin cannot investigate "intent" every time an alarm goes off. >>Especially when your idea of an alarm is: OH MY GOD! THEY'RE RUNNING COPS! >>I have yet to have an alarm go off, because I've tested the security >>of my system and I'm not paranoid. >This is getting ridiculous. Our policy is that students are *not* allowed >to obtain passwords without the consent of the password owner, by any means >whatever. Of course it is getting ridiculous. You have policies for everything besides choice in passwords ? If the system administrator does his job and runs cops, or more advanced renditions of the theme, then the problem is no longer a problem. If the system administrator installs the shadow password software, then the problem no longer exists at all. Greg runs password checkers himself on system(s) he administers. I do too. Then it no longer matters whether the student runs cops or similar software. It seems as though you're willing to stand there and defend that /etc/passwd file with a pick handle (shades of Lester Maddox, dontcha know) instead of closing that hole as a prudent man would do. Bill Vajk
learn@ddsw1.MCS.COM (William Vajk) (06/28/91)
In article <44260@fmsrl7.UUCP> wreck@fmsrl7.UUCP (Ron Carter) writes: >Why don't you just run COPS yourself every so often, and have it >send mail to the users whose passwords are easily broken? You >won't have to worry about crackers using dictionary searches on >your system ever again. Better yet, run a password checker more frequently and simply expire anyone's password which is too easily guessed. It won't take too many times to gently train them to use more discretion. Bill Vajk
karl@ddsw1.MCS.COM (Karl Denninger) (06/28/91)
In article <1991Jun28.033536.10048@ddsw1.MCS.COM> learn@ddsw1.MCS.COM (William Vajk) writes: > >If the system administrator does his job and runs cops, or more advanced >renditions of the theme, then the problem is no longer a problem. Correct. You'll find COPS is not only online here, but in the local binary area where ANYONE can run it -- and be quite sure how secure the system is (hint: I'm good! You ain't getting in via any of the COPS-detected paths) >If the system administrator installs the shadow password software, then >the problem no longer exists at all. True as well. Anyone running WITHOUT shadow passwords these days deserves whatever they get (flames on this to /dev/null, there ARE PD login programs out there for those without source, most of which support shadow passwords). If you were at the Winter Usenix you would have heard the speech about easily-built hardware ($2k or so) that could guess a password in something like a few hours. That makes the ONLY defense against this kind of hackery hiding the file where people can't read it! >It seems as though you're willing to stand there and defend that /etc/passwd >file with a pick handle (shades of Lester Maddox, dontcha know) instead of >closing that hole as a prudent man would do. Of course! To close the hole would require that the admin do his or her job! What a concept -- doing one's job. -- Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) Public Access Data Line: [+1 708 808-7300], Voice: [+1 708 808-7200] Anon. arch. (nuucp) 00:00-06:00 C[SD]T, req: /u/public/sources/DIRECTORY/README
lemson@ux1.cso.uiuc.edu (David Lemson) (06/30/91)
kdenning@genesis.Naitc.Com (Karl Denninger) writes: >Note, however, that COPS does NOT give you the "guessed" password. It only >tells you that the password was easily compromised, not WHAT it is. >Therefore, it would be OK for me to run COPS on your systems. But you have >said that it isn't. Why? >-- >Karl Denninger - AC Nielsen, Bannockburn IL (708) 317-3285 >kdenning@nis.naitc.com Maybe the passwd.chk script is set up that way, but the program that comes in ~cops/src/pass.c that guesses passwords will display the found password with the appropriate command line switch. So it will display the found password. -- David Lemson University of Illinois Computing Services Consultant Internet : lemson@uiuc.edu UUCP :...!uiucuxc!uiucux1!lemson