On Mon, 8 Feb 1999, Greg A. Woods wrote:

> You really *must* completely trust the client computer, even if only for
> a limited duration of time.  Period.

This is not correct, as I have shown. Your claim depends on the assumption
that "once authenticated the user is compleatly trusted". 

> The problem is that even one open connection is enough to permit the bad
> guy to do nasty things behind your back.  You cannot assume that that
> what you type and what you see is all that's passed over the connection.
> Remember there's an untrusted operating system between your user and the
> SSH process that's authenticated him or her and which is protecting the
> authorized session from attack on the network.

No, see below.

> This is not going to allow you to trust the client computer any more
> than you already must to allow the initial connection.

Yes it will - it guarantees that the intruder is limited in time to the
time that the user is actually logged on. After that, presumably all the
processes will be killed etc. Various nasty modifications may already have
been done to the persistant state of the host (i.e. files etc), but since
nothing is active you have drastically limited the damage that can be
done.

> So long as you remove authorization from the server then no matter what
> the client remembers it will be useless in the future.  That's what I
> meant by not having to trust the client forever -- just for the duration
> of use.  (Of course "PasswordAuthentication no" might be a prerequisite
> in this case if you allow reusable passwords inside your trusted
> network.)

So every time I use a computer I have to change my rsa key on all other
clients? Or how am I supposed to compensate for the fact that my
rsa+passphrase have been compromised once? Storing any form of reusable
authentication token (such as rsa key+passphrase) on a client means that
security may be compromised in the future.

I'll reiterate: hardware tokens offer two modes of improved security. The
most usable is that it limits the time you need to trust the client to the
logoff moment. Not trusting the machine while logged on requires a much
better protection in depth, but is still not impossible, only
rather cumbersome to use.

Peter
--
Peter Svensson      ! Pgp key available by finger, fingerprint:
<[EMAIL PROTECTED]>    ! 8A E9 20 98 C1 FF 43 E3  07 FD B9 0A 80 72 70 AF
<[EMAIL PROTECTED]> !
------------------------------------------------------------------------
Remember, Luke, your source will be with you... always...

Reply via email to