Path: utzoo!attcan!uunet!aplcen!samsung!dali.cs.montana.edu!mathisen From: mathisen@dali.cs.montana.edu (Jaye Mathisen) Newsgroups: comp.unix.internals Subject: Re: Finding Passwords Keywords: security trusted_path Message-ID: <2469@dali> Date: 24 Sep 90 14:00:45 GMT References: <50845@brunix.UUCP> <12165@chaph.usc.edu> Organization: Montana State University, Dept. of Computer Science, Bozeman MT 59717 Lines: 29 In article <12165@chaph.usc.edu> jeenglis@alcor.usc.edu (Joe English Muffin) writes: |cgy@cs.brown.edu (Curtis Yarvin) writes: | |>You should be able to prevent this. SunOS (and thus likely BSD as well, |>though I don't know) make the first login prompt " login:", and |>switch to plain "login:" if an incorrect password is entered. This disables |>login trojans by making them unconcealable. | |Yeah, but by the time you realize that |login isn't displaying the right prompt, |it's too late to do anything. The password- |snarfer could also exec /bin/login instead of |exiting, which would make everything look |right (it's getty that displays the hostname, |etc., not login.) I haven't been following this whole discussion, but I though I'd mention that DEC is now providing with Ultrix 4.0, a "Trusted Path" feature. If a user hits on a system with tpath enabled, then the user is guaranteed to be getting a real login session... I may be not quite on the mark with the details, but I would guess it's something as simple as when getty sees a , it kills itself off, and let's init start up a new getty, thus aborting any processes (spoofers) on the line. I haven't tried it here yet, because we have too many DECServer 200's that are configured to use BREAK for all the special functions.