March 13, 2007
@ 06:18 PM

Tim Bray has an excellent post entitled OpenID which attempts to separate hype from fact when it comes to the technorati's newest darling, OpenID. He writes

The buzz around OpenID is becoming impossible to ignore. If you don't know why, check out How To Use OpenID, a screencast by Simon Willison. As it's used now (unless I'm missing something) OpenID seems pretty useless, but with only a little work (unless I'm missing something) it could be very useful indeed.

Problem: TLS · The first problem is that OpenID doesn't require the use of TLS (what's behind URIs that begin with https:).
Problem: What's It Mean?
· Another problem with OpenID is that, well, having one doesn't mean very much; just that you can verify that some server somewhere says it believes that the person operating the browser owns that ID.
Problem: Phishing
· This is going to be a problem, but I don't think it's fair to hang it on OpenID, because it's going to be equally a problem with any browser-based authentication. Since browser-based authentication is What The People Want, we're just going to have to fight through this with a combination of browser engineering and (more important) educating the general public
The Real Problem · Of course, out there in the enterprise space where most of Sun's customers live, they think about identity problems at an entirely different level. Single-sign-on seems like a little and not terribly interesting piece of the problem. They lose sleep at night over "Attribute Exchange";once you have an identity, who is allowed to hold what pieces of information about you, and what are the right protocols by which they may be requested, authorized, and delivered? The technology is tough, but the policy issues are mind-boggling.
So at the moment I suspect that OpenID isn't that interesting to those people.

I've been thinking about OpenID from the context of authorization and sharing across multiple social networks. Until recently I worked on the authorization platform for a lot of MSN Windows Live properites (i.e. the platform that enables setting permissions on who can view your Windows Live Space, MSN Calendar, or Friends list from Windows Live Messenger). One of the problems I see us facing in the future is lack of interoperability across multiple social networks. This is a problem when your users have created their friend lists (i.e. virtual address books) on sites like Facebook, Flickr or MySpace. One of the things you notice about these services is that they all allow you to set permissions on who can view your profile or content.More importantly, if your profile/content is non-public then they all require that the people who can view your profile must have an account with their service. We do the same thing across Windows Live so it isn't a knock on them.

What I find interesting is this; what if on Flickr I could add as a contact then give Mike Torres permission to view my photos without him having to get a Yahoo! account? Sounds interesting doesn't it? Now let's go back to the issues with OpenID raised by Tim Bray.

The first thing to do is to make sure we all have the same general understanding of how OpenID works. It's basically the same model as Microsoft Passport Windows Live ID, Google Account Authentication for Web-Based Applications and Yahoo! Browser Based Authentication. A website redirects you to your identity provider, you authenticate yourself (i.e. login) on your identity providers site and then are redirected back to the referring site along with your authentication ticket. The ticket contains some information about you that can be used to uniquely identify you as well as some user data that may be of interest to the referring site (e.g. username). Now we have a high level understanding of how it all works, we can talk about Tim Bray's criticisms. 

On the surface it makes sense that identity providers should use SSL when you login to your account after being redirected there by a service that supports OpenID. However as papers like TrustBar: Protecting (even Naïve) Web Users from Spoofing and Phishing Attacks, SSL/TLS does little to prevent the real security problems on the Web today, namely Web page spoofing (i.e. Phishing) and the large amount of malware on user PCs which could be running key loggers. This isn't to say that using SSL/TLS isn't important, just that it's like putting bars on your windows and leaving the front door open. Thus I can understand why it isn't currently required that identity providers support SSL/TLS. However a little security is better than no security at all. 

What Does It Mean?
I agree with Tim Bray that since OpenID is completely decentralized, websites that support it will likely end up creating whitelists of sites they want to talk to otherwise they risk their systems being polluted by malicious or inconsiderate OpenID providers. See Tim Bray's example of creating which when queried about any OpenID beginning with that URI instantly provides a positive response without authenticating the user. This allows multiple people to claim for example. Although this may be valid if one was creating the OpenID version of BugMeNot, it is mostly a nuisance to service providers that want to accept OpenID.

Using susceptibility to phishing as an argument not to use OpenID seems like shutting the barn door when the horse has already bolted. The problem is that security conscious folks don't want users getting used to the idea of providing their username and password for one service whenever prompted by another service. After all, the main lesson we've been trying to teach users about preventing phishing is to only enter their username and password to their primary sites when they type them in themselves not when they follow links. OpenID runs counter to this teaching. However the problem with that teaching is that users are already used to doing this several times a day. Here are three situations from this morning where I've been asked to enter  my username and password from one site on another

  1. Connected Desktop Apps: Google Toolbar prompts me for my Gmail username and password when I try to view my bookmarks. The goal of the Google Account Authentication is to create a world where random apps asking me for my Gmail username and password by redirecting me to the Google login page is commonplace. The same goes for the the various Flickr uploader tools and Yahoo! Browser Based Authentication
  2. Importing Contacts: On Facebook, there is an option to import contacts from Yahoo! Mail, Hotmail, AOL and Gmail which requires me to enter my username and password from these services into their site. Every time I login to Yahoo! Mail there is a notice that asks me to import my contacts from other email services which requires me to give them my credentials from these services as well.
  3. Single Sign-On: Whenever I go to the Expedia sign-in page I'm given the option of signing in with my .NET Passport which happens to be the same username and password I use for all Windows Live and MSN services as well as company health site that has information about any medical conditions I may have.

Given the proliferation of this technique in various contexts on the Web today, it seems partisan to single out OpenID as having problems with phishing. If anything, THE WEB has a problem with phishing which needs to be solved by the browser vendors and the W3C who got us in this mess in the first place.

Attribute Exchange
This usually goes hand in hand with any sort of decentralized/federated identity play. So let's say I can now use my Windows Live ID to login to Flickr. What information should Flickr be able to find out about me from talking to Windows Live besides my username? Should I be able to control that or should it be something that Flickr and Windows Live agree on as part of their policies? How is the user educated that the information they entered in one context (i.e. in Windows Live) may be used in a totally different context on another site. As Tim Bray mentioned in his post, this is less of a technology issue and more a policy thing that will likely differ for enterprises versus "Web 2.0" sites. That said, I'm glad to see that Dick Hardt of Sxip Identity has submitted a proposal for OpenID Attribute Exchange 1.0 which should handle the technology aspect of the problem.

Disclaimer: This is not an endorsement of OpenID by Microsoft or an indication of the future direction of authentication and authorization in Windows Live. This is me brainstorming some ideas in my blog and seeing whether the smart folks in my reader base think these ideas make sense or not. 


Wednesday, March 14, 2007 12:59:19 PM (GMT Standard Time, UTC+00:00)

I also commented on Tim's post with some ideas.

Wednesday, March 14, 2007 1:23:12 PM (GMT Standard Time, UTC+00:00)
I agree with your points. I think OpenID is a very encouraging initiative and I welcome Microsoft's friendliness towards it.

One issue I think will be important that I haven't seen much coverage of is that of the lifetime of an OpenID. For OpenID to gain mass adoption, regular users need their ISPs or email providers to automatically grant them OpenIDs, as AOL are doing with AIM. The problem here is that if you leave AOL, you cannot guarantee that AOL/ACME ISP won't revoke your OpenID (as they may do with your email address). I think it will be important to solve this, or OpenID will degenerate to the same level of utility as email addresses for authentication (which is to say: useful until you change email address).

Another issue, touched on above, is that OpenIDs are quite similar to email addresses--they provide a unique identifier. Could OpenID be integrated into email so that you can send me an email just by knowing my OpenID? This may not be desirable--perhaps we should not dilute the meaning of OpenID. On the other hand, if the above problem is solved, piggybacking this would allow for lifelong "email" address. Of course, there is a possibly insurmountable entrenched base of reliance on email addresses, which could make such a goal nigh on impossible. How do you counter the fact that most places where you use your email address (e-commerce sites, for example) do email validation and any hacked on OpenID approach (*openid uri*@openid?) would probably fall foul of this?
Wednesday, March 14, 2007 3:04:06 PM (GMT Standard Time, UTC+00:00)
The value of SSL/TLS is not only to prevent phishing/spoofing, but also things like man-in-the-middle attacks. Remember that there are 2 parties involved here in this authentication flow: the identity provider and the relying party (the service the user wants to access).

TLS on the identity provider side will help users identify the identity of that ID Provider. You're right that this isn't a fool proof solution against phishing, but nothing is. Fighting spoofing is about educating users and giving them the tools to fight it. TLS combined with IE7's anti-phishing (for example) are undeniably better than one or the other (or neither).

TLS on the relying party side not only vouches for its identity as well, but also prevents any man-in-the-middle attacks that would allow capturing of the service ticket ("authentication ticket") and replayed by the attacker to impersonate a user.

Regarding the points 'What does it mean?', I agree that sites will create whitelists of who they trust. What this really means is that the OpenID identity provider list eventually won't be as large and open as it's currently sold-as. Using credit cards as an analogy, this is like the system moving towards Visa, Mastercard and American Express only. Would anyone accept a credit card from the "Bob's House 'o Credit" network vs. Visa?

I recently blogged about OpenID and a few criticisms I had which overlap with some of Tim Bray's comments:

Wednesday, March 14, 2007 3:44:04 PM (GMT Standard Time, UTC+00:00)
Thorough and very thought provoking.
Wednesday, March 14, 2007 3:47:21 PM (GMT Standard Time, UTC+00:00)
Could you please edit out my e-mail address? Some spambots are smart enough to figure that out...I knew of a couple that could get through that trick in late '99.
Thursday, March 15, 2007 3:26:09 AM (GMT Standard Time, UTC+00:00)
Trevin: [The value of SSL/TLS is not only to prevent phishing/spoofing, but also things like man-in-the-middle attacks.]

Yea yea... it's true, but I think that MIM attacks are either non-existent or extremely rare, as are "wiretaps". I've been around since the original RSA/Netscape daze when NS launched the wiretap scare. I've yet to see one, not that they don't exist. And I doube seriously that MIM attacks are for real even in unencrypted systems.

Question: How does one wiretap or interpose himself on the internet (short of hijacking the physical connection to the site(s))???

As for preventing phishing... I guarantee that a "man on the street" survey would reveal that most people mindlessly dismiss the "certificate domain doesn't match" and other alerts. A phisher need only negotiate a TLS connection with a clearly mis-matched cert and he'll get a usable percentage of live dummies.
Bob Denny
Thursday, March 22, 2007 5:16:45 PM (GMT Standard Time, UTC+00:00)
If the address isn't blocked, check out Liberty People Service for a solution to the social silos problem you hilite

Comments are closed.