On Mon, 2004-08-16 at 17:55 +0100, James Wilkinson wrote:
> And if all else fails, the ssh client could
> (maybe it already does) insert some artificial random delays into
> transmissions coming from key entries.
For that to work, the client would have to recognise when the server
was asking for a password. That would mean deducing the intent of what
was displayed. OpenSSH clients don't interpret the display at all: they
just pass it on to the terminal. PuTTY, of course, has an integrated
terminal emulator, but it still only displays what is sent: it has
no notion of "su".
You misinterpreted. I said "coming from key entries". All the client
would need to know is if the input was coming from a terminal or not. No
reason (other than efficiency) to only protect passwords from such
sniffing.
Alternatively, of course, you could just drop these delays into all
communication. To be effective, you'd need enough delays that it might
be noticable over a slow connection. I've got ssh users over such
slow connections, and I can tell you they'd not be happy about it.
If you delayed only terminal input (as opposed to, say, tunneled
application data), I think the scale of the delays necessary to confound
potential sniffers would be small enough as to be imperceivable; and on
a slow connection these delays would not be your limiting factor anyway.
A cleaner solution would be to invent an API and a terminfo code for
programs to request passwords from a terminal, and terminals that would
know to prompt for a password and not send anything until Return was
pressed. If you patched su, sudo and passwd to use such a thing, and
PuTTY and several of the Linux xterms to understand the codes, you could
probably get enough momentum for most other vendors to jump on board.
The fact that this hasn't happened should tell you something -- notably
that it is a highly theoretical weakness, and none of the professional
paranoids are sufficiently worried.
Especially in the case of SSH, I have a feeling that you are correct.