Jonathan:
Hello! First off, my apologies for my perceived role
as "director of improvement prevention". :) Hope the discussion
proves at all useful.
> ...If the encrypted key from the server was
> sniffed (or retrieved by connecting to the server), it could be replayed
> to a client which (if it knew the key password) would then think the
> cracker was the real server.
Right, exactly. The cracker wouldn't even have to know the
plaintext of the key, they could just playback the ciphertext
directly.
> OK, so we're back to the question of server authentication at the
> client end. A user-entered password is not good enough, because any
> password short enough for a user to remember can be cracked in a
> relatively short amount of time by any recent personal computer, given
> that the algorithm is known...
Well, not really. My understanding is that you (and others)
want to add a layer to the initial VNC authorization so that the
client believes it is talking to a *specific* server, and the
server believes it is talking to *specific* client, and you want
to do this over an insecure channel *and* to a client that has
no permanent local storage. Easy. :)
My suggestion would be a one-time password for each
client-to-server connection. Ie, a SecureID card. Seen them? It's a
credit-card size calculator with a 6-digit readout. Every 10 seconds
the number changes. Your server knows the number and the sequence
(which is *not* an open-source algorithm) asks for it at login. So
what if it's intercepted on the way to the server, it's only "good"
for 10 seconds anyhow. I hated them when I first saw them, but have
grown to appreciate the capability. No permanent storage at the
client needed, either. Though they need their card at hand to login.
Which leads into my next point: this problem isn't that
complicated to solve for *if* there's longterm storage on the client.
Then you just utilize classic, tested, non-home-grown schemes such
as what SSH (or IPSec) does with pub-priv key pairs and DFE key
exchange.
-Scott
---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to [EMAIL PROTECTED]
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------
