A rebuttal to the concerns surrounding OpenID

OpenID is still largely unknown to most Internet users.  Those who already know something about it are mostly very tech savvy and have a strong opinion either for or against it.  Those for it see it as a realistic vision for single sign-on for the web.  Those who are against it range from simply not seeing a need for it to adamantly thinking it’s one of the worst protocols because of the security risks it (supposedly) introduces.  Many of these concerns are based on old information or false assumptions.  I’d like to review some of the more commonly repeated concerns and explain why OpenID does more good than harm, and why I’d like to see its universal adoption in the next 2-3 years.

This post assumes you already have a grasp of what OpenID is all about.  If you don’t, stop by openid.net and read about it first, then come back here.  Another good read is Kim Cameron’s Laws of Identity (or in brief form), which I’ll discuss in the context of OpenID in a later post.

And a quick review of terminology used throughout the post:

• SSO = single-sign on: the capability to log in just once and have anyone you wish to reveal your identity to implicitly recognize you without you having to re-enter your credentials.
• IdP = Identity Provider: an entity that "hosts" your identity, and can make assertions regarding your identity and attributes to other entities.
• RP = Relying Party: an entity that trusts an IdP to assert your identity–that is, a site that accepts your OpenID Identifier to login.
• OpenID Identifier = the URL or XRI that you can type in to log into an RP.

Now on to the concerns I keep hearing…

OpenID fails at SSO

First let’s discuss the merits and demerits of SSO.  If you logged into your computer and every single web site you visited immediately knew who you were, this would indeed be convenient.  Unfortunately it would also be convenient to snoops who want to find out more about you to know who you were without your knowledge.  The Laws of Identity include this provision.  So SSO on the wild, wild web must include a conscious decision to reveal your identity — and only as much as is absolutely necessary. 

OpenID requires you to deliberately sign-in to every RP you visit.  If you trust an RP you can tell your IdP that it can stop asking you if you want to log in to make it more streamlined.  OpenID thus takes you as close to SSO on the web as you really want to be.

Verdict: A pro instead of a con.

Users often have multiple OpenID Identifiers

The mantra of OpenID is presumed to be that an individual has just one Identifier that gets him/her into everything.  Then why do so many users have multiple OpenID Identifiers?

Having more than one Identifier is not a sign of a problem, but a sign that one of OpenID’s powers is being put to use.  With OpenID allowing anyone to be an identity provider (IdP), we have competition in the marketplace to become the best IdP to win loyal web visitors.  Until we see a "best" out there (likely never), there will always be trade-offs to picking one IdP over another.  But if you choose multiple IdPs, you can combine the advantages of many into your own identity management.  Since OpenID lets you collect all your IdPs under one OpenID Identifier, your identity isn’t splintered by having multiple IdPs.  It just makes your omni-Identifier more potent. 

Let’s say you have three OpenIDs: one from openid.yahoo.com, one from myvidoop.com and one from linksafe.com.  Each IdP has its advantages.  Go with me in this example (it may not be strictly true for you, but true for many):

• You’re almost always logged into Yahoo!, so using them as a IdP makes sense because it increases the likelihood that logging into an web site that accepts OpenID (henceforth called RP, for "relying party") won’t require you to log into your Provider.
• When you’re away from your own (trusted) computer, and you’re at an untrusted computer (an enemy’s, or an Internet cafe) that may have a key logger, you can use myvidoop.com to login with their one-time-use passwords.
• When you’re trying to log into HealthVault which has a whitelist of only two providers, your linksafe.com provider (which is on HealthVault’s whitelist) will automatically be selected and authenticate you.

And all this without having to remember your several Identifiers.  Just remember the one that ties them together.  One Identifier to Rule Them All.

Verdict: A pro instead of a con.

OpenID is too hard

No password to login?  That’s the hardest intellectual hurdle in my opinion.  When I first tried OpenID I remember how I felt while typing some URL into a single box and wondering "How in the world will my typing in a URL prove who I am to this web site?"  There was a mind block there for several moments.  But I tried it and it worked.

Since then it’s gotten way easier.  I don’t even have to remember a moderately easy URL like http://andrewarnott.myopenid.com.  I only have to type in myopenid.com or yahoo.com and I’m done.  How easy is that?!

In fact, with some popular Providers like Yahoo! issuing their "Log in with your Yahoo! ID" buttons, OpenID falls completely behind the scenes.  The user just clicks a familiar button, the log into Yahoo (from their perspective) and suddenly they’re logged into the RP web site.  How could that be any easier?

There is room to improve, of course.  Yahoo! and some other providers have to make creating an OpenID look simpler.  But that is no fault of the protocol.  The sites that offer OpenID can and will get better.  Remember how hard the web was when it was new?  Was anyone ready to type in http://www.yourfavoritebrand.com back then?  Heck, household product vendors didn’t even know what to do with a web site yet.  OpenID is just the next new thing and it will take some time for people to "get it" mentally.  But that is normal, not a bad sign that OpenID is headed for the dump heap.

Verdict: There is improvement to be made, but many IdP’s are already quite user-friendly.

OpenID allows IdP’s to track all your web site visits

This is true.  Part of the OpenID protocol’s security features include that an IdP is aware of each RP a user logs into.  While the protocol does not require the IdP to track all your visits over time, an IdP is free to do so.  But this concern is resolved when you remember that anyone (even you!) can be an IdP, and if you don’t trust the IdP you’re using to either not track you or to keep your private data private, pick a different one, or become your own IdP. 

Verdict: Completely resolvable by an individual user.

OpenID allows different RPs to link data they have on you

This concern is based on the assumption that a visitor uses the same Identifier to every RP he/she logs into.  If I am known by https://andrewarnott.myopenid.com at every site I log into, then those sites can exchange user data about me and gain more information than I intended for them to have. 

This was a valid concern with OpenID 1.x, but OpenID 2.0 solved that by introducing the directed identity feature.  Directed Identity allows IdP’s to transform the Identifier the user typed in into some other Identifier.  It is both a convenience feature (so user’s can just type myopenid.com instead of andrewarnott.myopenid.com) and a security feature so that RPs (optionally, based on the IdP you use) never see andrewarnott.myopenid.com at all, but instead some randomly generated Identifier that the IdP will always use for that individual RP and no others. 

So OpenID, once again, puts the option into the user’s hands by letting the user decide whether the RP will see a standard Identifier you use when you wish to be identifiable across sites vs. a unique Identifier for that individual RP or small group of RPs.

To date however, I have not seen a single IdP that actually uses directed identity to generate pair-wise unique Identifiers so the user’s identity cannot be tied across RPs.  It’s absolutely technically feasible given the spec, and not that hard either.  But I guess customers have not been clamoring for this feature enough for IdP’s to actually add support for it.

(Don’t be fooled into thinking Yahoo!’s hash-looking Identifier it creates for you is pair-wise unique… it’s not.  The same crazy Identifier is shared across all the RPs you log into.)

Verdict: Totally resolved by OpenID 2.0, although IdP’s need to catch up and leverage 2.0 to solve this.

OpenID is vulnerable to phishing attacks

First the bad news: OpenID multiplies the severity of the phishing problem.  If someone else controls your OpenID Identifier, they can impersonate you everywhere you use OpenID to login.  Since an untrusted RP that you’re trying to log into is the same entity that redirects you to your IdP to prove your identity through alternate means (traditional username/password for example), there is room for the RP to pretend to be your IdP and capture your credentials and gain control of your OpenId Identifier.  It was bad enough when phishing emails with almost-normal-looking URLs tried to steal your username/password to your bank account by luring you to a copy-cat site where one username/password could get stolen.  But now web sites can take you without seeing or clicking on a link to a site that you think is yours, and steal the one key that will open every one of your locks (at least those that accept your OpenID).  Wow, that’s bad…

Although OpenID somewhat forces centralization and unification of your one-size-fits-all key, I’ll bet 95% of the common users out there are doing it informally already.  Be honest: do you really use a unique username and password for each and every web site you log into?  If you have a password manager installed in your browser you just might.  But you probably don’t.  In fact, most less tech-savvy people reuse the same one or two passwords at every site they visit.  This is not just guessing.  It is a real problem.  Web sites can and do use their username/password database to try to steal your identity or assets on other web sites and succeed!  This is all without the help of OpenID.

But of course this cloud has a silver lining, or else I wouldn’t be advocating OpenID. :) 

While an IdP can take a username/password as its credential, it can (and should) also take stronger, less phishable credentials.  Some terrific alternatives are InfoCard, X.509 client certificates, one-time-use passwords, and two-factor authentication like calling you on your cell phone.  By using InfoCard or X.509 client certificates as your primary authentication to an IdP, your proof of identity becomes completely unphishable.  Yes, an evil RP could trick you into logging into their pretend-IdP site, but that will not buy them control of your OpenID hosted at the real IdP at all.  The very most they could phish out of you is whatever attributes about yourself you explicitly added to your InfoCard or X.509 cert, which may consist of your name and email address — but never the ability to pretend to be you to your IdP.  In fact several of the big-name OpenID Providers out there already offer the option to let you log in using InfoCard or X.509 and even allow you to turn off the ability to log in with a password so it can never happen to you. 

Verdict: Completely resolvable by an individual user, but Providers can improve security for their users by encouraging more users to turn off their passwords. 

We already have InfoCard and X.509 client certificates.  Why do we need OpenID?

X.509 client certificates are not a great solution because you either have one for every web site or you share certificates across web sites which means these web sites can collaborate and share information about you.  Neither of these is desirable.  X.509 client certificates are also not easily ported between computers, and you’d never want to copy them to an untrusted computer to temporarily log in as that computer could steal the private certificate without your knowledge.

InfoCard allows you to have just one Card (or perhaps a few) that you can use across all sites you visit, without those sites being able to link your information across multiple sites.  But accepting InfoCard securely requires that your site both have an HTTPS server certificate and that your web site has access to the private certificate to decrypt the token, which many web hosting providers disallow for security reasons.   This makes accepting InfoCard technically infeasible for most sites out there.  It also requires special software on the client, and the Cards are not easily ported between computers and again should not be done on untrusted hardware, leaving you unable to log in as yourself on someone else’s computer.

OpenID on the other hand does not require RPs to have HTTPS certificates, although RPs should have one if they ask for sensitive personal information about yourself as all web sites should.  It can be done with "safe" server code (partial trust ASP.NET, Java, PHP, Perl, Python, Ruby, …) and is thus easily deployable in shared hosting environments.  Logging in using OpenID can be done from any computer, subject to the limitations of the IdP you choose, and requires only a web browser.  But that’s the awesome bit: it’s up to you to choose your IdP and how to configure it, so you choose between the trade-offs between high security and high portability instead of every other web site you visit.  Plus, some IdP’s (like myopenid.com and myvidoop.com) are getting quite creative in getting the best of both worlds between portability and security.  With OpenID you can leverage that to benefit you on every site that accepts OpenID.  Sweet.

I’ll just add that any web site you log into with a username/password really should use HTTPS to protect your password. But with OpenID an RP can safely allow you to login without having an HTTPS certificate of its own.  With the great libraries out there for adding OpenID to your web site, adding OpenID actually becomes potentially easier than adding username/password in a secure way. 

Verdict: InfoCard and X.509 lack some important features that OpenID makes easily available to users.

OpenID Identifier URLs are subject to others gaining (or spoofing) control of them and stealing your identity

If you are using a URL from a domain you own as your OpenID Identifier (say http://blog.yourname.com) there is the danger that one year you’ll forget, or decide to not renew that domain name.  Someone can then buy that domain, set up an OpenID Identifier at the same location, and then impersonate you on all the RP sites that you left dangling accounts on.  You would have to be very careful to delete your account or change OpenID Identifiers on every single RP you ever signed into to avoid this.  That’s unlikely and thus a real security risk.  (but read on…)

You don’t even have to let your domain registration expire.  If you don’t always use a secure https Identifier, an attacker can use a DNS poisoning attack to impersonate you on some RP by tricking the RP into thinking the attacker is hosting the user’s IdP.  That’s really bad.  And although not all sites are vulnerable to DNS poisoning attacks, as just a visitor to an RP web site, there’s no good way for you to establish their vulnerability to this (nor would you want to laboriously check this with every visit).

Finally, even if you aren’t hosting your own Identifier and have chosen a good HTTPS-supporting IdP, concern exists that when you cancel your georgeduncan account at that IdP that the IdP may recreate the account for a new George Duncan that comes along to that IdP, allow the same Identifier to be created and that George to impersonate you on all the RP sites you’ve visited in the past.

OpenID 2.0 helps to relieve most of these concerns that arose out of use of OpenID 1.x.  HTTPS Identifiers are highly encouraged and many Providers already support them, although most can improve their security by normalizing Identifiers users type in to be https even if the user typed in http.  IdP’s that wish to reuse usernames as existing users cancel accounts and new ones arrive may do so without sacrificing the security of their old account by using OpenID 2.0’s "Identifier recycling", which adds a #fragment to the URL Identifier that RPs will recognize and use to differentiate the new and old user accounts.

Finally, and the best solution in my opinion, is that OpenID 2.0 introduced the use of XRIs as Identifiers that we can use instead of URLs.  XRI’s come in two forms: i-names and i-numbers.  My i-name is =arnott, and my i-number is =!9B72.7DD1.50A9.5CCD.  My i-name, like a domain name, only belongs to me as long as I maintain an account with the service I registered it with.  But my i-number that came with that i-name is universally unique and mine forever, long after I cancel my i-name.  Since RPs I log into using my i-name actually store my i-number as my Identifier, I can change my i-name anytime I like and still log in because my i-number is mine forever.  And a future owner of =arnott will not be able to impersonate me because their i-number must be different than mine.  And no I do not have to memorize my i-number.  I just remember =arnott, and the infrastructure does all the work of resolving that to an i-number and authenticating me.  Now even if I’m hosting my own IdP I can rest assured that no one can ever buy off my Identifier.

Verdict: Valid security concerns exist, but solutions to all of them already exist and are well supported.

There are not enough relying party web sites that accept OpenID

I agree with this sentiment.  Although there are already tens of thousands of sites that accept OpenID, on the scale of the web that is a very small percentage.  And most of the sites that I personally use do not yet accept it. 

This of course is not a shortcoming of the OpenID Authentication protocol, but just a sign of its newness.  I encourage everyone to help in the effort of spreading OpenID.  Web developers can adopt OpenID on their web sites.  Everyone can visit http://demand.openid.net and add a bookmarklet to their web browser toolbars and click "Demand OpenID" on each site they visit that does not accept OpenID. Think of it as a vote counter that web developers can view to see how many of their visitors want OpenID.  It’s just one click and you can go on logging in the traditional way until that site adds OpenID support.

Verdict: True.  But sites are adding OpenID support at an encouraging rate.

OpenID has no "single sign off"

Let’s say you’re at an Internet kiosk and log into an OpenID-supporting web site.  To complete that process you actually logged into two web sites: your IdP and the RP.  Each subsequent RP you log into adds one more web site to the list of web sites you’ve logged into.  No big deal, since OpenID makes logging into each successive RP quick and easy.  But now you’re ready to leave the kiosk and you certainly don’t want the next person in line to impersonate your identity, so you responsibly Log Off of the last RP you signed into.  Guess what?  Even if you logged out of every single RP you logged into, you may have forgotten to explicitly log out of your IdP since you only visited that site long enough to log into another site.  The next person in line may even be innocent when they type in "yahoo.com" as their OpenID Identifier to log themselves into bankofamerica.com, but when they see your account automatically come up instead of being prompted to log in as themselves, even an honest man can be tempted.  If you logged out of your IdP explicitly but forgot to log out of an RP, you’re identity can still be impersonated at that RP. 

Leaving yourself logged into RPs when you walk away from a computer is not a concern introduced by OpenID.  Obviously any site you log into with a standard username/password is still dangerous to walk away from without logging out first.  But the fact that inadvertently leaving yourself logged into your IdP can allow someone to impersonate you everywhere is horrible.

I regret to say that OpenID does not have a good answer for this — yet.  A future version of OpenID or an extension to an existing version could allow for a "single sign off" feature that would automatically log you out of every web site when you click Log Off of just one (or some variant of that).  In the meantime, you need to remember to log out of your IdP before you walk away — or don’t click that "Remember Me" checkbox and be sure to close your browser window when you’re done.

Verdict: A real security concern (for now), but individual users can protect themselves by explicitly logging out when they leave a computer.

My personal concern: Insecure implementations of OpenID

I actually haven’t heard anyone else voice this concern, but to me this is the most serious one and the most difficult to resolve.  There are several good, reputable libraries that make adding OpenID support to a web site fairly trivial and secure at the same time.  As an OpenID library author myself I know that getting it correct, interoperable with other sites, and secure is difficult and takes time and a lot of code and reviews. 

But there are some web developers out there that resist adding libraries to their web sites and would rather code up OpenID support themselves.  I’ve seen several blog posts on "How to add OpenID to your site without a library in just 30 lines of code" or to that effect.  It’s horrendous the security holes these implementations have.  In just a couple minutes of reviewing these ~30 lines I can usually find two or three gaping holes that would allow me to impersonate anybody.  Yet these blog samples unfortunately become the source code to real, live web sites.  The fact that a web site can get OpenID login "working" in 30 lines of code in ideal conditions does not automatically mean that it is secure against attackers or interoperable with other sites that do things slightly differently. 

You wouldn’t want to implement the HTTPS protocol yourself (I hope!) just to avoid a dependency on software that should be built into your web server anyway.  OpenID is a highly security-sensitive protocol that deserves the same respect and care. 

Yet given some arbitrary web site you choose to visit that accepts OpenID, there is no way for you to tell whether a well-written library is driving that feature or a cheap 30 lines from some blog.  If that site offers username/password and OpenID and lets you choose, do you choose username/password because that’s much easier to get right than an OpenID implementation just to play it safe?  Not that passwords are all that safe and you’re still trusting the site to use them responsibly, but still, it’s a way to hedge your bets.  The trouble is that end users have no way to know whether this site’s OpenID is well done or if its implementation would allow someone else to impersonate them. 

There is unfortunately no solution whatsoever right now to this problem.  I imagine the only way to solve this would be to get a reputable security company (like Verisign or Thawte) to issue "OpenID security checked and approved" seals that sites can display next to their OpenID login box to help assure you of a good implementation.  But until someone does that, well, don’t use a poe-dunk looking site to store anything you wouldn’t want someone impersonating you to access.  That’s largely true whether you’re using username/password or OpenID anyway.

Verdict: A real concern, and unfortunately adoption-stifling caution is the best mitigation for now.

Summary

Logging in with passwords needs to go the way of all the earth, there just is no way around it.  Passwords are phishable, forgettable, and weak.  But in the short term they are the only truly portable identity.  The stronger credentials all require either hardware or special software on a computer to let you prove your identity (which is what makes them so secure).  Until the stronger credentials become as easy as passwords to use when you’re on a stranger’s computer, passwords will survive. 

OpenID can help us in this transition by letting users choose when they are personally ready to make the jump to no passwords by choosing an OpenID Provider that suits their security requirements.  Those decisions, made by each individual, can then span to all the web sites the user logs into automatically.