Finding Passwords

Dan Bernstein brnstnd at kramden.acf.nyu.edu
Sat Oct 6 16:29:28 AEST 1990


In article <651 at puck.mrcu> paj at uk.co.gec-mrc (Paul Johnson) writes:
> >In article <8685 at mirsa.inria.fr> jlf at mirsa.inria.fr (Jean-Louis Faraut) writes:
> >> What about a two-ways authentication, modifying the getty program to
> >> oblige the computer to authenticate itself ?
> >Fails. As I've said before, you can't reliably *avoid* a Trojan Horse
> >unless you can reliably *detect* a Trojan Horse. If you don't have a
> >trusted path, the intruder can masquerade as you, forwarding enough of
> >the responses you supply to authenticate itself and then taking control
> >of your account.
> No it does not.

Let's settle on some terminology here.

A login spoof pretends to be login, but isn't connected to the real
login program. Barry's solution works here; Jean-Louis's solution works
here; even the dumb strategy of putting a hostname before the login:
lets the user detect a login spoof.

But I'm not talking about a spoof. I'm talking about a Trojan Horse. A
Trojan Horse pretends to be a *connection directly to your computer*,
but is actually a *connection through a hostile program to your
computer*. Read the paragraph of mine quoted above.

Challenge sequences don't work against a ``proper'' Trojan Horse.
Encryption doesn't work---though it can limit the damage that certain
types of Trojan Horses can do. *Nothing works*. Unless every
communications link provides explicit verification that you're talking
to who you think you're talking to, you *cannot* avoid a Trojan Horse.

> A plain trojan could not make the correct response:
> all it could collect would be the user's challenge.

That's a spoof. Read the paragraph quoted above that you're responding
to: I'm not talking about a spoof.

---Dan



More information about the Comp.unix.internals mailing list