WHAT IS OPENID FOR?

Blogger: Bob Blakley

There’s been a bit of a dust-up over OpenID recently in the blogosphere. First Eugene and Vlad Tsyrklevitch published a paper at BlackHat 2007 outlining a bunch of weaknesses in OpenID. Then Stefan Brands amplified the critique in a long blog post. David Recordon fired back in a post of his own, in which he expresses confidence that OpenID 2.0 will fix all of OpenID’s problems. I have less confidence than David, but I’ll leave that topic for later. What I’d like to do first is talk about getting the horse before the cart.

What I’d really like to see, as a security guy, is a problem statement and a risk analysis. Specifically, before we start arguing about whether OpenID 2.0 is the answer, I’d like to know the following things about the question:

1. What are the assets to be protected?

What do OpenID’s designers intend it to be used to protect? Blog comment lists? Blog entries? Persistent consumer accounts on commercial servers? Persistent employee accounts on corporate servers?

2. What are the services to be offered?

What services do OpenID’s designers intend it to offer? Authentication of users as the legitimate possessors of OpenID URLs? Linkage of OpenID URLs to user accounts on web-facing systems? Linkage of OpenID URLs to user attribute information (e.g. Information Cards)?

3. What quality of protection is claimed for these services?

Is the OpenID protocol intended to protect against phishing? Is it intended to protect against man-in-the-middle attacks? Is it intended to protect against attempts by one OpenID party to induce another party to execute malicious code? Is it intended to protect against session-splicing or session hijacking? Is it intended to protect against active or passive wiretapping?

4. What is the threat model?

What threats is OpenID designed to protect against? Accidental failures at a participating party? Malicious behavior by users? Malicious behavior by relying parties? Malicious behavior by OpenID providers? Wiretappers? Hackers attempting to penetrate a relying party? Hackers attempting to penetrate a provider? Hackers attempting to penetrate a client system? Cryptanalysts?

5. What is the trust model?

Who trusts whom to do what? Does the user trust the OpenID provider to actually check his password? Does the provider trust the relying party not to send maliciously constructed OpenID URL strings? Does the relying party trust the provider not to reissue OpenID URLs to different parties at different times? Does the relying party trust any particular OpenID provider to issue OpenID URL strings in a particular part of the namespace (e.g. “.gov”?)

All the arguments about OpenID are entertaining, but the claims and counterclaims are very difficult to evaluate in the absence of a coherent problem statement which includes answers to questions like these. The OpenID 2.0 Specification signally fails to address these issues; in this sense it’s a solution looking for a problem.

Comments

[Justen Stepka]

Security concerns certainly have been identified with the OpenID protocol, however given the simplicity and grass root adoption it seems the protocol is here stay. The limits of the protocol are not that much different than the phishing problems that email has... to resolve this programs like firefox have built in fraud detection which I am sure we will see in the browser and providers soon enough.

One of the things we have have done with our Atlassian Crowd OpenID server is build in whitelist and blacklist:

* http://confluence.atlassian.com/display/CROWD/3.3+Allowing+specified+hosts+only+%28%27Whitelist%27%29

[Bob Blakley]

Saying that OpenID is here to stay because it's been widely adopted is like saying a million Dinosaurs can't be wrong. They can. I appreciate the link to the whitelist and blacklist functionality, but it doesn't answer my question. What do you think this technology should be used for? What do you think it should not be used for?