pmaniac@walt.cc.utexas.edu (Noah Friedman) (06/03/90)
In article <6703@blake.acs.washington.edu> mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes: >... There are lessons to be learned, starting with the >abolishment of /etc/passwd and user access to the encryption >algorithm. I don't know that this is necessary. While it's possible that someone already has worked out a way to reverse DES, having access to /etc/passwd is quite useful. A number of my programs use information in this database, including the password field, so that other users can use their own passwords for various options while running my programs. If DES is breakable, then a new algorithm needs to be implemented. And users should be encouraged to choose good passwords, otherwise it doesn't matter what encryption mechanism is used. It's probably already been mentioned, but there is no good way to hide the encryption algorithm. Even if it's hardcoded into the kernal, it can always be disassembled. Noah Friedman pmaniac@ccwf.cc.utexas.edu
wcs) (06/05/90)
In article <28764@ut-emx.UUCP> pmaniac@walt.cc.utexas.edu (Noah Friedman) writes: ]In article <6703@blake.acs.washington.edu> mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes: ]>... There are lessons to be learned, starting with the ]>abolishment of /etc/passwd and user access to the encryption ]>algorithm. ]/etc/passwd is quite useful. A number of my programs use information ]in this database, including the password field, so that other users ]can use their own passwords for various options while running my programs. /etc/passwd has become the traditional location for user-info other than passwords, so of course it needs to be kept, but I agree with the shadow-password approach that puts (encrypted) passwords in a non-world-readable file. Yes, this means that YOUR software can't use the real password, but this is good - I'm not going to trust my real password to non-system software, because of the increased risk of trojan horses and insecurity; terminal-lockers and such get their own passwords. ]If DES is breakable, then a new algorithm needs to be implemented. And ]users should be encouraged to choose good passwords, otherwise it ]doesn't matter what encryption mechanism is used. The point of the modified-DES used by UNIX is that it isn't the same as the real DES, so a real-DES breaker won't work, and a fast hardware implementation of real-DES will make it hard to search for obvious passwords. Unfortunately, though, people have gotten 10-fold speedups in password encryption through software, and hardware is 1-2 orders of magnitude faster than the old PDP-11 days (much more, if you have a network of machines to bum cycles off of). So DES isn't real secure enough either, given readable passwords. -- Thanks; Bill # Bill Stewart AT&T Bell Labs 4M312 Holmdel NJ 201-949-0705 erebus.att.com!wcs # Actually, it's *two* drummers, and we're not marching, we're *dancing*. # But that's the general idea.
sms@WLV.IMSD.CONTEL.COM (Steven M. Schultz) (06/06/90)
>From: att!cbnewsh!wcs@ucbvax.Berkeley.EDU (Bill Stewart erebus.att.com!wcs) >References: <6703@blake.acs.washington.edu>, <28764@ut-emx.UUCP> > > /etc/passwd has become the traditional location for user-info > other than passwords, so of course it needs to be kept, > but I agree with the shadow-password approach that puts > (encrypted) passwords in a non-world-readable file. just a "thought" - if the (shadow)file is non-world readable and the system is administered "correctly" then why bother with encryption at all ;-) Steven
drears@PICA.ARMY.MIL ("Dennis G. Rears ", FSAC) (06/08/90)
"Steven M. Schultz" <sms@wlv.imsd.contel.com> writes: > >>From: att!cbnewsh!wcs@ucbvax.Berkeley.EDU (Bill Stewart erebus.att.com!wcs) >>References: <6703@blake.acs.washington.edu>, <28764@ut-emx.UUCP> >> >> /etc/passwd has become the traditional location for user-info >> other than passwords, so of course it needs to be kept, >> but I agree with the shadow-password approach that puts >> (encrypted) passwords in a non-world-readable file. > > just a "thought" - if the (shadow)file is non-world readable and the > system is administered "correctly" then why bother with > encryption at all ;-) Just in case one of the system admins is a bad guy or becomes a bad guy. I have three passwords for 30+ systems of which I only administrate 12 of them. If my password was available in the clear to system administrators on the other machines, they would have my passwords to all my accounts which is not a good idea. Also, what do you do when you fire a system administrator for bad conduct? If he had access to those clear passwords, every password would have to be changed. Dennis
sms@WLV.IMSD.CONTEL.COM (Steven M. Schultz) (06/08/90)
Dennis: >From drears@PICA.ARMY.MIL Thu Jun 7 13:16:46 1990 >>"Steven M. Schultz" <sms@wlv.imsd.contel.com> writes: >> just a "thought" - if the (shadow)file is non-world readable and the >> system is administered "correctly" then why bother with >> encryption at all ;-) > > Just in case one of the system admins is a bad guy or becomes a >bad guy. I have three passwords for 30+ systems of which I only >administrate 12 of them. If my password was available in the clear to >system administrators on the other machines, they would have my passwords >to all my accounts which is not a good idea. Also, what do you do when >you fire a system administrator for bad conduct? If he had access to >those clear passwords, every password would have to be changed. i thought i was being only semi-serious... guess i didn't make that clear enough. the thought at the time was that the file being non-world readable excludes any one BUT a sysadmin from even knowing if there is a password present, much less whether it's encrypted or not. besides the sysadmin is being trusted not install password snarfing versions of programs, isn't he? after obtaining (or already posessing) sufficient privs to read the "non-world readable file" a person (sysadmin or badguy) neither knows nor cares what passwords are - at that point the person can do anything he wants to. do the other sysadmins have sysadmin privs on the system(s) you administer? if not, then they wouldn't be able to read the "non-world readable" file in the first place. if they do have privs on your systems, then they can do anything you can and don't need to know the passwords anyhow. you mean you don't change passwords when sysadm types leave (especially when they're TOLD to leave)? when someone is as trusted a capacity as that leaves (on bad terms especially) i'd think that there'd be a fair amount of concern over possible dummy privd account left behind, and the like. no, i'm not advocating removal of encryption. Steven
smb@ulysses.att.com (Steven Bellovin) (06/08/90)
In article <9006060704.AA02343@WLV.IMSD.CONTEL.COM>, sms@WLV.IMSD.CONTEL.COM (Steven M. Schultz) writes: > just a "thought" - if the (shadow)file is non-world readable and the > system is administered "correctly" then why bother with > encryption at all ;-) Go back and read the Morris/Thompson paper. Basically, files can leak, due to carelessness, bugs, hard-copy terminals, backup tapes, etc.
barmar@think.com (Barry Margolin) (06/08/90)
In article <9006060704.AA02343@WLV.IMSD.CONTEL.COM> sms@WLV.IMSD.CONTEL.COM (Steven M. Schultz) writes: >just a "thought" - if the (shadow)file is non-world readable and the >system is administered "correctly" then why bother with >encryption at all ;-) I'm not sure how non-serious that smiley represents. The serious answer is that even system administrators should not be able to find out a user's password. Sure, they don't need to know the user's password to violate the user's files. But if they know someone's password then they could accidentally (or through coercion) divulge it to someone else. Also, two levels of protection are better than one: if the file is accidentally made readable it is still encrypted. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
jc@minya.UUCP (John Chambers) (06/12/90)
In article <37166@think.Think.COM>, barmar@think.com (Barry Margolin) writes: > In article <9006060704.AA02343@WLV.IMSD.CONTEL.COM> sms@WLV.IMSD.CONTEL.COM (Steven M. Schultz) writes: > >just a "thought" - if the (shadow)file is non-world readable and the > >system is administered "correctly" then why bother with > >encryption at all ;-) > > I'm not sure how non-serious that smiley represents. The serious answer is > that even system administrators should not be able to find out a user's > password. Sure, they don't need to know the user's password to violate the > user's files. But if they know someone's password then they could > accidentally (or through coercion) divulge it to someone else. Some years back, I saw an enlightening instance of all of the above. The participants shall remain nameless; the OS was Univac's EXEC8 on the 1108, for which every file had both a read and a write password. The system stored these internally in an unencrypted form, and one of the local games was to try to find holes in the system that let one access them. One of the holes was intentional: There was a system utility that would list files and their passwords, so that an administrator could delete files. One administrator was rather unpopular with users; and one day he got a bunch of guys in the EE and physics departments especially mad at him, so they changed their files to have a read password that was a well-known sexual verb starting with 'f', and a write password that was his name. They took no further action. At the next campus-wide users-group meeting, he got into a dispute with some of them, and in the heat of the moment, he made some rather disparaging remarks about the nature of people who would use obscene insults about him as their passwords. They didn't respond. The next day, they all wrote letters to his superiors complaining about the fact that he had, in a public meeting, made statements that enabled listeners to guess the passwords on their files. It was perhaps just a coincidence, but in very short order he no longer worked there. Myself, I was satisfied with finding one way to do raw disk I/O that showed a few such passwords, then I went on to more interesting work. -- Uucp: ...!{harvard.edu,ima.com,mit-eddie.edu}!minya!jc (John Chambers) Home: 1-617-484-6393 Work: 1-508-952-3274 Cute-Saying: It's never to late to have a happy childhood.