Connection caching?

[Jefferson Ogata]

Darren Tucker wrote:
> Jefferson Ogata wrote:
>> The former is what OTP is supposed to prevent.
> 
> Unless your OTP authenticates exactly one *command*, it won't stop a 
> compromised client from injecting an extra command into an already 
> authenticated login session.
> 
> Your original statement was "You're advocating a mechanism that renders 
> one-time password useless against a remote client compromise."  What I'm 
> saying is that even with your proposed modification, it's still useless 
> against remote client compromise.

You wrote "useless", where the correct wording would be "useful but not totally 
secure."

>  > The latter requires an attacker of unusual skill.
> 
> Not necessarily.  Trivial example: set the user's login shell to 
> "screen" on the machine running the ssh client, let them log in then 
> kill their incoming TCP connection and resume their screen session.

All of your scenarios (change user shell, hack client, etc.) are substantially 
more complex than:

1. Get user shell somehow.
2. ssh to anywhere the user is /already logged into/ without a passphrase, 
one-time password, fixed password, or /any authentication token whatsoever/. Do 
this as many times as you like.

In this scenario, the user could have authenticated a month ago. You seem to be 
assuming the attacker will have many opportunities to piggyback on live 
authentications, while I'm concerned about latent sessions providing a way to 
bypass authentication altogether.

>> I keep mentioning OTP here...
> 
> See above.  A compromised client can do nasty things after OTP 
> authentication, whether it's limited to a single session or otherwise.

Again, these scenarios require a window for the intruder to prepare an attack, 
and require modification of system configure or user profile, either of which 
might be detected, and in any case, the user has to authenticate /after/ the 
attacker has done his thing. Any attempt to hijack an already authenticated 
session after the fact requires, as I said, an advanced attacker, not just some 
idiot who can type "ssh bozo at victim" and get in because bozo logged in to victim 
six weeks ago and left a shell running.

>> Lazy users will do some of those things. But they won't typically scan 
>> a hardcopy S/KEY password list in and post it on a web page. If they 
>> do, they're not being lazy any more.
> 
> That's true.  My point was that they can if they want to and the server 
> can't stop it.  Even with the changes you propose, a compromised client 
> can run commands on the server after authentication and the server can't 
> stop it.

No, the server can't stop it completely. But a user's being able to exceed the 
limitations of sshd because he has an unrestricted shell is vastly different 
from sshd not providing hooks to limit authorization.

>> It is a reasonable expectation for an admin to be able to say: one 
>> authentication authorizes one session. If the admin wants to relax 
>> that control, fine, but it needs to be discretionary.
> 
> If "session" == "SSH session" that's what you've got now.  What we're 
> disagreeing about is the value of making additional restrictions within 
> a single SSH session, for the reasons listed above.

By session, I mean a remote shell or command (albeit composite) invocation, 
obviously.

-- 
Jefferson Ogata <Jefferson.Ogata at noaa.gov>
NOAA Computer Incident Response Team (N-CIRT) <ncirt at noaa.gov>