Petnames

Interesting paper:

Zooko’s Triangle argues that names cannot be global, secure, and memorable, all at the same time. Domain names are an example: they are global, and memorable, but as the rapid rise of phishing demonstrates, they are not secure.

Though no single name can have all three properties, the petname system does indeed embody all three properties. Informal experiments with petname-like systems suggest that petnames can be both intuitive and effective. Experimental implementations already exist for simple extensions to existing browsers that could alleviate (possibly dramatically) the problems with phishing. As phishers gain sophistication, it seems compelling to experiment with petname systems as part of the solution.

Tags: , , , , ,

Posted on February 8, 2006 at 11:25 AM • 44 Comments

Comments

Bruce Cleaver • February 8, 2006 1:05 PM

“…cannot be global, secure, and memorable, all at the same time.”

Strongly reminiscent of the engineers trilemma: good, fast, cheap. Pick two.

jmr • February 8, 2006 1:28 PM

Brains, beauty, personality, availability. Pick any two.

I remember reading about a project whose purpose was to make “permanent” but securely editable (as in, by the author with the key used to post the original) postings that had a secure namespace management system. Does anybody remember the name of it?

Anonymous • February 8, 2006 2:08 PM

Brains, beauty, personality, availability. Pick any two.

Sometimes, I think that “beauty” counts double there.

Theo Van Dinter • February 8, 2006 3:04 PM

Domain names are an example: they are global, and memorable, but as the rapid rise of phishing demonstrates, they are not secure.

This doesn’t actually make any sense. Receiving a mail that aims me at ebay-phish.com instead of ebay.com doesn’t make the domain ebay.com any less “secure”.

DJA • February 8, 2006 3:19 PM

Brains, beauty, personality, availability. Pick any two.

I’d always heard that one as “Attractive, available, sane.”

Shura • February 8, 2006 3:25 PM

@Theo Van Dinter:

The article says this:

“Securely Unique: This is means that the name cannot be forged or mimicked. A name can be forged if one can manufacture an exact duplicate of the name such that neither man nor machine can tell the difference. A name can be mimicked if one can make a name similar enough to fool the human being. In general, phishing depends on mimicry, not forgery. This difference becomes crucial later in the discussion.”

So there you have it – the fact that the fact that, for example, PayPal.com was registered did not mean that somebody else couldn’t come along and register PayPa1.com means that domain names are not securely unique according to the definition used here. Or take a hypothetical bank named “Acme Bank” or so, for example; they might have registered acmebank.com, but somebody else could conceivably come along and register acme-bank.com, or acme-banking.com, or anything other domain name that suggests that it’s associated with the actual Acme Bank (even though it’s not).

Victor Bogado • February 8, 2006 5:06 PM

@ 3ric johanson

It does work, since a member of the paypal site did already given paypal a petname (say he used the default ‘paypal’), the system will ask you to create a new petname and this in it self is suspicious.

It could even compare the keys of registered sites to check if there is a similar enought key and say explicity that this is not that site.

for instance say the first time I try to submit any information to a site the browser would, before sending any info, ask me to give a petname to it. It will sujest me one based on the link I used to get here and the main part of the URL (www.paypal.com would be sujested as ‘paypal’ for instance).

From now on the browser will refer the paypal site with my own petname, that only I know for sure and preferably it will be in a part of the gui that is not alterable by scripts or other stuff.

Now supose that I received an email saying that I should update my paypаl account, (notice the second “а” is not a latin “a” but a cyrilic “а”). Since the site do not yet have a petname it will show no petname in the ui, it could also attempt to match it’s key (url) to the list of known URLs that do have a petname, since it matches in all but one glyph, it could warn the user that this is not your known “paylpal”.

That is what I got from the paper, I must tell you that I did not got it in depth, since I read it in a hurry and it is a bit confusing sometimes.

Ari Heikkinen • February 8, 2006 5:09 PM

Well, to me arguing that DNS names aren’t secure because they’re too memorable is kind of silly. It’s much like arguing street adresses aren’t secure as they’re too easy to remember.

It’s like sometimes people forget that you cannot secure the whole world. Well, you probably could, in theory, but then it’d be like one big prison.

Mark S. Miller • February 8, 2006 7:27 PM

SDSI/SPKI implement “lambda-names” as opposed to “petnames”. Lambda-names occupy the same edge of Zooko’s triangle as to petnames, and helped inspire petnames. The lambda-name->key mapping is many-to-one, without any required support for a backwards mapping. The petname<->key binding is one-to-one, with a requirement that the backward mapping be supported.

What the paper says about conventional bookmarks applies to SDSI/SPKI: “As noted earlier, a true petname is a two-way mapping: any reference to the key is represented in the user’s world as the petname. However, lambda-names like bookmarks only map from the private name to the key, with no mapping back.”

Why “lambda-names” for the many-to-one, one-way naming concept? The lambda-name to key relationship is the same as the relationship of lexical variable names to pointers in a lexically scoped programming language: The variable names are human readable, and are unique only within an environment. The environment maps them to pointers which (within the world of the program’s implementation) are globally unique but not meaningful to humans.

How does SDSI/SPKI suffer from the lack of a backward mapping? As http://www.erights.org/elib/capability/pnml.html explains “But without a translation-on-introduction mechanism, humans can only participate in a second class way.” In other words, in SDSI/SPKI, humans can use human readable names to designate what they mean to software, but when communicating a designation to a human, the designation cannot be securely rendered in a human meaningful way.

Ari Heikkinen • February 8, 2006 7:38 PM

Just to add, I think pet names are actually even worse than bad passwords. There’s bunch of common pet names for cats and dogs for instance, that guessing one can be easy even trying manually.

Mark S. Miller • February 8, 2006 8:24 PM

Ari Heikkinen wrote:
“Just to add, I think pet names are actually even worse than bad passwords. There’s bunch of common pet names for cats and dogs for instance, that guessing one can be easy even trying manually.”

The security of petnames have nothing to do with unguessability. My petname for my bank is “bank”. How does that knowledge help you attack me?

Ari Heikkinen • February 8, 2006 8:51 PM

Ok, it’s petname, not pet’s name. I guess I’m getting too fast on assuming “silliness” these days whenever it’s anything security related.

peachpuff • February 9, 2006 1:55 AM

This sounds pretty neat, but the implementation should have a way to make the petnames portable. For example, you should be able to use the same petnames at work as at home without manually setting them twice. That’ll make a huge difference in how popular it gets.

Timothy Miller • February 9, 2006 6:28 AM

@ Mark–

To be honest, I don’t see SPKI/SDSI as limited in the way you assert. The essential point of SPKI/SDSI is that it is only uniqueness and “globalness” for human readable names that are incompatible. Since randomly-generated RSA keys are globally unique, the work concentrated on how to join local namespaces together in ways that allow meaningful communications between users.

As you note, in SPKI/SDSI humans talk with software via names in the human’s local namespace where each entity in that space is unambiguous; and software talks with software using RSA keys (ECC keys work too, and are demonstrably more unique) where all entities are globally unique.

The introduction problem is addressed two ways. First, local namespaces can be chained together, making it is possible to unambiguously refer to any entity named in any arbitrary local namespace in any other local namespace. This is very powerful by itself. In cases where no chain exists, the new entity can simply be named in the local namespace.

Yes, this allows someone who has never visited paypal.com to be fooled into accepting a different site and naming it “Paypal” in the local space. But this local name is easily distinguishable from the real paypal.com when it’s encountered: the RSA key is different, and software can tell. The reason I discount this issue is because introductions don’t occur in a vacuum; they have context of their own. Phishing attacks target well-known sites, not obscure ones, so they must overcome the existing local name. Under SPKI/SDSI, this is much more difficult.

Additionally, recall that phishing attacks are all credential-stealing attacks. If we pursue something like SPKI/SDSI naming for sites, we can easily use it for users as well. In fact, SPKI/SDSI is more suited for this kind of wide use because it relies on no central authority as X.509 does. If the user is participating with a site using public-key authentication, there is no credential to steal (as long as the user protects his private key). The phisher gains far less in a “successful” attack, in addition to being far less likely to be successful in the first place.

I bring this up because, under IPv6, we can use (practically unique) key hashes as the local address component. This is a really cool and very powerful idea; any given host can have a permanent address that it can prove it should hold. I don’t have the references handy, but if you google on IPv6 and cryptographically generated addresses, they should be easy to find.

Mark S. Miller • February 9, 2006 6:56 AM

I’m not sure what you are suggesting. Could you explain how SDSI/SPKI would handle the first “Ms. Jones” example at http://www.erights.org/elib/capability/pnml.html ? As I understand SDSI/SPKI, the receiver may have a binding from “Ms. Jones” to her public key, and have a binding from “Shirley” to that same public key. When a message comes in designating Ms. Jones by her public key, how is the receiver’s user agent to decide which one to display?

Note: I don’t think the problem I raise above is in any way deep. SDSI/SPKI could easily be enhanced to deal with it by adding some basis for choosing among these bindings.

I’ll respond to the rest once I understand your proposal.

Timothy Miller • February 9, 2006 8:52 AM

When you introduce the key you designate Ms. Jones to me, and I already have that key designated Shirley, the software presents that key to me as Shirley. Since I already know the key and have it bound to a name, my software uses that name with me.

Note that the software deals generally with the keys themselves; what you sent to me was the key. You may also send me an SPKI name certificate, but it’s not strictly necessary.

Now, I can refer to that key as “The key that Mark Miller named Ms. Jones” as well as by the local name “Shirley.” This is namespace chaining, and it can continue to arbitrary depth; “The key that Tim named Chris named Mark named Ms. Jones,” and so on.

Now, if I haven’t already bound an introduced key to a name (i.e., it’s unknown to me), I can accept you as an introducer. I can either refuse to create a local name and exclusively refer to that key through your namespace (“The key that Mark named Ms. Jones”) or I can bind a new name for my own namespace (“The key I named Shirley” or even “The key I named Ms. Jones because I trust Mark”) and use that name exclusively thereafter.

This points to SPKI/SDSI’s challenges: to practically use it we really needed a network of introducers (as well as a database of name certificates so that chains can be constructed). Introducers play a similar role as a CA plays in X.509, but we’re not limited to one point of trust per key; a given key can be introduced by any number of introducers. This is basically how PGP key trusts work, but SPKI/SDSI is not trying to associate unique human names to keys, which is where PGP has shortcomings.

Timothy Miller • February 9, 2006 8:53 AM

Mark–Maybe we can continue this in email. My ‘name link’ on this message is now a mailto: for your convenience. 😉

Alan • February 9, 2006 10:32 AM

This seems similar in principle to what Bank of America has recently employed on their online banking login. They call it SiteKey and you select a picture and text to display when you log in. Next login, after entering your ID, you are shown the pic and text prior to entering your password, thus verifying you are connected to the real BoA site.
The problem I have with the system is that I’m not sure if the pics are chosen randomly (e.g. I took the default it offered, many others may have the same pic) and I think most people pick obvious text associated with the pic (e.g. flower, bird etc.). These features may make it easier to foil. Whilst not quite as global as a petname-enabled browser, it does implement the two-way mapping of ID.

jmr • February 9, 2006 12:58 PM

@Alan

So, if there’s a 1 / 50 chance of the image being a “beach ball”, and you send a phishing email to 100,000 people, and 400 of them fall for it, and 8 of them actually use the beach ball, and 4 of those typed in “beach ball”, you can clean out 4 people’s accounts. That has the potential to be quite a bit of money.

Not bad.

Anybody know how many site key images there are?

jmr • February 9, 2006 12:59 PM

Also, I’m not counting how many people don’t verify the text precisely, or don’t verify the beach ball at all and just type in their passkey.

Alan • February 9, 2006 6:52 PM

@jmr

It’s a bit more sophisticated than I realised.
I just did a quick check and there are at least 250 different images available (possibly a lot more, I just got bored clicking next).
In addition when you login from a new computer (e.g. without the required cookie) it asks you to verify a previously set question (mother’s maiden name, first school etc.), prior to showing the site-key image and text. You have to tell it whether you plan to use this computer regularly for login or it won’t set the cookie.
So, even if there are just 250 images with easily guessed text you have still cut down on sucessful phishes by 250 times (assuming images are selected randomly by people and 250 people don’t pick the cute puppy) and you still have to guess the phishee’s first school, mother’s name etc, even if you successfully obtain their username and password. Of course, this assumes that you can’t forge the cookie and therefore just use their password as if you were on their designated computer (I have no idea how secure such a cookie might be).

piglet • February 10, 2006 12:42 PM

Maybe I’m slow today but I don’t see what problem is supposed to be solved here. When I use bookmarks to access important sites, it doesn’t matter how I chose the description of the bookmark as long as nobody can hack the bookmarks, right? On the other hand, if I am stupid enough to click on a phishing link, how would a petname system protect me against my stupidity? Could somebody please explain that to me?

piglet • February 10, 2006 2:12 PM

Could oyu elaborate, Timothy? What has DNS spoofing to do with the bookmarks on my computer, and why should pet name systems not be vulnerable to hijacking attacks?

Timothy Miller • February 10, 2006 9:23 PM

When you open a bookmark, you make a DNS request for an IP address assigned to that site name. An attacker with the right access can return you a bogus answer, directing you to an IP of his choice. As with phishing attacks, the new target is visually identical to the site you intended to go to, so you happily enter your username and password, which is simply collected by the attacker and then reused.

SSL is supposed to thwart this kind of thing, because the key of the site you’re redirected to will be different than the key of the original site, and under ideal circumstances your browser will alert you of this. However, humans deal with readable names, which are far from unique, and browsers allow users to click through the warning. If the attacker simply puts “Paypal, Inc.” (for example) in his site certificate, a very large percentage of users will simply click through the warning and continue to the phishing site.

SPKI/SDSI, and similarly petnames, don’t use names in the same way. The human names exist only in your software; the computer deals with larger, potentially globally unique keys (RSA keys are ideal for this). When browse to the site you named “PayPal,” the computer translates this to the key you’ve marked. If, when the site is contacted, another key is in use, the user is notified. In this case, however, since the key the site presented is unknown to you and contains no name assigned by the site owner, your software can tell you that this is not the site you expected to hit, or automatically take appropriate action (such as dropping the connection).

The difference between SPKI/SDSI and petnames is the nature of this mapping between names and keys. Petnames is attempting to assign human readable names in a way that will move between the namespaces of individuals, providing a measure of globalness in order to ease introduction. SPKI/SDSI eschews global human readable names altogether in favor of providing ways to link all the local namespaces together in an unambiguous way.

I’m still studying the petnames concept and its background material so I can more fully understand the concept, but as of right now I think that the SPKI/SDSI solution offers stronger protection to the user because of its discarding of global human readable names.

Timothy Miller • February 11, 2006 11:23 AM

I think this will be my final comment.

I believe that SPKI/SDSI solves the same problem being discussed by PetNames, and the general work behind it (E capabilities) but more elegantly and with greater security. SPKI/SDSI avoids the vulnerability associated with capturing a SwissNumber, and thus SPKI/SDSI authentication and authorization can take place in the open.

In a three-party example, consider that Carol has granted Alice a capability she wishes to transfer to Bob. In SPKI/SDSI, Carol creates a name certificate for Alice in her namespace, an ACL that points to that name, and then creates an authorization certificate for Alice.

Alice then delegates her capability to Bob’s key via an authorization certificate. When Bob contacts Carol, he gives Carol his public key, a private-key proof, and the authorization certificate Alice created. Carol verifies the chain from Bob’s key to her ACL (using Alice’s delegation certificate), and grants access.

Bob knows that he’s talking to Carol because he has a name certificate for Carol from Alice, and Carol provides her public key and a private-key proof as part of her interaction with Bob.

Note that there is no secret data involved here at all, other than the private keys of each participant, which are never revealed.

The additional advantage that SPKI/SDSI confers is that Carol, when granting Alice authorization, can deny Alice the ability to delegate that authorization. Alice can do the same to Bob. I’m not sure I see the same feature in E capabilities.

Tyler Close • February 13, 2006 5:24 PM

piglet – You are correct that accessing a site via a bookmarked https: URL provides phishing protection equal to that of accessing a site via petname. In fact, when used in this way, a petname is just a bookmark.

The special properties of a petname come into play when accessing a site by any means other than a local bookmark. For example, clicking on a link in a web page, in an email, or typing in a URL. In these scenarios, the petname tool will do the reverse lookup of finding a local bookmark that corresponds to the SSL certificate presented by the remote site. The petname tool will then clearly indicate what local name, or bookmark, the user has assigned to the remote site, if any. This indication makes it easy to recognize a trusted site, even though the user did not arrive at the site via a trusted link.

No matter how you arrive at a site, the petname tool provides a consistent display of the local name you have assigned to the currently displayed web site. By mapping global identifiers (SSL certificates) back into the user’s local namespace, the petname tool makes it easier for users to recognize and understand who they are talking to.

Tyler Close • February 13, 2006 5:39 PM

Actually, using a petname is still stronger than using a bookmarked https: URL, since the petname will catch a CA substitution attack. For example, if the site the user has petnamed uses a Verisign certificate, the petname will catch a phishing attack that tries to substitute a cheaper, fraudulently obtained, domain validated certificate. The bookmarked https: URL will provide no indication that anything is amiss.

piglet • February 13, 2006 7:26 PM

“No matter how you arrive at a site, the petname tool provides a consistent display of the local name you have assigned to the currently displayed web site. By mapping global identifiers (SSL certificates) back into the user’s local namespace, the petname tool makes it easier for users to recognize and understand who they are talking to.”

From what I understand, this kind of tool won’t prevent a stupid user from doing stupid things. Phishing attacks are really targeting the internet community’s “weakest links”, so I doubt that there is real benefit is such a system.

“When you open a bookmark, you make a DNS request for an IP address assigned to that site name. An attacker with the right access can return you a bogus answer, directing you to an IP of his choice.” This is more serious than phishing. Do you know whether this attack has been successfully employed?

Revenant • February 15, 2006 12:49 AM

@ piglet: DNS attacks have been carried out successfully, but not successfully used for phishing as far as anybody is aware.

This type of attack, when used for phishing, has been dubbed “pharming.”

Some example known DNS attacks (from the wikipedia entry on pharming, http://en.wikipedia.org/wiki/Pharming):

For example, in January 2005, the Domain Name for a large New York ISP, Panix, was hijacked to a site in Australia.

Secure e-mail provider Hushmail was also caught by this attack on 24th of April 2005 when the attacker rang up the domain registrar and gained enough information to redirect users to a defaced webpage.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.