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

Perry E. Metzger                pe...@piermont.com

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Reply via email to