[cap-talk] "Secure Bookmark" terminology and Phoolproof Phishing Preventing from CMU

[Mark S. Miller]

Eric Jacobs wrote:
> On Thu, 07 Sep 2006 19:35:17 -0700
> "Mark S. Miller" <markm at cs.jhu.edu> wrote:
> 
>> Your text above clearly states "user-assigned", but you still think spoofing 
>> is an issue. Why does it matter if an attacker correctly guesses that my 
>> petname for Amazon.com is "Amazon"? What attack does this enable?
> 
> It still enables spoofing of the UI - e.g., simulating a pop-up window. 

The attacker would need to get the user to mistake the attacker's pop-up for 
the petname tool display. Petname systems do indeed rely on trusted path -- 
the user needs to be able to distinguish the rendering of a petname by his 
user agent from pixels rendered by the attacker. This is a valid criticism of 
petname systems when deployed on current legacy platforms. Perhaps this is 
what the authors have in mind?


> This
> can probably be resolved, but I'd think it would take a great deal of
> redesigning GUI systems from a security perspective. 

Yes. The issue is not whether the attacker can guess the petname -- petname 
systems assume this. The issue is whether there's a trusted path.

In any case, the next paragraph of their paper states:

# Dhamija and Tygar propose Dynamic Security Skins (DSS) to enable a user to
# authenticate the server [10, 9]. In their system, a server opens a
# user-customized popup window that displays an image only the correct server
# can produce. Similar to YURL, this approach relies on the user to perform
# the verification.

Ignoring the "Similar to" above, DSS can provide a degree of trusted path on 
legacy platforms, and they indeed rely on the attacker not being able to guess 
the skin. On legacy platforms, under some plausible assumptions, one could use 
DSS to provide an adequately trusted path for use of a petname system. The 
combination would rely *only* on the attacker not being able to guess the 
skin. If they can't, then it doesn't matter whether they guess the petname.


> In addition, I expect
> that users will need _some_ incentive for making sure they are spoof-proof
> (kinda like a good driver's discount, eh?)

Perhaps, but for incentives to be effective, it must first be possible for 
users to operate securely.


> Passwords are the real problem though. If they can be replaced or augmented
> with crypto, as this project is doing, I think that would improve security in
> a big way.

Yes.


>> For more on petnames, please see 
>> <https://www.financialcryptography.com/mt/archives/000499.html>.

See also <http://www.w3.org/2005/Security/usability-ws/papers/02-hp-petname/> 
and section 3.5 of my thesis <http://www.erights.org/talks/thesis/>.

>> (Note: when 
>> discussing petname systems, "nickname" refers to a distinct concept. To avoid 
>> confusion, please do not refer to petnames as nicknames. Thanks.)
> 
> What's the difference?

Petnames and nicknames are both human meaningful.

Petnames are context dependent -- Alice and Bob may each have their own 
petname for Carol, perhaps "Mom" and "Honey" respectively, and are chosen by 
them. Carol's nickname is the name she says she goes by, perhaps "Carol". 
Carol's nickname is context-free -- as in when she makes her choice of "Carol" 
public.

Petnames are securely collision free -- Alice maintains her own petname 
mapping so that only Carol is listed as her "Mom". OTOH, many people may 
choose the nickname "Carol", so they are not collision-free.

Nicknames are useful for discovery, as when you google for "Don" (try it). 
Alan's Client Utility used nicknames for discovery. Once introduced by a 
discovery service to an entity allegedly with the nickname "Don", you can 
determine if this is indeed the nickname of the entity you've been introduced 
to by asking it "Do you go by Don?". A "yes" authenticates the nickname, since 
a nickname as designator cannot provide any further assurance. However, once 
discovered, you can corroborate the discovery by trying to find a petname path 
from yourself to the same entity (such as "Stanford's Don"), at which point 
you have some assurance about who or what you've discovered.

Lambda names are like petnames in that they are human meaningful, chosen by 
the user, and securely collision-free within the user's context: if "Mom" is 
Alice's lambda name for Carol, then it still designates only Carol. The 
difference is that lambda names are only used to designate, whereas petnames 
are also used to indicate what has been designated. Lambda names can therefore 
be many-to-one, so Alice might also use "Mrs. Jones" as a lambda name for 
Carol. When Alice says "Mom" to her user agent, it's still unambiguous who she 
means. However, if Carol's identity needs to be communicated to Alice, it 
would now be ambiguous how her user should render this to her. (This isn't 
fatal -- for example, Alice lambda names may be implicitly prioritized, or the 
user agent could show all matches. But it is a difference.)

-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM