Is OpenID a good idea?

The Main Idea

OpenID is a standard way for people to log in to websites as an alternative to coming up with a username and password (and possibly giving the site an email address). If someone does not trust OpenID, they can treat an OpenID login process the same as the old-fashioned username and password login process, by going to an OpenID provider, creating a new account with a new username and password, and using that OpenID on the website they are trying to access. If they repeat this process for each new website they want to log in to, they miss out on some of the benefits of OpenID, but are in no worse position than if they were using the old-fashioned system.

Criticism

There are a number of criticisms that immediately arise when considering that view point. Firstly there is the issue that going to a separate site to create the account could be confusing or time consuming, but I posit that this is merely a software issue, and someone could, for instance, write a Firefox extension which adds a “Create OpenID for this site” button to the browser. You could press the button, and it could go off and create an account at an OpenID provider, with a random user name and password, store it in Firefox’s login manager, and log you straight in to the site. Notice that in legacy sites, the signup process cannot be automated like this because the extension would have to know how to negotiate every type of signup form, whereas with OpenID you can use just one website and one signup form to create several accounts which can each be used on a different site.

This leads on to the problem of CAPTCHAs, because an OpenID provider should perhaps prevent automated signups like this, to deter spambots. In this case, the provider could send the Firefox extension some CAPTCHA which it would ask the user to solve it before the account was created. Again, this would be better than the current legacy systems, because presumably they would have CAPTCHAs themselves, and could dispense with this complex feature by off-loading the burden to the OpenID providers. Alternatively, the OpenID provider could let you sign up for a meta-account, with a very stringent CAPTCHA process, but once you had created that account (and put the details into the Firefox extension), it would let you use them to create new OpenIDs without a CAPTCHA. Thus OpenID would actually reduce the number of CAPTCHAs being used.

Next, there is the question of privacy. It is true that using the same OpenID on multiple sites is potentially a way for people (not least advertisers) to connect your various identities and possibly exploit that, but the system I am proposing lets you create a different account for each website, making it harder to link them. Admittedly the OpenID provider themselves would be able to link all the accounts together, but the Firefox extension could be configured to use multiple providers, or use Tor and Privoxy so that the provider wouldn’t know which accounts were created by whom. If you are worried about the theoretical attack of the provider logging in with each of the accounts it creates to the websites where it sees them being used, and harvesting information and using some algorithm to piece together identities, then you should be more worried about what your webmail provider is doing with all your emails and contacts.

The security issue of webmail, or email in general, is actually an even more significant point. It is likely that the vast majority of web users are not as secure as they would be under even the worst OpenID system. Most sites currently have a “reset password” feature which sends an email to your email address with the new password, so people are already using a system with a single point of failure, and your email provider can probably tell which sites you have accounts on from the “Welcome $user!” emails they send. Moreover, the majority of people on the web probably use the same password on every site (including their webmail), and are thus N times more likely to have their passwords compromised than if they used OpenID, where N is the number of sites that they use the same password for, assuming that all websites are as trustworthy as the site they pick as their OpenID provider.

So, with the legacy system you are only as secure as your email provider, assuming you have a good password policy. Even if you run your own mail server, the username you choose on each new website, and the name of that website, will likely be sent to you as an unencrypted email over the internet when you sign up (unless the site you are signing up with asks for your public key first). You might think that you can afford to trust your email provider whereas you couldn’t trust an OpenID provider, but with OpenID you have the option of running your own provider, possibly on your home machine if you wish. OpenID, then, seems to have huge advantages for the majority and small advantages for the minority, but The Main Idea stands: OpenID can be used equivalently to the old username and password system if desired.

Conclusion

I think the idea I’ve put forward does respond to any criticism about OpenID being insecure, and some of the other objections can be answered by similarly general points, such as the fact that OpenID can be run in parallel with existing login systems, which should dramatically reduce the disruption of a site implementing it. I should probably point out though that this general defence of OpenID is not exactly new. I remember reading a similar idea in someone’s comment on a forum and unfortunately I can’t remember how developed my own thoughts on this subject were when I read it. The responses to criticisms, however, are all my own work, and I came up with them because I didn’t feel that anyone had ever addressed the concerns that people might come up with about this idea.

Anyway, the last time I asked people to give me their thoughts about the standard, they said that it was vulnerable to DNS spoofing attacks and phishing in general (which I agree with, but believe there are technological solutions to) and they mentioned that SSL is rarely used (which I think is a problem with existing sites too). I did, though, get the overall comment that OpenID can be made secure, there is nothing in the technology which prohibits a secure implementation, but that few if any OpenID providers currently support the necessary features. This could be because websites which accept OpenIDs cannot tell the difference between a good OpenID provider and a bad one, so there is no benefit (and some cost) in a provider becoming one of the good ones.

What this all suggests then is a need for the OpenID community to come up with a way for websites to find out whether a provider implements various security features such as SSL, multi-factor authentication and client-side certificates. The open standard “PAPE” is an attempt to enable this, but it relies on providers telling the truth. When providers start lying, I imagine sites will start looking to independent organisations to compile lists of OpenID providers based on whether those providers tell the truth in their PAPE responses.

The idea of having a whitelist of providers doesn’t sound great, but perhaps there could be a blacklist, where sites could say “Sorry, according to $list your OpenID provider lies about the security features it supports. Please use our standard username and password login form below.” The assumption could be that any provider not on the list is either a known good provider, or a provider which someone has set up just for themselves and is not subject to the same risks. Most websites, however, probably don’t care if your provider is insecure, because an identity thief is unlikely to use your account to comment on blogs or make changes to a wiki.

So the remaining question are: what standard are we going to use for requesting updates to the blacklist (diff over Atom?) and how are we going to decide which blacklist of untrustworthy OpenID providers is trustworthy?