On Mon, 2 Aug 2010 16:20:01 -0500 Nicolas Williams <nicolas.willi...@oracle.com> wrote: > But users have to help you establish the context. Have you ever > been prompted about invalid certs when navigating to pages where > you couldn't have cared less about the server's ID? On the web, > when does security matter? When you fill in a field on a form? > Maybe you're just submitting an anonymous comment somewhere. But > certainly not just when making payments. > > I believe the user has to be involved somewhat. The decisions the > user has to make need to be simple, real simple (e.g., never about > whether to accept a defective cert). But you can't treat the user > as a total ignoramus unless you're also willing to severely > constrain what the user can do (so that you can then assume that > everything the user is doing requires, say, mutual authentication > with peer servers).
There are decisions, and there are decisions. If, for example (and this is really just an example, not a worked design), your browser authenticates the bank website using a USB attached hardware token containing both parties credentials, which also refuses to work for any other web site, it is very difficult for the user to do anything to give away the store, and the user has very little scope for decision making (beyond, say, deciding whether to make a transfer once they're authenticated). This is a big contrast to the current situation, where the user needs to figure out whether they're typing their password in to the correct web site etc., and can be phished into giving up their credentials. You can still be attacked even in an ideal situation, of course. For example, you could still follow instructions from con men telling you to wire money to them. However, the trick is to change the system from one where the user must be constantly on the alert lest they do something wrong, like typing in a password to the wrong web site, to one in which the user has to go out of their way to do something wrong, like actively making the decision to send a bad guy all their money. Perry -- Perry E. Metzger pe...@piermont.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
