[cryptography] preventing protocol failings

Marsh Ray marsh at extendedsubset.com
Fri Jul 22 17:29:30 EDT 2011

On 07/22/2011 01:17 PM, Zooko O'Whielacronx wrote:
> From http://www.hpl.hp.com/techreports/2009/HPL-2009-53.pdf :
> “1. INTRODUCTION Most people agree with the statement, ―There is an
> inevitable tension between usability and security. We don’t, so we
> set out to build a useful tool to prove our point.”
> If they've done what they claim (which I find plausible), then how
> could it be possible? Where does this "free energy" come from?

They could get it from optimizing things that were previously
unnecessarily cumbersome.

Or they could be hand-waving and pushing the problem off somewhere else.
Usually developers try to push it back on the user to be ignored:

> A webkey is displayed in the Webkey field after the user clicks Save.
> The user sends this webkey to the new Pal by whatever means the user
> desires, typically via a conventional email, much as one would send
> an email address. Users can prevent a third party who intercepts the
> webkey from impersonation attacks by confirming the webkey out of
> band, such as over the telephone, much as they would double check an
> email address. The recipient clicks "Create a Pal with a Webkey",
> fills out the form, inserts the webkey, and clicks Save. The
> difference between these two ways of creating a Pal avoids the
> confusion some early users had when they generated a webkey instead
> of using one they had been sent.

This doesn't sound like free security to me.

> I think it comes from taking advantage of information which is
> already present but which is just lying about unused by the security
> mechanism: expressions of intent that the user makes but that some
> security mechanisms ignore.

I like this direction of work, but I just don't see the word "attack" in
the paper enough times.

What does the user see when they *are* under attack and the server
authentication step fails?

How do the security properties change when the user clicks on a link in
a phishing email?

The design says
> A webkey is the moral equivalent of a password, but one the user
> treats as a bookmark and that controls access to a specific object

So what do you do when one of these webkey passwords eventually does get
disclosed? Can you revoke it or is is equivalent to the name of the

> For example, if you send a file to someone, then there is no need
> for your tools to interrupt your workflow with security-specific
> questions, like prompting for a password or access code, popping up
> a dialog that says "This might be insecure! Are you sure?",

Yeah that's lame.

> or asking you to specify a public key of your recipient. You've
> already specified (as part of your *normal* workflow) what file and
> who to send it to,

How do you specify "what file" without an existing server authentication

How do you specify "who" without presuming an existing user identity and
authentication infrastructure?

> and that information is sufficient the security system to figure out
> what to do. Likewise there is no need for the recipient of the file
> to have her workflow interrupted by security issues.

I think a system can still be moderately secure without interrupting the
normal workflow. But at first glance it looks to me like this HP system
has most of the security limitations of any other web browser email
client being operated by a typical user. In this case the user is told
that they don't have to "interrupt their workflow" for security concerns
(except perhaps to install the binary plugin).

> Again, the point is that *you've already specified*. The human has
> already communicated all of the necessary information to the
> computer. Security tools that request extra steps are usually being
> deaf to what the human has already told the computer. (Or else they
> are just doing "CYA Security" a.k.a "Blame The Victim Security" where
> if anything goes wrong later they can say "Well I popped up an 'Are
> You Sure?' dialog box, so what happened wasn't my fault!".)

Agreed. The programmer is successful as far as shifting blame, which is
actually a reasonable thing to do if you're thinking as an engineer
documenting an interface contract and fulfilling his side of it.

> Okay, now I admit that once we have security tools that integrate
> into user workflow and take advantage of the information that is
> already present, *then* we'll still have some remaining hard problems
> about fitting usability and security together.

Remember the attacker gets a vote in how "usable" the system really is
when he chooses to attack the user, which is exactly when it really
matters. What capabilities can he trick the (intentionally naive) user
into delegating? What can the user give away and how hard is it to clean
up afterwards?

- Marsh

More information about the cryptography mailing list