On Wed, 2006-06-07 at 21:11 +0200, Bas Wijnen wrote: > > Similarly, a server cannot tell if the user is actually logged in at a > > terminal at all -- it can only tell that it has received input from a > > connection that appears to constitute an authentication sequence. > > The assumption is that only the user can authenticate. If this assumption is > not true, then there is something wrong with the authentication mechanism, > which should be fixed.
Nonsense. The assumption is universally false. The computer *never* knows whether the user has authenticated. What the computer knows is that characters have been sent from a device. The assumption that these characters originated from a user is just that -- an assumption. This is not a question of bugs. It is a consequence of the absence of an end-to-end trusted path. > > Your original statement was that the system could trust the terminal. In > > many circumstances this is "true enough" in practice that we can get > > useful work done, but it definitely is NOT true if we are dealing with > > anything sensitive. > > Well, it depends on what machines we're talking about. For desktop computers, > which are inside the home of the owner, it is very reasonable to let the owner > be responsible for the hardware security (that is, that no hardware sniffers > are installed). If you believe this, you have not been reading the US newspapers. It is quite amazing how many keyboard sniffers are getting installed (amazing and, I might add, depressing). > > In particular, it is not true for credit transactions. > > You mean money machines? No, in that case the terminal design is very hard, I > can imagine. However, as I said, that's not a software problem. :-) No, I simply meant credit transactions on the web from a home computer. Yes. ATM terminals are hard to design well. Banks accept a very high rate of loss per ATM as a cost of doing business. Sadly, this rate of loss remains lower than the cost of paying humans to work at the bank. shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
