Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!nrl-cmf!ukma!rutgers!netsys!vector!rpp386!jfh From: jfh@rpp386.Dallas.TX.US (John F. Haugh II) Newsgroups: comp.unix.wizards Subject: Re: Improving password security Summary: correct to crypt plaintext. Message-ID: <8724@rpp386.Dallas.TX.US> Date: 20 Nov 88 16:20:32 GMT References: <21670@pbhya.PacBell.COM> <27987@tut.cis.ohio-state.edu> Reply-To: jfh@rpp386.Dallas.TX.US (John F. Haugh II) Organization: River Parishes Programming, Dallas TX Lines: 23 In article <27987@tut.cis.ohio-state.edu> jgreely@banjo.cis.ohio-state.edu (J Greely) writes: >point by point: >1. break the plaintext: trivial to do, if I can read libc.a on your > system. Since crypt is a standard library function, the object > file is open to anyone who wants it. Your secret plaintext is > secret only so long as no one is allowed to use the crypt function. No, you can call setkey() from inside of login(1). Then the cracker has to be able to read login(1). If you allow the bad guy to read login, you lose. If you are running shadow password files and you let the bad guy read that, then you lose as well. But in the normal case you would have to be root to read the files, or have physical access to the dump tapes or system console [ to break in at single user ]. Greely is on the right track - you can't just add one feature [ new plaintext ] and expect that to solve all your problems. -- John F. Haugh II +----------Quote of the Week:---------- VoiceNet: (214) 250-3311 Data: -6272 | "Okay, so maybe Berkeley is in north- InterNet: jfh@rpp386.Dallas.TX.US | ern California." -- Henry Spencer UucpNet : !killer!rpp386!jfh +--------------------------------------