[ On Wednesday, February 3, 1999 at 20:27:40 (-0800), Joe Rhett wrote: ]
> Subject: Re: transfering files back along an existing connection
>
> A hardware-based device which generates the right answer based upon a
> challenge, a secret key, some algorhythm is NOT vulnerable to this. The
> answer never remains the same, and the key is never stored on the client
> machine in any fashion.
Unless someone guesses the pseudo-random number generation algorithm and
the starting position (seed), as is used by many hardware based
challenge response systems. Not too unsurprisingly this hasn't been
all that hard to do for some well known "crypto" calculators. I've
personally seen it done twice on two very un-related devices. S/Key, if
used incorrectly, is even less secure because the number of
implementations of the "calculator" are so wide-spread and easily
available (and of course because it's "open").
> > program), entering data to the machine would be like sending
> > email to the owner of the machine. If the machine's
> > owner is a bad guy, you are in effect allowing
> > the bad guy to see what you writing.
>
> Right. Which makes remote access from untrusted machines functional and
> accepting for reading e-mail, updating logs of work done for the client, or
> perhaps transfering files back to our site for analysis, but useless for
> any situation where you need to be typing passwords and such. This is both
> known and documented for all users in our environment.
>
> I spent many hours trying to explain this concept to Greg, and he
> never got it. You've managed to do so in 2 messages - congrats :-)
Hmmm... Well, actually it seems to me that he proved *my* point, not
the other way around.
Anyway, just to re-iterate, if you don't trust the client machine (and
it's hard disk and user-interface peripherals), then you cannot trust
any user connecting from it, *REGARDLESS* of what level of external
authentication they're able to pass. Go read the article about nasty
self-hiding LKMs in Phrack #51 as one simple way of getting hooks into a
system that would permit it to do damn near anything behind your back
down your so-called "secure channel". They could give you their left
arm and their first born and you still can not trust their connection.
The authentication and encryption happens far far far too late to
protect the trusted network at the other end. Typing passwords from an
un-trusted machine should be the least of your worries -- I would hope
that only the truely gullible would fall for that trick.
Iff you're booting the machine from your own SSH'ified floppy or CD-ROM,
etc., then maybe you'll be OK because the level of risk associated with
a threat that'll go to the extent of modifying system (eg. firmware) is
relatively low for most uses (in which case you really do *not* need
hardware-based challenge-response systems to try to make your
authentication scheme more secure -- the floppy's copy of an authorized
RSA private key is just as secure as any "crypto" card, so long as
you've not opened any files or programs from the system's hard disk).
But hacked hardware is not out of the question -- it just depends on
what you consider an "acceptable" level of risk. If the threat is
great, then you must carry your own physically secured laptop on-site
and *never* *ever* use an un-trused computer to connect to a trusted
network, not by any means whatsoever (and of course *never* *ever*
authorize an untrusted client to connect to your network). Again in
this case so long as you trust your laptop then the RSA private key
stored in it is of adequate security (assuming you're using SSH from
it). Additional authentication is simply a way of ensuring that theft
of the laptop's RSA key is not sufficient to break your network, but if
you're really under this much threat then you probably shouldn't be
using public networks in the first place. (I.e. it *is* possible to
have too much security.)
In fact if the risk is high then you can't even use an untrusted machine
to send e-mail, never mind read it. You can use it to transfer files,
provided you decrypt and authenticate them on a trusted machine, but
that's about it. (In that case it's no different than any other part of
the untrusted network you retrive a file over.)
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
