dankg@tornado.Berkeley.EDU (Dan KoGai) (05/28/90)
In article <9000030@m.cs.uiuc.edu> carroll@m.cs.uiuc.edu writes: >---Begin copy--- > Don't you hate it when you leave your password in a .netrc in > a directory of stuff you ftp'ed over from the web. I sure do. > Then anyone can just get your password and delete all of your > files in both accounts. Bummer. >/* End of text from m.cs.uiuc.edu:comp.unix.questions */ >Perhaps I'm missing something, but it doesn't sound like security >violation. I assume that you have a .netrc file with your password >in it. Does FTP check for .netrc specially? If not, then this seems to >claim that you ftp'd the .netrc and it was that copy that was used, >not your 600 .netrc. It might be system dependent but ALL ftp I know refuses to use .netrc with wrong mode. And my Apollo account was not an exception. As soon that message appeared I retested ftp and it refused to use .netrc with group|other bit was set. You can check it out just by chmod-ing your .netrc and see how ftp would work. So in this respect, ftp is very well made--it even tells you your unlocked door. But that Bozo knew another door and .netrc was used just for another account and it's fair assumption my OCF account (this one), at very least is still in danger--things suggest that he at least had capability of anihilating my OCF account and .netrc made situation worse. And he started with screwing around my ocf account, found my .netrc and read it, rlogin/ftp'd to my another account, deleted it and deleted the rest of ocf. So the absense of my password in .netrc could prevent my another account from being anihilated but still this OCF account is still in danger. And this applies to other UNIX and other accounts, too. ---------------- ____ __ __ + Dan The "raped" Man ||__||__| + E-mail: dankg@ocf.berkeley.edu ____| ______ + Voice: +1 415-549-6111 | |__|__| + USnail: 1730 Laloma Berkeley, CA 94709 U.S.A |___ |__|__| + |____|____ + "What's the biggest U.S. export to Japan?" \_| | + "Bullshit. It makes the best fertilizer for their rice"
dce@smsc.sony.com (David Elliott) (05/28/90)
In article <1990May28.102235.10021@agate.berkeley.edu> dankg@ocf.Berkeley.EDU (Dan Kogai) writes: >In article <9000030@m.cs.uiuc.edu> carroll@m.cs.uiuc.edu writes: >>in it. Does FTP check for .netrc specially? If not, then this seems to >>claim that you ftp'd the .netrc and it was that copy that was used, >>not your 600 .netrc. > > It might be system dependent but ALL ftp I know refuses to use >.netrc with wrong mode. Hold on, Dan. I think that carrol@m.cs.uiuc.edu is asking "when going a get or a put, does ftp check for .netrc specially". That is, is it possible that you did a get/put of everything in a directory, and that your .netrc got copied to a new place without being protected? This is what the note you found implied to me as well -- that the "rapist" found a file called .netrc that wasn't mode 0600, and got your password from that file. -- David Elliott dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce (408)944-4073 "If I had a hat the size of Oklahoma, I'd be a happy person."
samlb@pioneer.arc.nasa.gov (Sam Bassett RCS) (05/29/90)
Moral of the story: Don't put passwords in your .netrc, dum-dum. (Or anywhere that *anybody* can read 'em -- even you!) (Don't assume it's the sysop, either -- assume that UNIX is *NOT* secure until it is proven otherwise.) Note that I am not condoning snooping and poking by System Administrators -- that is impolite, among other things. I _AM_ taking this kid to task for wasting net bandwidth with anguished (and over-wordy) cries of outrage about something that his teachers should have pointed out to him in his first semester. UNIX was not designed to be secure. It was designed (sic) to make programming and file-handling convenient. If you want something to be secure, either learn something about encryption or *KEEP IT OFF-LINE* Sam'l Bassett, Sterling Software @ NASA Ames Research Center, Moffett Field CA 94035 Work: (415) 604-4792; Home: (415) 969-2644 samlb@well.sf.ca.us samlb@ames.arc.nasa.gov <Disclaimer> := 'Sterling doesn't _have_ opinions -- much less NASA!'
dce@smsc.sony.com (David Elliott) (05/29/90)
In article <6365@amelia.nas.nasa.gov> samlb@pioneer.arc.nasa.gov.UUCP (Sam Bassett RCS) writes: > > Moral of the story: > > Don't put passwords in your .netrc, dum-dum. (Or anywhere that >*anybody* can read 'em -- even you!) (Don't assume it's the sysop, >either -- assume that UNIX is *NOT* secure until it is proven otherwise.) I think that the problem here, Sam, is that the .netrc file is "an attractive nuisance". Not only does the .netrc file give you a place to put a password, the documentation tells you that this feature won't be used if the file is readable by others. In essence, it is saying "it's safe to put passwords here". So, while I agree with most of your moral, I disagree with the "dum-dum". Anyone can be lulled into a false sense of security with the way passwords, permissions, and so forth are documented. -- David Elliott dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce (408)944-4073 "If I had a hat the size of Oklahoma, I'd be a happy person."
samlb@pioneer.arc.nasa.gov (Sam Bassett RCS) (05/29/90)
I agree -- the documentation should be more straightforward about the dangers of the .netrc, and for d**n sure, whoever is teaching kids about UNIX should point out the problem -- especially at Berkeley. I retract the "dum-dum" . . . . Sam'l Bassett, Sterling Software @ NASA Ames Research Center, Moffett Field CA 94035 Work: (415) 604-4792; Home: (415) 969-2644 samlb@well.sf.ca.us samlb@ames.arc.nasa.gov <Disclaimer> := 'Sterling doesn't _have_ opinions -- much less NASA!'
lauther@janus.Berkeley.EDU (Ulrich Lauther) (05/29/90)
In article <6368@amelia.nas.nasa.gov> samlb@pioneer.arc.nasa.gov.UUCP (Sam Bassett RCS) writes: > > I agree -- the documentation should be more straightforward about >the dangers of the .netrc, and for d**n sure, whoever is teaching kids I just wonder why not the same technique is used with .netrc as with /etc/passwd: have the file readable, but sensitive parts encrypted? -ulrich ----------------------------------------------------------------- Ulrich Lauther Internet: lauther@janus.berkeley.edu Siemens / UCB ph: +1 415 642 3338 fax: 642 2739
jik@athena.mit.edu (Jonathan I. Kamens) (05/29/90)
In article <36584@ucbvax.BERKELEY.EDU>, lauther@janus.Berkeley.EDU (Ulrich Lauther) writes: |> I just wonder why not the same technique is used with .netrc as with |> /etc/passwd: have the file readable, but sensitive parts encrypted? Because this makes the .netrc file useless for its intended purpose. The .netrc file is meant to save you the effort of typing your password when you ftp to another host, or to allow you to use ftp in a shell script without you there to watch it. At some point, ftp has to be able to send your password in cleartext over the network to the other host (that, in itself, is of course a security hole, but what the hell, it isn't *too* painful to assume that your network is secure :-). An encrypted password simply isn't good enough. If the password in the .netrc file is encrypted with a one-way encryption function, then there is no way to get the cleartext password from the encrypted password string, so it's useless. If it's encrypted with a two-way function for which you provide the key when you do the encryption, then it's still useless for unattended operation, since you have to be there to type the encryption key to get it back. If it's encrypted with a two-way function with the key somewhere on-line, you haven't gained anything, because anybody who can read your protected .netrc can probably also read whereever the key is stored (i.e. you've just introduced another layer of indirection without introducing any added security). In comparison to the .netrc file, the reason that encrypting the sensitive data in the /etc/passwd file works is that the OS never needs to know your cleartext password, except when it prompts you for it (and promptly does a crypt() on it and then throws the cleartext away). Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8495 Home: 617-782-0710
montnaro@spyder.crd.ge.com (Skip Montanaro) (05/29/90)
In article <1990May29.022854.22733@smsc.sony.com> dce@smsc.sony.com (David Elliott) writes:
I think that the problem here, Sam, is that the .netrc file is "an
attractive nuisance". Not only does the .netrc file give you a place
to put a password, the documentation tells you that this feature won't
be used if the file is readable by others. In essence, it is saying
"it's safe to put passwords here".
Shouldn't the ftp daemon on the receiving end set the file permissions
pessimistically? On Suns at least, the mode on the receiving end is 666.
(Ultrix appears to set the mode to 644, which for the current discussion is
no better than 666.) If the modes are going to be mangled, I'd rather they
were mangled to 600. The case of ~/.netrc is just one problem. As another
example, mail files often contain sensitive information (like passwords :-).
Having them created mode 666 can be just as damaging.
--
Skip (montanaro@crdgw1.ge.com)ram@attcan.UUCP (Richard Meesters) (05/30/90)
In article <1990May29.124526.13935@athena.mit.edu>, jik@athena.mit.edu (Jonathan I. Kamens) writes: > In article <36584@ucbvax.BERKELEY.EDU>, lauther@janus.Berkeley.EDU > (Ulrich Lauther) writes: > |> I just wonder why not the same technique is used with .netrc as with > |> /etc/passwd: have the file readable, but sensitive parts encrypted? > > Because this makes the .netrc file useless for its intended purpose. > > The .netrc file is meant to save you the effort of typing your > password when you ftp to another host, or to allow you to use ftp in a > shell script without you there to watch it. > > At some point, ftp has to be able to send your password in cleartext > over the network to the other host (that, in itself, is of course a > security hole, but what the hell, it isn't *too* painful to assume that > your network is secure :-). An encrypted password simply isn't good enough. The point is, however valid. If you are going to use a .netrc, why cant it be more like the passwd system. This merely means that the ftp program must provide the facilities for encryption/decription of the password, rather than leaving it up to the user to do so himself. Using a .netrc, or any type of script to save the effort of typing in a password when going between systems is not only lazy but stupid. The idea of a password is, after all to provide a measure of security to your data, and the system. Automating the process negates any good effect this might have. One other point. I'm not too sure, but since Dan was burned twice, is it true then that he must have had the same password combination used for several different machines (or at least two). Couldn't the damage have been minimalized by having different .netrc/passwords for each machine? Regards, ------------------------------------------------------------------------------ Richard A Meesters | Technical Support Specialist | Insert std.logo here AT&T Canada | | "Waste is a terrible thing ATTMAIL: ....attmail!rmeesters | to mind...clean up your act" UUCP: ...att!attcan!ram | ------------------------------------------------------------------------------
karish@mindcrf.UUCP (05/30/90)
In article <MONTNARO.90May29111606@spyder.crd.ge.com> montanaro@crdgw1.ge.com (Skip Montanaro) writes: >Shouldn't the ftp daemon on the receiving end set the file permissions >pessimistically? On Suns at least, the mode on the receiving end is 666. >(Ultrix appears to set the mode to 644, which for the current discussion is >no better than 666.) If the modes are going to be mangled, I'd rather they >were mangled to 600. The case of ~/.netrc is just one problem. As another >example, mail files often contain sensitive information (like passwords :-). >Having them created mode 666 can be just as damaging. The receiving-end ftp daemon should set file access modes using the system's default umask. If a file contains sensitive data, it should be restored into a directory with secure access modes and kept there until the file's access modes can be corrected. This is all under the control of the user. If you want a more user-friendly utility for this purpose, use 'rcp', which preserves modes. -- Chuck Karish karish@mindcraft.com Mindcraft, Inc. (415) 323-9000
defaria@hpclapd.HP.COM (Andy DeFaria) (05/30/90)
>/ hpclapd:comp.unix.questions / jik@athena.mit.edu (Jonathan I. Kamens) / 5:45 am May 29, 1990 / > At some point, ftp has to be able to send your password in cleartext >over the network to the other host (that, in itself, is of course a >security hole, but what the hell, it isn't *too* painful to assume that >your network is secure :-). An encrypted password simply isn't good enough. I'm no security guru on Unix but it seems to me that the way around this problem would be to remove this silly restriction and allow ftp (and others?) to send encrypted passwords to the other host.
jik@athena.mit.edu (Jonathan I. Kamens) (06/01/90)
In article <11513@vpk1.UUCP>, ram@attcan.UUCP (Richard Meesters) writes: |> The point is, however valid. If you are going to use a .netrc, why cant it be |> more like the passwd system. This merely means that the ftp program must |> provide the facilities for encryption/decription of the password, rather than |> leaving it up to the user to do so himself. First of all, the ftp protocol doesn't say, "Two machines talking to each other using the protocol must both be Unix machines that use a standard crypt() function for password verification." What it says is that there is a protocol command to send a password from the client to the server, and that server may use the password for verification in whatever way it chooses. Therefore, the ftp program can't "provide the facilities for encryption/decription [sic] of the password", because it has no idea what type of encryption the server at the other end is going to be expecting. Second, if the client is supposed to do password encryption, then what's to stop me from logging into your machine, grabbing your encrypted password string from the /etc/passwd file, then ftp'ing back to the same machine with a hacked ftp client which sends that encrypted string as the password? The ftp server says, "Gee, look, you've sent me the correct encrypted password!" and goes right ahead believing that I'm you. The security of the ftp password (well, at least, in the case of ftp servers on Unix machines) works the same way as the security for a normal Unix log-in password -- you give it a plaintext password, it encrypts it, and if the encrypted string matches the string in the passwd file, it assumes that you are who you say you are, since you've provided a string that encrypts correctly. Providing an already encrypted string proves nothing. If I've misunderstood what you're suggesting, then please forgive me, and please explain more clearly what you're suggesting. If not, I think you've got to think through a bit more clearly exactly how ftp authentication, and Unix password authentication in general, works. Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8495 Home: 617-782-0710 (Isn't it about time somebody wrote a Kerberized ftp client/server? :-)
ram@attcan.UUCP (Richard Meesters) (06/01/90)
In article <1990Jun1.063800.17539@athena.mit.edu>, jik@athena.mit.edu (Jonathan I. Kamens) writes: > In article <11513@vpk1.UUCP>, ram@attcan.UUCP (Richard Meesters) writes: rm |> The point is, however valid. If you are going to use a .netrc, why rm cant it be rm |> more like the passwd system. This merely means that the ftp program must rm |> provide the facilities for encryption/decription of the password, rm rather than rm |> leaving it up to the user to do so himself. > > First of all, the ftp protocol doesn't say, "Two machines talking to > each other using the protocol must both be Unix machines that use a > standard crypt() function for password verification." What it says is > that there is a protocol command to send a password from the client to > the server, and that server may use the password for verification in > whatever way it chooses. I'm not suggesting that we necessarily use the crypt() function call ala UNIX to provide the data encryption. What I'm suggesting is that perhaps the ftp code should include some form of encryption/decryption algorithm to protect the password information. IMHO, any plain-text password stored on a system is a security risk, no matter how well it is protected. > > Second, if the client is supposed to do password encryption, then > what's to stop me from logging into your machine, grabbing your > encrypted password string from the /etc/passwd file, then ftp'ing back > to the same machine with a hacked ftp client which sends that encrypted > string as the password? The ftp server says, "Gee, look, you've sent me > the correct encrypted password!" and goes right ahead believing that I'm you. Again, see above. It doesn't have to be the same encryption algorithm that is used for /etc/passwd (or use the same key?). So the password in /etc/passwd does not necessarily have any bearing on the passwd in .netrc. The danger of a plain-text passwd in a file is that someone only has to SEE it, rather than necessarily decrypt it to be able to use it. > > If I've misunderstood what you're suggesting, then please forgive me, > and please explain more clearly what you're suggesting. If not, I think > you've got to think through a bit more clearly exactly how ftp > authentication, and Unix password authentication in general, works. > Like I said in my previous posting, I'm by no means an expert on the topic, but rather just kicking around ideas. I appreciate your input. Regards, ------------------------------------------------------------------------------ Richard A Meesters | Technical Support Specialist | Insert std.logo here AT&T Canada | | "Waste is a terrible thing ATTMAIL: ....attmail!rmeesters | to mind...clean up your act" UUCP: ...att!attcan!ram | ------------------------------------------------------------------------------
dankg@tornado.Berkeley.EDU (Dan KoGai) (06/04/90)
In article <36584@ucbvax.BERKELEY.EDU> lauther@janus.Berkeley.EDU.UUCP (Ulrich Lauther) writes: >In article <6368@amelia.nas.nasa.gov> samlb@pioneer.arc.nasa.gov.UUCP (Sam Bassett RCS) writes: >> >> I agree -- the documentation should be more straightforward about >>the dangers of the .netrc, and for d**n sure, whoever is teaching kids > >I just wonder why not the same technique is used with .netrc as with >/etc/passwd: have the file readable, but sensitive parts encrypted? I don't think so: I don't think /etc/passwd was a good idea: It's encrypted. So what? That means you can take time to feed random string to encryptor, which is available, then find the matching string. Maybe you can feed it from dict file--people's name makes big candidate for considerably many people choose their password from thier (boy|girl)friends' or spouses' names. What I don't understand is that my password is not a kind of string found on dict but it's still feasible to use "power" rather than "tech" to break secirity in UNIX. I admit my .netrc was not a good idea. But still I think it's possible for that moron to kill at least OCF account: Some others suggested that some of UNIX has a serious problem in user switching. One of my friends witnessed that he was accidentally su'd to somebody else. At very least finger info and passwd file must be saparated. If possible, it might be a good idea to hard-code secirity part of UNIX, that is, implement seciryty by hardware than software. On current system encrypted or not, precious password info is visible. How about ATM card way (I don't think it's valid idea--How about dialin?)--No one but card knows your password. there remains the problem in case of loss of cards or "keys" but it's at very least far more secure than current UNIX implementation of password. ---------------- ____ __ __ + Dan The "Raped" Man ||__||__| + E-mail: dankg@ocf.berkeley.edu ____| ______ + Voice: +1 415-549-6111 | |__|__| + USnail: 1730 Laloma Berkeley, CA 94709 U.S.A |___ |__|__| + |____|____ + "What's the biggest U.S. export to Japan?" \_| | + "Bullshit. It makes the best fertilizer for their rice"
boyd@necisa.ho.necisa.oz (Boyd Roberts) (06/05/90)
In article <1990Jun4.102422.12896@agate.berkeley.edu> dankg@tornado.Berkeley.EDU (Dan KoGai) writes: > > I don't think so: I don't think /etc/passwd was a good idea: It's >encrypted. So what? That means you can take time to feed random string to >encryptor, which is available, then find the matching string. > Dan, my man you seem to have jumped to the conclusion that UNIX isn't secure because someone broke into your account and blew away your files. How this was done would appear to be attributable to stupidity, and not to underlying flaws in UNIX password security. At this point I'd like to make the distinction between UNIX password security and the various `security' of IP based networking utilities. With those, there is _no_ security. I think RTM and various others have proved this beyond a shadow of a doubt. UNIX password security is secure, provided you have chosen a reasonable password. Sure, you can snarf /etc/passwd and try a dictionary attack. But, you have to get access to the machine first. Without access to the machine it's near impossible to break. Shadow password files nullify this method of attack, although I don't like this password file dichotomy. The bottom line is that password security works. Most systems aren't broken into. The ones that are broken are usually compromised by some sloppy (ie. networking) utility or a flawed UNIX port. So Dan, a piece of advice: $@$*$H$7$^$((J $@$*(J $@$D$1$F(J! Boyd Roberts boyd@necisa.ho.necisa.oz.au ``When the going gets wierd, the weird turn pro...''
jik@athena.mit.edu (Jonathan I. Kamens) (06/05/90)
In article <11529@vpk1.UUCP>, ram@attcan.UUCP (Richard Meesters) writes: |> I'm not suggesting that we necessarily use the crypt() function call ala UNIX |> to provide the data encryption. What I'm suggesting is that perhaps the ftp |> code should include some form of encryption/decryption algorithm to protect |> the password information. IMHO, any plain-text password stored on a system |> is a security risk, no matter how well it is protected. It still won't work. And, no offense intended, I still don't think you've thought this through enough. Before posting a suggestion like this, try to through at least one concrete set-up which would make it work properly. Let me explain to you why I don't think you will be able to. You're proposing one of two things (I'm not sure which). Either you're saying that the password in the .netrc file should be encrypted in a way that ftp or ftpd can decrypt, or you're saying that ftp should encrypt the password before sending it over the network, and then ftpd should decrypt it on the other end. In the former case, you must keep in mind that the ftp protocol is publicly available, as is an implementation of ftp and ftpd. If your password in your .netrc is encrypted in a way that either ftp or ftpd knows how to decrypt, then if I can read your .netrc, I can decrypt your password by using the publicly available algorithm, or even easier by using publicly available ftp/ftpd source code. Therefore, you've gained no security over the already existent security of not allowing other users to read the .netrc file. In the latter case, once again, if I can read the encrypted password in your .netrc file, then I can use the algorithm or the publicly available ftpd code to decrypt it. Furthermore, if I'm snooping on the network and I see a password fly across the net encrypted in ftp's encryption algorithm, then I know the algorithm to use to decrypt it. Therefore, once again, you haven't gained any security by implementing encryption. Let's stop calling it encryption/decryption and call it the "verification function. Now let's say that I make the verification function site-specific, i.e. each site can define its on method of verifying that the password info it gets proves that you are who you say you are. You can make this site-specific stuff either client-dependent or client-independent. If the former, then you've got to have a separate version of ftp for each site. This is impractical at best. If the latter, you haven't gained anything, because once again you have to send a password over the network. In fact, the client-independent solution is exactly what the ftp protocol has now -- you send a password, and the server is allowed to do anything it wants with it for verification. Even if you implement client-dependent two-part (one in the client, one in the server) verification functions, once someone has managed to read the client and your .netrc file, they can pretend to be you. Once again, the only security you've got is their inability to read those files, which is pretty much no more security than there is now. Clearly, the strain running through all of this is the .netrc file -- delete that, and problems go away (well, most of them -- you still have network snooping). If you make the assumptions that no one else can get your password (i.e. either you never store it in a .netrc file or people really can't read your .netrc file {hehehehehehe :-}), and that no one is snooping on the network, then ftp is as secure as the normal Unix password scheme. *Think about* how Unix password security works, and then try to come up with a concrete example of what you're proposing. Of course, if you don't assume that the network is secure, then you need some network-secure authentication scheme, such as Kerberos. |> Again, see above. It doesn't have to be the same encryption algorithm that |> is used for /etc/passwd (or use the same key?). So the password in |> /etc/passwd does not necessarily have any bearing on the passwd in .netrc. |> The danger of a plain-text passwd in a file is that someone only has to SEE |> it, rather than necessarily decrypt it to be able to use it. It doesn't matter. If I can read your .netrc, then I can decrypt the password, since ftp knows how to decrypt it, and ftp sources are publicly available (and the ftp binary is publicly executable on the system). Therefore, even encrypted, the security of the password depends on the security of the .netrc file -- you're no better off than before. The reason Unix password security works is that the crypt() function is a *trapdoor* function. /bin/login doesn't say, "Let's decrypt the password in /etc/passwd and see if it matches what the user says his password is," because that's *impossible* (or, at least, it's believed to be; I'm not sure if crypt() has been proven to be a trapdoor function). What /bin/login says is, "Let's take what the user says his password is, encrypt it the same way the password was encrypted when it was set, and see if what we get matches what's in the /etc/passwd file." Then, if it matches, /bin/login gives the user appropriate privileges *since /bin/login is a privileged program*. Ftpd works the same way. What you're proposing is a two-way encryption function. That doesn't buy you anything, as long as files are not secure from unauthorized reading, since what's in the file *is* the password. In effect, what you're proposing is a filter through which every password must be passed before using it. Anybody who can read your password out of the .netrc can pass it through that filter as well as you can. Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8495 Home: 617-782-0710
dankg@volcano.Berkeley.EDU (Dan KoGai) (06/05/90)
In article <1752@necisa.ho.necisa.oz> boyd@necisa.ho.necisa.oz (Boyd Roberts) writes: >Dan, my man you seem to have jumped to the conclusion that UNIX isn't >secure because someone broke into your account and blew away your files. >How this was done would appear to be attributable to stupidity, and >not to underlying flaws in UNIX password security. Unix is at very least insecure enough to make me sleep in nightmare. I got several mails and some of them are raped even harder. And this applies to computer in general--My Mac is infected by virus 4 times (but last 2 was not serious at all, thanx to Disinfectant). >At this point I'd like to make the distinction between UNIX password security >and the various `security' of IP based networking utilities. With those, >there is _no_ security. I think RTM and various others have proved this >beyond a shadow of a doubt. UNIX password security is secure, provided you >have chosen a reasonable password. I do not think my accounts were nuked due to network flaw: Very unfortunately, there are several cracker activities reported to be originated at OCF. And my password was secure enough for your standard, the string as complicated as intercal syntax! >Sure, you can snarf /etc/passwd and try a dictionary attack. But, you have >to get access to the machine first. Without access to the machine it's >near impossible to break. Shadow password files nullify this method of attack, >although I don't like this password file dichotomy. It's not that hard today to obtain a UNIX account. And if you can crack one site, it's likely the site includes users with other remote accounts, which is exactly my case, and crack others--chain reaction also appeard in "Cockoo's Egg". I don't like NORAD-like security but very unfortunately human nature is evil and it takes evil to secure from evil. >The bottom line is that password security works. Most systems aren't broken >into. The ones that are broken are usually compromised by some sloppy >(ie. networking) utility or a flawed UNIX port. But it's far more common than your wallet is stolen. Look, I'm not the only victim and I heard of many cases on this Berkeley alone. And UNIX is still not common enough to attract people's attention--Internet virus case and Cockoo's Egg case attracted people because it was military security related, not because of fame of UNIX. I think I have seen too many cases of insecurity considering still small size of UNIX community. And this will get but more serious as UNIX gains its popularity. We'd better be prepared before it gets even messier. >So Dan, a piece of advice: > > $@$*$H$7$^$((J $@$*(J $@$D$1$F(J! ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ESC is dropped, yet another fraw of netnews sytem I wish I could. And now here's my advice: Living UNIX world is like an orgy: full of joy but riskier these days. ---------------- ____ __ __ + Dan The "insecured" Man ||__||__| + E-mail: dankg@ocf.berkeley.edu ____| ______ + Voice: +1 415-549-6111 | |__|__| + USnail: 1730 Laloma Berkeley, CA 94709 U.S.A |___ |__|__| + |____|____ + "What's the biggest U.S. export to Japan?" \_| | + "Bullshit. It makes the best fertilizer for their rice"
lyndon@cs.AthabascaU.CA (Lyndon Nerenberg) (06/06/90)
samlb@pioneer.arc.nasa.gov.UUCP (Sam Bassett RCS) writes: > I agree -- the documentation should be more straightforward about >the dangers of the .netrc, and for d**n sure, whoever is teaching kids >about UNIX should point out the problem -- especially at Berkeley. .netrc is an ugly BOTCH and should be removed from ftp. I guess I have something to do this afternoon ... -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University {alberta,cbmvax,mips}!atha!lyndon || lyndon@cs.athabascau.ca Practice Good Government Use A Kingdom
carroll@m.cs.uiuc.edu (06/06/90)
/* Written 11:22 am May 28, 1990 by dce@smsc.sony.com in m.cs.uiuc.edu:comp.unix.questions */ In article <1990May28.102235.10021@agate.berkeley.edu> dankg@ocf.Berkeley.EDU (Dan Kogai) writes: >In article <9000030@m.cs.uiuc.edu> carroll@m.cs.uiuc.edu writes: >>in it. Does FTP check for .netrc specially? If not, then this seems to >>claim that you ftp'd the .netrc and it was that copy that was used, >>not your 600 .netrc. > > It might be system dependent but ALL ftp I know refuses to use >.netrc with wrong mode. Hold on, Dan. I think that carrol@m.cs.uiuc.edu is asking "when going a get or a put, does ftp check for .netrc specially". That is, is it possible that you did a get/put of everything in a directory, and that your .netrc got copied to a new place without being protected? /* End of text from m.cs.uiuc.edu:comp.unix.questions */ Yes, this is what I meant. The scenario I envisioned was, 1. A tar is done on "." or using find, such that the .files are included, including the .netrc. 2. The tar file is ftp'd somewhere else, with permissions such that another user can get the file (normally or through ftp). 3. This other user then untars the file, and the .netrc, still with 600 permissions, is also untarred, but _owned by the other user_, because that's what tar does (on BSD - on SysV, you have to go to the trouble of using the -o flag). 4. Other user then picks the password out of the file. I can't see how ftp could possibly prevent this from happening, and I strongly suspect that something very similar to this took place. Alan M. Carroll Barbara/Marilyn in '92 : carroll@cs.uiuc.edu + This time, why not choose the better halves? Epoch Development Team CS Grad / U of Ill @ Urbana ...{ucbvax,pur-ee,convex}!cs.uiuc.edu!carroll
woods@robohack.UUCP (Greg A. Woods) (06/06/90)
In article <1990Jun5.152004.15873@agate.berkeley.edu> dankg@volcano.Berkeley.EDU (Dan KoGai) writes: > Unix is at very least insecure enough to make me sleep in nightmare. > I got several mails and some of them are raped even harder. And this applies > to computer in general--My Mac is infected by virus 4 times (but last 2 was > not serious at all, thanx to Disinfectant). Your first sentence is wrong, as I will attempt to show. I don't quite understand your second sentence. As to your final point however, you should realize the susceptibility of a PC (any PC, or home computer, including Apple's Macintosh) to a virus is several orders of magnitude greater than the average UNIX system. Certainly a true UNIX virus is possible, and given the sloppiness of the average vendor these days, one could easily get out. However, I'd suggest that it would be rare that such a virus would be contagious. Binaries just aren't often moved or shared between UNIX systems, and the software distribution hierarchy is entirely different. This is changing with the increasing use of workstations on networks though...and you can't really blame the network for this "flaw". > I do not think my accounts were nuked due to network flaw: Very > unfortunately, there are several cracker activities reported to be originated > at OCF. And my password was secure enough for your standard, the string as > complicated as intercal syntax! I don't know how your site is related to OCF, but if they share a network cable, then yes, you can indeed blame the network.... > It's not that hard today to obtain a UNIX account. And if you can > crack one site, it's likely the site includes users with other remote accounts, > which is exactly my case, and crack others--chain reaction also appeard in > "Cockoo's Egg". I don't like NORAD-like security but very unfortunately human > nature is evil and it takes evil to secure from evil. Yes, but first you'll have to crack the passwords of the people at the "breached" site. Then you'll have to hope they use the same passwords on the target sites. Then you repeat the loop. Fortunately it is likely you'll be discovered before the second iteration, since there is still a significant lag required to break the passwords the hard way. (You'll also have to get through any "external" security the target sites may have, such as call-back or dialup passwords.) Again, the network makes this so much easier! > In article <1752@necisa.ho.necisa.oz> boyd@necisa.ho.necisa.oz (Boyd Roberts) writes: > >The bottom line is that password security works. Most systems aren't broken > >into. The ones that are broken are usually compromised by some sloppy > >(ie. networking) utility or a flawed UNIX port. > > But it's far more common than your wallet is stolen. Look, I'm not > the only victim and I heard of many cases on this Berkeley alone. And UNIX > is still not common enough to attract people's attention--Internet virus > case and Cockoo's Egg case attracted people because it was military security > related, not because of fame of UNIX. I think I have seen too many cases > of insecurity considering still small size of UNIX community. And this will > get but more serious as UNIX gains its popularity. We'd better be prepared > before it gets even messier. Berkeley is on a network. If it were possible that the network be secure, or not exist, the breakins would be as common as those to Fort Knox. Most breaches of commercial UNIX systems are due entirely to sloppy, or non-existant, system administration. What does the "fame" of UNIX have to do with anything? Do you think it will be a more common target if it becomes more famous? I doubt anything would raise the ratio of UNIX breakins to those of other types of systems. I would imagine the ratio is already quite high. UNIX is already quite famous in the cracker community. UNIX is fundamentaly quite "secure" (in the common definition). It does not, however, have mandatory security by default. UNIX makes it easy for you to disable any security features, sometimes by accident. Networks are fundamentaly quite insecure. They are designed to provide open and easy access to "remote" resources. -- Greg A. Woods woods@{robohack,gate,eci386,tmsoft,ontmoh}.UUCP +1 416 443-1734 [h] +1 416 595-5425 [w] VE3-TCP Toronto, Ontario; CANADA
ram@attcan.UUCP (Richard Meesters) (06/06/90)
In article <1990Jun5.081053.25508@athena.mit.edu>, jik@athena.mit.edu (Jonathan I. Kamens) writes: < In article <11529@vpk1.UUCP>, ram@attcan.UUCP (Richard Meesters) writes: < |> I'm not suggesting that we necessarily use the crypt() function call < ala UNIX < |> to provide the data encryption. What I'm suggesting is that perhaps the ftp < |> code should include some form of encryption/decryption algorithm to protect < |> the password information. IMHO, any plain-text password stored on a system < |> is a security risk, no matter how well it is protected. < < Clearly, the strain running through all of this is the .netrc file -- < delete that, and problems go away (well, most of them -- you still have < network snooping). < < If you make the assumptions that no one else can get your password < (i.e. either you never store it in a .netrc file or people really can't < read your .netrc file {hehehehehehe :-}), and that no one is snooping on < the network, then ftp is as secure as the normal Unix password scheme. < *Think about* how Unix password security works, and then try to come up < with a concrete example of what you're proposing. < Again, my thrust has really been that having a plain-text password in a file is BAD (excuse the shout). And the best possible thing to do is eliminate it. But if that's not possible, and a large number of users will most certainly balk at their administrators making life more miserable by making them (gasp!) type passwords when they want to go across the network, then we need to provide some level of security to the users, IMHO. < Of course, if you don't assume that the network is secure, then you < need some network-secure authentication scheme, such as Kerberos. < > |> Again, see above. It doesn't have to be the same encryption algorithm that < |> is used for /etc/passwd (or use the same key?). So the password in < |> /etc/passwd does not necessarily have any bearing on the passwd in .netrc. < |> The danger of a plain-text passwd in a file is that someone only has to SEE < |> it, rather than necessarily decrypt it to be able to use it. < < It doesn't matter. If I can read your .netrc, then I can decrypt the < password, since ftp knows how to decrypt it, and ftp sources are < publicly available (and the ftp binary is publicly executable on the < system). Therefore, even encrypted, the security of the password < depends on the security of the .netrc file -- you're no better off than before. < What you're proposing is a two-way encryption function. That doesn't < buy you anything, as long as files are not secure from unauthorized < reading, since what's in the file *is* the password. < < In effect, what you're proposing is a filter through which every < password must be passed before using it. Anybody who can read your < password out of the .netrc can pass it through that filter as well as you can. < I agree that if you have access to the encryption function you can break the password/security of the system. But it does buy you something. What it gives you is protection from the person who only gets a chance to _look_ at your .netrc/[file where password information is stored - this has in effect gone beyond a specific topic] and see instantly what that password is. At least with some level of encryption, someone will only see 'asfj8af2' instead of 'farpoint' or whatever you use as a password. If anyone is dedicated enough, or has access to enough information/source, he/she is likely to be able to break almost any protection scheme you can think of. It's a matter of degree. Regards, ------------------------------------------------------------------------------ Richard A Meesters | Technical Support Specialist | Insert std.logo here AT&T Canada | | "Waste is a terrible thing ATTMAIL: ....attmail!rmeesters | to mind...clean up your act" UUCP: ...att!attcan!ram | ------------------------------------------------------------------------------
jik@athena.mit.edu (Jonathan I. Kamens) (06/07/90)
In article <720015@hpclapd.HP.COM>, defaria@hpclapd.HP.COM (Andy DeFaria) writes: |> I'm no security guru on Unix but it seems to me that the way around this |> problem would be to remove this silly restriction and allow ftp (and |> others?) to send encrypted passwords to the other host. I thought I already explained this. Sigh. Let's assume that what you said is possible. In that case, I do the following: 1. Log into your machine. 2. Grab the encrypted password for root out of the (publicly readable) /etc/passwd. 3. "Ftp localhost". 4. Use username "root", and the encrypted password I've already snarfed. Presto, I've just ftp'd as root, without ever knowing the root password! There is a fundamental concept you're missing -- the act of encrypting the password and comparing it to the password in /etc/passwd is the authentication; if you don't do the encryption, you haven't proven anything. (How many times am I going to have to explain this?) Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8495 Home: 617-782-0710
les@chinet.chi.il.us (Leslie Mikesell) (06/07/90)
In article <1990Jun5.152004.15873@agate.berkeley.edu> dankg@volcano.Berkeley.EDU (Dan KoGai) writes: >>Dan, my man you seem to have jumped to the conclusion that UNIX isn't >>secure because someone broke into your account and blew away your files. > Unix is at very least insecure enough to make me sleep in nightmare. >I got several mails and some of them are raped even harder. The usual protection against losing files either due to accidents or malicious removal is to keep backups. Doesn't your site maintain some reasonably current tape copies of everything? I also try to keep copies of files that are personally valuable on PC floppies which at the moment are the ultimate in portable media. All you really need is access to a PC, modem, and dial-up port to tranfer to/from just about anything. Les Mikesell les@chinet.chi.il.us
boyd@necisa.ho.necisa.oz (Boyd Roberts) (06/08/90)
In article <1990Jun5.152004.15873@agate.berkeley.edu>, dankg@volcano.Berkeley.EDU (Dan KoGai) writes: > In article <1752@necisa.ho.necisa.oz> boyd@necisa.ho.necisa.oz (Boyd Roberts) writes: > > >So Dan, a piece of advice: > > > > $@$*$H$7$^$((J $@$*(J $@$D$1$F(J! > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ESC is dropped, yet another fraw of > netnews sytem > No, guess again. Iie chigaimasu, ESC ga arimasen deshita. Boyd Roberts boyd@necisa.ho.necisa.oz.au ``When the going gets wierd, the weird turn pro...''
dankg@tornado.Berkeley.EDU (Dan KoGai) (06/08/90)
In article <1990Jun7.161215.27328@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >The usual protection against losing files either due to accidents or >malicious removal is to keep backups. Doesn't your site maintain >some reasonably current tape copies of everything? I also try to keep >copies of files that are personally valuable on PC floppies which at the >moment are the ultimate in portable media. All you really need is access >to a PC, modem, and dial-up port to tranfer to/from just about anything. One of my accounts did: Not this OCF account. But losing files are rather small problems. What if your root password is illegally changed by someone else? If so unless you can replace /etc/passwd or yp, you can't get back to root again (replace whole disk with carbon-copy image of previous backup?). Of course you can do it by replacing whole disk but it's a hardware solution and not very efficient. My case is not just accident. The moron showed me capability of doing even nastier things. So backup is not a solution of cracker and never intended to be: cracker is not an accident and we are not supposed to confuse accident and felony. As long as we depend on crypt() to encrypt password and password file is open to public, unix can never be secure enough--I wrote a 10-line C code to crack it and successfully found my own password (Thank god this method doesn't apply on Apollo where my OCF account resides but works any with /etc/passwd. And easily extendable to yp). It took horrible time but this kind of time is nothing compared to the prize it guarantees). I'm not at all UNIX guru but all I needed was how password protection was implemented and decent C knowledge--both accessible. We should at very least separate encrypted password from finger entries. And if possible, replace dummy crypt() with something else--we don't need much speed for login process, do we? ---------------- ____ __ __ + Dan The "Hackn' Scared" Man ||__||__| + E-mail: dankg@ocf.berkeley.edu ____| ______ + Voice: +1 415-549-6111 | |__|__| + USnail: 1730 Laloma Berkeley, CA 94709 U.S.A |___ |__|__| + |____|____ + if (!strcmp(cryptpass, crypt(pass, cryptpass))) \_| | + You_Are_Toast();
defaria@hpclapd.HP.COM (Andy DeFaria) (06/08/90)
>/ hpclapd:comp.unix.questions / jik@athena.mit.edu (Jonathan I. Kamens) / 2:46 pm Jun 6, 1990 / >In article <720015@hpclapd.HP.COM>, defaria@hpclapd.HP.COM (Andy >DeFaria) writes: >|> I'm no security guru on Unix but it seems to me that the way around this >|> problem would be to remove this silly restriction and allow ftp (and >|> others?) to send encrypted passwords to the other host. > > I thought I already explained this. Sigh. > > Let's assume that what you said is possible. In that case, I do the >following: > >1. Log into your machine. >2. Grab the encrypted password for root out of the (publicly readable) ^^^^^^^^^^^^^^^^^ > /etc/passwd. >3. "Ftp localhost". >4. Use username "root", and the encrypted password I've already snarfed. > >Presto, I've just ftp'd as root, without ever knowing the root password! > > There is a fundamental concept you're missing -- the act of encrypting >the password and comparing it to the password in /etc/passwd is the >authentication; if you don't do the encryption, you haven't proven anything. > > (How many times am I going to have to explain this?) > >Jonathan Kamens USnail: >MIT Project Athena 11 Ashford Terrace >jik@Athena.MIT.EDU Allston, MA 02134 >Office: 617-253-8495 Home: 617-782-0710 >---------- I thought I explained this. IMHO /etc/passwd should NOT be publicly readable. If this were true then you couldn't ftp as root because you wouldn't even know the encrypted password, which, IMHO, you shouldn't have access to.
jik@athena.mit.edu (Jonathan I. Kamens) (06/09/90)
In article <1990Jun8.154523.5102@agate.berkeley.edu>, dankg@tornado.Berkeley.EDU (Dan KoGai) writes: |> One of my accounts did: Not this OCF account. But losing files |> are rather small problems. What if your root password is illegally changed |> by someone else? If so unless you can replace /etc/passwd or yp, you can't |> get back to root again (replace whole disk with carbon-copy image of previous |> backup?). Please do not try to post authoritatively about things concerning which you are not an authority. There are very few Unix systems on which a system administrator with the necessary access can't log on as the superuser, even if he doesn't know the root password, as long as the machine is intact enough to boot into single-user mode. |> As long as we depend on crypt() to encrypt password and password file |> is open to public, unix can never be secure enough--I wrote a 10-line C code |> to crack it and successfully found my own password (Thank god this method |> doesn't apply on Apollo where my OCF account resides but works any with |> /etc/passwd. And easily extendable to yp). It took horrible time but this |> kind of time is nothing compared to the prize it guarantees). I am becoming more and more convinced that you're flaming without much justification about something about which you know little, and frankly, it's getting a little irritating. Well-chosen passwords *are* secure enough in almost all situations, even when the /etc/passwd file is world-readable. The fact that you wrote a C program to crack passwords and it successfully found yours just means that your password was not well-chosen. You can't blame Unix for that. |> I'm not at all UNIX guru but all I needed was how password protection |> was implemented and decent C knowledge--both accessible. We should at very |> least separate encrypted password from finger entries. And if possible, |> replace dummy crypt() with something else--we don't need much speed for |> login process, do we? Actually, I consider fast log-in time to be one of the most important features in any given system. Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8495 Home: 617-782-0710
omerzu@quando.UUCP (Thomas Omerzu) (06/09/90)
In article <720016@hpclapd.HP.COM> defaria@hpclapd.HP.COM (Andy DeFaria) writes: [...] >>2. Grab the encrypted password for root out of the (publicly readable) >> /etc/passwd. [...] > >I thought I explained this. IMHO /etc/passwd should NOT be publicly >readable. If this were true then you couldn't ftp as root because you [...] I cannot find out where you explained this, but have you ever tried to remove public read permissions from /etc/passwd? Very funny results, not the simplest 'ls -l' will work ... And now MAY WE STOP this discussion PLEASE? To me it seems as if everything worthy of discussion has been said at least twice, and every new aspect is more unqualified than the one before ... -- Thomas Omerzu, omerzu@quando.quantum.de
jik@athena.mit.edu (Jonathan I. Kamens) (06/10/90)
In article <720016@hpclapd.HP.COM> defaria@hpclapd.HP.COM (Andy DeFaria) writes: >I thought I explained this. IMHO /etc/passwd should NOT be publicly >readable. If this were true then you couldn't ftp as root because you >wouldn't even know the encrypted password, which, IMHO, you shouldn't have >access to. Oh, jolly good. So now you're proposing to take all the passwords (or, at least, encrypted passwords) and put them in an /etc/shadow file, but other than the fact that the file isn't world-readable, the rest of the scenario I described is correct, right? In that case, you're basing the entire security of your system on the readability or non-readability of one file. Do you know how many ways there are in Unix to read a file you're not supposed to be able to read? Or to read portions of that file? The elegance of the standard Unix security mechanism is that, given well-chosen and moderately-frequently-changed passwords, it doesn't *matter* whether or not someone can read the /etc/passwd file, because doing so *does not enable them to break the security of your system*, at least not in the short term. Under the system you propose, you've completely eliminated that elegance. Indeed, if the password file isn't world-readable, then why not just store the plaintext password in it, and not the encrypted password? After all, according to what you're saying, all you need to do to verify that someone is who they say they are is to compare the string they give you to the string in a file that isn't world-readable, so why bother with the encryption? One more note -- this wole discussion started when someone suggested that people be allowed to store their encrypted passwords in the .netrc file, rather than their plaintext passwords, to prevent people who managed to read their .netrc file from using it to gain access to other systems. Your proposal doesn't fix that problem, because, as I've already said, if the encrypted password is what is used for the authentication, then if I can read your .netrc, I can still use its contents to break into your other accounts. Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8495 Home: 617-782-0710
jik@athena.mit.edu (Jonathan I. Kamens) (06/10/90)
In article <1557@quando.UUCP> omerzu@quando.UUCP (Thomas Omerzu) writes: >I cannot find out where you explained this, >but have you ever tried to remove public read permissions >from /etc/passwd? >Very funny results, not the simplest 'ls -l' will work ... What he was talking about was something on the order of a protected /etc/shadow file containing only the encrypted passwords, not a wholesale protection of everything in /etc/passwd. >And now MAY WE STOP this discussion PLEASE? >To me it seems as if everything worthy of discussion has been said >at least twice, and every new aspect is more unqualified than the >one before ... Indeed. Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8495 Home: 617-782-0710
dankg@tornado.Berkeley.EDU (Dan KoGai) (06/11/90)
In article <1990Jun8.175747.18776@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: > I am becoming more and more convinced that you're flaming without much >justification about something about which you know little, and frankly, >it's getting a little irritating. All I know is I became victim and there are a lot others. And it's not that hard to overcome crypt(). I admit I know too little to become a security expert. But it doesn't take a wizard to know every single file I had were brutally deleted. Are you still saying I am just flaming? if you stop me or people like me from what you call flaming, Give us secure system for first place so I don't have to post something like this anymore, period! > Well-chosen passwords *are* secure enough in almost all situations, >even when the /etc/passwd file is world-readable. The fact that you >wrote a C program to crack passwords and it successfully found yours >just means that your password was not well-chosen. You can't blame Unix >for that. I think my password was well-chosen: It is hardly English or any other language, with Uppercase and Numbers. My previous one was very random also. Yet my 10-line (now 20 and can handle even more complex cases) successfully found it: I didn't use /usr/dict/words or any sort at all. > Actually, I consider fast log-in time to be one of the most important >features in any given system. Provided it's secure enough. UNIX is not. I'm not very exceptionally rare victims. I know a lot of even severe cases broken harder, which are protected with UNIX experts. How many victims do we need to convince you guys that today's UNIX needs major upgrade of secirity? Well, even after Stockton Masscare, this country allows us to have guns without any lisence. maybe asking Americans for secirity is never secure enough for 1st place. ---------------- ____ __ __ + Dan The "Just one of many victims" Man ||__||__| + E-mail: dankg@ocf.berkeley.edu ____| ______ + Voice: +1 415-549-6111 | |__|__| + USnail: 1730 Laloma Berkeley, CA 94709 U.S.A |___ |__|__| + |____|____ + if (!strcmp(cryptpass, crypt(pass, cryptpass))) \_| | + You_Are_Toast();
jrh@mustang.dell.com (James Howard) (06/11/90)
Dan KoGai writes: > All I know is I became victim and there are a lot others. [ much whining deleted ] > How many victims do we need to convince you > guys that today's UNIX needs major upgrade of secirity? Well, even after > Stockton Masscare, this country allows us to have guns without any lisence. > maybe asking Americans for secirity is never secure enough for 1st place. > > ---------------- > ____ __ __ + Dan The "Just one of many victims" Man > ||__||__| + E-mail: dankg@ocf.berkeley.edu > ____| ______ + Voice: +1 415-549-6111 > | |__|__| + USnail: 1730 Laloma Berkeley, CA 94709 U.S.A > |___ |__|__| + > |____|____ + if (!strcmp(cryptpass, crypt(pass, cryptpass))) > \_| | + You_Are_Toast(); Here is a quote that seems appropriate, although I do not remember the source: Even the truly paranoid have real enemies. flames > /dev/null --------------------------------------------------------- James Howard Dell Computer Corp. jrh@mustang.dell.com The opinions expressed are my own, and not necessarily those of my employer. ---------------------------------------------------------
rogerj@batcomputer.tn.cornell.edu (Roger Jagoda) (06/11/90)
In article <1931@aurora.cs.athabascau.ca> lyndon@cs.AthabascaU.CA (Lyndon Nerenberg) writes: >samlb@pioneer.arc.nasa.gov.UUCP (Sam Bassett RCS) writes: > >> I agree -- the documentation should be more straightforward about >>the dangers of the .netrc, and for d**n sure, whoever is teaching kids >>about UNIX should point out the problem -- especially at Berkeley. > >.netrc is an ugly BOTCH and should be removed from ftp. I guess I >have something to do this afternoon ... Wait, the .netrc file DOES have a good use--anonymous FTP sites. I mean how many times do you REALLY want to type ANONYMOUS anyway. Sam's right, the UCB kids just need better teaching about the tool, although, UNIX has this problem in other tools too. Just MHO. As for the passwd file being readable by ANYONE, there's no argument I know of that can be presented for why that EVER was a good idea. If a file is readable it is useable, or MIS-useable. Novell, VMS, IBM OSes all have similar files that are NOT readable...for good reasons. Now, shadow passwd files are part of the solution, allowing the OS to get by with a passwd file with attributes of 600 is another part and doing away with the file altogether is the BEST part! -- ------------------------------------------------------------------------------ Roger Jagoda -- My employers don't even like paying Cornell University me, let alone accept responsibility fqoj@cornella.cit.cornell.edu for anything I say or do! --
defaria@hpclapd.HP.COM (Andy DeFaria) (06/12/90)
>/ hpclapd:comp.unix.questions / jik@athena.mit.edu (Jonathan I. Kamens) / 1:30 am Jun 10, 1990 / > Oh, jolly good. So now you're proposing to take all the passwords >(or, at least, encrypted passwords) and put them in an /etc/shadow >file, but other than the fact that the file isn't world-readable, the >rest of the scenario I described is correct, right? If you can't get the password because you can't read it then you scenario fails. > In that case, you're basing the entire security of your system on >the readability or non-readability of one file. Do you know how many >ways there are in Unix to read a file you're not supposed to be able >to read? Or to read portions of that file? I don't know how many ways there are in Unix to read a file you're not supposed to be able to read but if there are any then they are holes in the files system itself.
jik@athena.mit.edu (Jonathan I. Kamens) (06/12/90)
In article <1990Jun10.183417.6226@agate.berkeley.edu>, dankg@tornado.Berkeley.EDU (Dan KoGai) writes: |> All I know is I became victim and there are a lot others. And it's |> not that hard to overcome crypt(). I admit I know too little to become |> a security expert. But it doesn't take a wizard to know every single file |> I had were brutally deleted. Are you still saying I am just flaming? |> if you stop me or people like me from what you call flaming, Give us secure |> system for first place so I don't have to post something like this anymore, |> period! As I, and several other people, have already pointed out, it *is* sufficiently hard to overcome crypt() if your password is well chosen. One of the reasons I said in a previous posting that I don't think you know what you're talking about is that you keep on claiming that crypt() is easy to break, when in fact it isn't. Your files were removed because you had a .netrc file with a plaintext password in it. That has nothing to do with crypt(). As someone else has already pointed out, it is incredibly stupid to put any password which you don't want other people to know into your .netrc file. The fact that you did so has nothing at all to do with whether or not crypt() is secure. |> I think my password was well-chosen: It is hardly English or |> any other language, with Uppercase and Numbers. My previous one was very |> random also. Yet my 10-line (now 20 and can handle even more complex cases) |> successfully found it: I didn't use /usr/dict/words or any sort at all. Your password may very well have been well-chosen. That's completely irrelevant to the argument of whether or not crypt() is adequate, since the way your account was broken into was by someone who read your .netrc file, not by someone who cracked your password by encryption. |> Provided it's secure enough. UNIX is not. I'm not very exceptionally |> rare victims. I know a lot of even severe cases broken harder, which are |> protected with UNIX experts. How many victims do we need to convince you |> guys that today's UNIX needs major upgrade of secirity? Well, even after |> Stockton Masscare, this country allows us to have guns without any lisence. |> maybe asking Americans for secirity is never secure enough for 1st place. I am fully in agreement with the claim that Unix security needs to be enhanced in many areas. I just don't think that what happened to you is any sort of good example of why this is so, and I still think that what happened to you is more your fault than it is the fault of Unix. Or, at most, the fault of Unix documentation and of the people who run your site for not telling you not to put important passwords in the .netrc file. Finally, I think your argument about guns is bogus and irrelevant. Even after a guy with a can of gasoline burned down a nightclub and killed something like 80 people (someone feel free to correct me if I'm wrong), many more people than were killed and injured at Stockton, this country allows us to have gasoline without any license. Figure that out. Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8495 Home: 617-782-0710
woods@robohack.UUCP (Greg A. Woods) (06/12/90)
In article <1990Jun10.183417.6226@agate.berkeley.edu> dankg@tornado.Berkeley.EDU (Dan KoGai) writes: > In article <1990Jun8.175747.18776@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: > > > I am becoming more and more convinced that you're flaming without much > >justification about something about which you know little, and frankly, > >it's getting a little irritating. > >[....] Are you still saying I am just flaming? > if you stop me or people like me from what you call flaming, Give us secure > system for first place so I don't have to post something like this anymore, > period! Whoa! Jonathan is absolutely right! You aren't just flaming though, you're whining, and beginning to annoy at least me.... If you were to have a system secure enough not to have to worry again, you'd never be posting from it, nor reading and/or sending mail on it. The only truly secure system is a physically isolated system, with properly administered physical security policies. I would even go so far as to suggest that you would not be running news on an even moderately secure UNIX system. Mail is a bit safer. Networking (eg. with things such as NFS, or even SMTP) is much more more dangerous. > I think my password was well-chosen: It is hardly English or > any other language, with Uppercase and Numbers. My previous one was very > random also. Yet my 10-line (now 20 and can handle even more complex cases) > successfully found it: I didn't use /usr/dict/words or any sort at all. OK, I'll believe you. However, you did mention that it took quite a bit of horsepower to crack. Mind telling us just how much? Was your algorithm tainted towards the pattern employed in your password? Was your programme actually used by an outside party to crack your own password? Meanwhile, do you have proof your password was compromised? If not, have you considered again that it may have been a security violation through the network, or perhaps in a poorly designed application which allowed the compromise. It may even have been an "inside" job by some other "authorized" user of your system. Again, I must also resurrect the question of why your files weren't on backup media, ready to be restored in event of disaster. (I apologize if they were, but in that case, what are you crying about?) > > Actually, I consider fast log-in time to be one of the most important > >features in any given system. > > Provided it's secure enough. UNIX is not. I'm not very exceptionally > rare victims. I know a lot of even severe cases broken harder, which are > protected with UNIX experts. How many victims do we need to convince you > guys that today's UNIX needs major upgrade of secirity? [....] And how many times do we have to tell you that the responsibility for UNIX security lies with the administrator. UNIX, in and of itself, can be made quite secure. I believe the official rating of a carefully maintained and only slightly modified system can reach C2 (per "the Orange Book"). Certainly the "objects" deemed important by a commercial user can indeed be monitored easily enough to maintain a C2 rating. Personally I do not see a great philosophical gain in the efforts by such vendors as AT&T to create an even more secure UNIX system (i.e. B2). [Yes, "today's UNIX" is, and has been for quite some time, getting a major security upgrade.] I don't feel the implementation of B2-secure UNIX systems maintains either the spirit of UNIX, or even the spirit of POSIX. Such things are only done to attract those who are already entrapped by the red tape of the existing security establishment. The great majority of both industry and government applications do not require such measures, and would not require them even if the threat of crackers was much greater than it really is. Proper administration of these systems, which is even more critical with the added security features of these systems, will provide adequate security in most cases. No system can be considered secure unless there is a security policy that is enforced outside of the system itself. The system can be no more secure than the environment in which it operates. The proper administration of a sufficient security policy to maintain a B2 level system is far beyond the capabilities of most "users" of UNIX. -- Greg A. Woods woods@{robohack,gate,eci386,tmsoft,ontmoh}.UUCP +1 416 443-1734 [h] +1 416 595-5425 [w] VE3-TCP Toronto, Ontario; CANADA
gwyn@smoke.BRL.MIL (Doug Gwyn) (06/12/90)
In article <1990Jun10.083006.17475@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: > The elegance of the standard Unix security mechanism is that, given >well-chosen and moderately-frequently-changed passwords, it doesn't >*matter* whether or not someone can read the /etc/passwd file, because >doing so *does not enable them to break the security of your system*, >at least not in the short term. While that was reasonably the case when this scheme was first devised, it is certainly no longer true. Thus, hiding the encrypted passwords is now necessary for security, and if there are no other security loopholes that suffices to protect the passwords. Better authentication schemes are welcome, but until one is widely adopted shadow encrypted password files plug one of the biggest security gaps.
dennis@bailey.cpac.washington.edu (Dennis Gentry) (06/12/90)
In article <1990Jun10.183417.6226@agate.berkeley.edu> dankg@tornado.Berkeley.EDU (Dan KoGai) writes:
It's not that hard to overcome crypt().
There are no published easy methods of overcoming crypt(). If
you have found one, I would like to help you co-author a paper.
I think my password was well-chosen: It is hardly English or any
other language, with Uppercase and Numbers. My previous one was
very random also. Yet my 10-line (now 20 and can handle even
more complex cases) successfully found it: I didn't use
/usr/dict/words or any sort at all.
Again, I would be extremely surprised if your 20 line program
can successfully find well chosen passwords at any reasonable
rate (say one per year on a fast workstation). Also, it is easy
for a good system administrator to change the original string
being encrypted so that remote password attacks are much more
difficult. Dan, would you be willing to mail me your 20 line
program for analysis? If you are not, I'd still believe you if
you can you find my password. Here is my password entry. (If
any of you besides Dan crack my password, please let me know by
sending e-mail.)
dennis:H3MsMYv9Jed8Y:100:10:Dennis Gentry:/u/dennis:/bin/csh
Thanks,
Dennis
dennis@cs.washington.eduvolpe@underdog.crd.ge.com (Christopher R Volpe) (06/12/90)
In article <1990Jun12.012339.12779@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: > >In article <1990Jun10.183417.6226@agate.berkeley.edu>, >dankg@tornado.Berkeley.EDU (Dan KoGai) writes: > >|> I think my password was well-chosen: It is hardly English or >|> any other language, with Uppercase and Numbers. My previous one was very >|> random also. Yet my 10-line (now 20 and can handle even more complex cases) >|> successfully found it: I didn't use /usr/dict/words or any sort at all. > > Your password may very well have been well-chosen. That's completely >irrelevant to the argument of whether or not crypt() is adequate, since >the way your account was broken into was by someone who read your .netrc >file, not by someone who cracked your password by encryption. > Wait a minute. It sounds to me like Dan is claiming that with a 10 (or 20) line C program, he was able to find an arbitrary password (with uppercase and numerals) via encryption. Yes, it's true, that his account was broken into by someone who read the password from the .netrc file, but that has nothing to do with his claim. He says he didn't use /usr/dict/words or any sort of [word list] at all, which implies something along the lines of an exhaustive search. I find that highly unlikely, considering that the password encryption mechanism is an implementation of DES, which uses a 56 bit key. A brute force search of the keyspace is pretty unfeasable. Perhaps I misunderstood the claim. ============================ Chris Volpe Computer Scientist G.E. Corporate Research and Development volpecr@crd.ge.com
shwake@raysnec.UUCP (Ray Shwake) (06/12/90)
In article <1557@quando.UUCP> omerzu@quando.UUCP (Thomas Omerzu) writes: > >but have you ever tried to remove public read permissions >from /etc/passwd? >Very funny results, not the simplest 'ls -l' will work ... I recently structured permissions on one password file such that one group - let's call them outsider - can't access /etc/passwd, but others can. Simply assign GROUP ownership of /etc/password to the outsider group and take away their read permission. viz. -rw----r-- 1 bin outsider 1041 May 02 16:26 /etc/passwd BTW, many new UNIX implementations post-3.2 support password shadowing, such that the encrypted passwords are NOT publicly accessible.
bitbug@vicom.com (James Buster) (06/13/90)
I think that something the original complainant forgets is *just how annoying*
a truly secure system is. Have you ever used a system with mandatory security?
Such a system, when properly setup, means that often you can't freely send data
around. Want to send mail to a friend? Sorry, your friend has the
*wrong label*, and can't read the mail. Allowing your friends to just read your
files will also fail, for the same reason. You could allow such information
transfer, but then you've compromised security, haven't you? All in all, no
fun. In general, ease of use is inversely proportional to level of security.
--
---------------------------------------------------------------------
James Buster (Domain) bitbug@vicom.com
Mad Hacker Extraordinaire (UUCP) ...!ames!vsi1!bitbug
---------------------------------------------------------------------jik@athena.mit.edu (Jonathan I. Kamens) (06/13/90)
In article <720017@hpclapd.HP.COM> defaria@hpclapd.HP.COM (Andy DeFaria) writes: >I don't know how many ways there are in Unix to read a file you're not >supposed to be able to read but if there are any then they are holes in the >files system itself. Exactly. There are quite a few known bugs in various implementations of Unix, some of which ban be exploited as security holes, and many of which have not yet been fixed by many vendors. In addition, there are probably bugs that we don't know about, and some of them can be exploited as security holes. Finally, vendors are always developing Unix, and I'm sure that you'll agree that with development comes new bugs, some of which aren't discovered for some time, and some of which can be exploited as security holes. Given all this, I think that any security which depends on the unreadibility of one file is flawed. Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8495 Home: 617-782-0710
boyd@necisa.ho.necisa.oz (Boyd Roberts) (06/13/90)
In article <1990Jun10.183417.6226@agate.berkeley.edu> dankg@tornado.Berkeley.EDU (Dan KoGai) writes: > > All I know is I became victim and there are a lot others. And it's >not that hard to overcome crypt(). I admit I know too little to become >a security expert. Exactly. Dan, this is comp.unix.questions, not comp.unix.bitching. Move the discussion to alt.flame and give this group a rest. It is obvious from your postings that paranoia is the driving force behind them. Enough! Boyd Roberts boyd@necisa.ho.necisa.oz.au ``When the going gets wierd, the weird turn pro...''
root@rdb1.UUCP (Robert Barrell) (06/13/90)
In article <8480@crdgw1.crd.ge.com>, volpe@underdog.crd.ge.com (Christopher R Volpe) writes: > Wait a minute. It sounds to me like Dan is claiming that with a 10 > (or 20) line C program, he was able to find an arbitrary password > (with uppercase and numerals) via encryption.... >... > He says he didn't use /usr/dict/words or any sort of [word list] at all, > which implies something along the lines of an exhaustive search. > I find that highly unlikely, considering that the password encryption > mechanism is an implementation of DES, which uses a 56 bit key. > A brute force search of the keyspace is pretty unfeasable. Perhaps > I misunderstood the claim. Instead of performing an exhaustive search on passwords, perhaps Dan is doing something by running through all the possible 2-character salt values on the encrypted password. Even so, isn't crypt() supposed to "rotate" so many times anyway to defeat such an attempted decryption? Also, what about the CBW (Crypt-Breaker's Workshop) programs? I believe they are only for entire files that have been encrypted, but don't know if they are useful for passwords or not. -- Robert Barrell | ...!cbmvax!gvlv2!lock60!rdb1!root | Cody Computer Services Milo's Meadow BBS | root@rdb1.canal.org | 55 East High Street login: nuucp or bbs |-----------------------------------| Pottstown, PA 19464 (215) 323-0497 | Business and Police Dept Software | (215) 326-7476
edp@east.sun.com (Ed Pendzik {Prof Services} Sun Rochester) (06/13/90)
In article <1990Jun10.183417.6226@agate.berkeley.edu> dankg@tornado.Berkeley.EDU (Dan KoGai)
How many victims do we need to convince you
guys that today's UNIX needs major upgrade of secirity? Well, even after
Stockton Masscare, this country allows us to have guns without any lisence.
maybe asking Americans for secirity is never secure enough for 1st place.
please show how a lunatic in CA has anything to do with computer security.
despite his criminal record and tough CA gun laws he had no problems legally
buying firearms. this was a breakdown of the CA legal system.
Ed Pendzikdefaria@hpclapd.HP.COM (Andy DeFaria) (06/13/90)
>/ hpclapd:comp.unix.questions / jik@athena.mit.edu (Jonathan I. Kamens) / 4:49 pm Jun 12, 1990 / > Given all this, I think that any security which depends on the >unreadibility of one file is flawed. Yeah but what do you call leaving the file totally readable? What would be an unflawed security scheme? As fas as "a system too secure is unusable" goes I believe that the security of system should be set up such that you have access to the info that you need and are not allowed to get at info that you don't need or that would compromise the security of the system. The biggest problems that I see to this set up is: 1) Determining what all users need to be able to access. This is done initially by system admin BUT IT MUST BE AN ON-GOING ITERRATIVE AND INTERACTIVE PROCESS. If this is not carried through properly the system does indeed become hard to use. 2) Having a system admin that puts up stupid rules and barriers under the name of security. If someone has a litgitimate (sp?) need for a piece of info then there shouldn't be a big buerucratic (sp?) process to get the proper permissions to access the info. If the system admin people start saying things like "I can't allow you to look at this... It's company policy" then you're in trouble (especially when you ask "Why?" and they simply say "It's company policy". I seriously believe that any person that does this should be shot!). All in all if the system is set up right you should only be accessing info that you need to access and you should have the capability to access it anyway. If you are attempting to access info and you can't it should be because you probably don't need that info and if you really do, then it should be a simple procedure to get access to it.
jik@athena.mit.edu (Jonathan I. Kamens) (06/14/90)
In article <207@rdb1.UUCP> root@rdb1.UUCP (Robert Barrell) writes: > Also, what about the CBW (Crypt-Breaker's Workshop) programs? I >believe they are only for entire files that have been encrypted, but >don't know if they are useful for passwords or not. CBW is designed for breaking the encryption on files that were encrypted using crypt(1). The crypt program *does not* use DES encryption, which is what the crypt(3) function uses. Instead, it uses "a one-rotor machine designed along the lines of the German Enigma, but with a 256-element rotor" (that's from the man page). In other words, CBW isn't useful for breaking password encryption. Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8495 Home: 617-782-0710
kdq@demott.COM (Kevin D. Quitt) (06/14/90)
In article <EDP.90Jun13093936@pertsovka.east.sun.com> edp@east.sun.com (Ed Pendzik {Prof Services} Sun Rochester) writes: > >please show how a lunatic in CA has anything to do with computer security. OOH! OOH! I KNOW! Somebody broke into his account, and deleted all his files, and he didn't have a backup, so... 8-{)} -- _ Kevin D. Quitt Manager, Software Development 34 12 N 118 27 W DeMott Electronics Co. 14707 Keswick St. Van Nuys, CA 91405-1266 VOICE (818) 988-4975 FAX (818) 997-1190 MODEM (818) 997-4496 Telebit PEP last demott!kdq kdq@demott.com 96.37% of the statistics used in arguments are made up.
akhale@chamomile.uucp (Abhijit Khale) (06/14/90)
In article <207@rdb1.UUCP> root@rdb1.UUCP (Robert Barrell) writes: > Also, what about the CBW (Crypt-Breaker's Workshop) programs? I believe >they are only for entire files that have been encrypted, but don't know if they >are useful for passwords or not. > CBW helps to break crypt(1) which uses a comparitively simple encryption algorithm. crypt(3) which is used by the password encryption algorithm is based on the DES which is well-nigh impossible to break. Abhijit
gwyn@smoke.BRL.MIL (Doug Gwyn) (06/14/90)
In article <207@rdb1.UUCP> root@rdb1.UUCP (Robert Barrell) writes: > Also, what about the CBW (Crypt-Breaker's Workshop) programs? I believe >they are only for entire files that have been encrypted, but don't know if they >are useful for passwords or not. No, passwords are encrypted using a different algorithm. crypt(1) is not hard to break; crypt(3) is quite hard to break.