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