Finding Passwords

Jaye Mathisen mathisen at dali.cs.montana.edu
Tue Sep 25 00:00:45 AEST 1990


In article <12165 at chaph.usc.edu> jeenglis at alcor.usc.edu (Joe English Muffin) writes:
|cgy at 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 "<hostname> 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 <break> 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 <break>, 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.



More information about the Comp.unix.internals mailing list