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