I’m going to admit it: I’m becoming an OpenID fanboy. OpenID, for those who haven’t heard, is a fairly new open-standards movement to help deal with the fact that we’re required to create new accounts for virtually every site on the Internet. I know that I was recently dissuaded from posting a comment on an Ars Technica comment because I simply didn’t want another damn ID.

I understand why people want login credentials. Hell, I require on this very blog that I vet every unauthenticated comment on this very blog, simply because if I didn’t, there would be a ton of random Spam all over the place if I didn’t. I experimented with reCAPTCHA support, but I’ve had a lot of trouble with the Movable Type plugin that embed the reCAPTCHA form, so I gave up on it. I plan to revisit the CAPTCA issue soon on this blog, but in the meantime Movable Type 4 ships with OpenID support built in, and commenters authenticated via OpenID get their comments posted immediately.

Jeff Atwood had a good post today on using OpenID for his forthcoming stackoverflow.com project. He has a great picture feed of what the OpenID login process looks like, but the basics are this:

1. When you see a page letting you login with OpenID, you enter your OpenID URL.
2. You get redirected to your OpenID provider, who takes your Password
3. You can choose authorize the requesting site, to simplify future logins

And that’s it. Three steps, and you’re authenticated. Setting up the account with the OpenID Provider, can be a bit heavier, but it’s something that needs to be done once. And, if you don’t want to remember your OpenID? You can set a series of tags on your homepage, to tell OpenID requestors who to talk to to authenticate your. It’s simple, and as long as you can edit HTML, you can easily add this to the header. The following code is specific to myopenid.com, but other providers should offer similar functionality.

        <meta http-equiv=”X-XRDS-Location” content=”http://www.myopenid.com/xrds?username=dinglebert.myopenid.com” />
        
        <link rel=”openid.server” href=”http://www.myopenid.com/server” />
        <link rel=”openid.delegate” href=”http://dinglebert.openid.com/” />
        <link rel=”openid2.provider” href=”http://www.myopenid.com/server” />
        
        <link rel=”openid.local_id” href=”http://dinglebert.openid.com/” />
        

In fact, if you were to visit http://dinglebert.openid.com/ (if dinglebert existed as a user that is), those links to the openid.server and openid2.provider appear on that page! All you’re really doing is cutting out the middleman, and providing the address to the webservice that your OpenID uses. Yahoo!, who provides openIDs to everyone with Yahoo! accounts, even goes so far as to allow it’s users to use yahoo.com as your OpenID address. Simply enter yahoo.com, and yahoo will verify your credentials, and approve access to the OpenID site. This is still technically a beta service, so Yahoo! does require you to opt-in, but the process is less painless than any other option, if you have a Yahoo! Id already.

Some people are claiming that OpenID isn’t secure. I argue that OpenId is only as secure as your OpenID provider. But let’s go through the main points in the linked blog post.

1. Phising Weaknesses - The attack is basically identical to standard e-mail phising. Trick the user into going to a fake login page, that looks like the real deal, and steal their credentials. Since it is the responsibility of the page you’re trying to authenticate to to send you to your provider, this is actually trivial to accomplish. However, this is also trivial to avoid. Your provider should have an SSL login page, and if the certificate doesn’t match the page, don’t log into it. Easy. Admittedly, most users will click right through these security warnings, but that has been approving. Plus, Phising Filters on browsers have been improving, which provides a bit more aid in mitigating the damage.
2. Privacy Issues - Some people are worried about having all of your online activities tied to a single ID. For one thing, if your username were ever recycled by your provider, and snatched up by somebody else, then the new person will have access to your old sites. Resolution is easy: don’t recycle IDs. Storage is cheap, and while I may be disappointed that I can’t be foxxtrot at every site I go to, I understand that IDs aren’t always unique. With OpenID, all I require is a URL, and that *can* be unique. And despite one blogger’s claims, OpenID will not destroy anonimity, certainly not anymore than it already is. Most people use the same usernames from site to site anyway, you can easily track someone by following their username. If the poster on a different site isn’t me, odds are they aren’t going to write as I do. There is credence to the fact that a compromised OpenID, via credentials stolen by a keylogger or whatnot, but I’ll address those shortly.
3. Trust Issues - My provider is where the trust comes from. And with OpenID, you can choose to only accept certain providers. Of course, no other standard authentication answers this need very well either. E-mail is inherently insecure, and if my e-mail gets cracked, or can be observed en route, than all the mechanisms used today to validate identity based on ownership of an e-mail address go right out the window. However, there is an answer to this. One that can (and does!) utilize OpenID, more on that later.
4. Too Complex - Okay, I’ll go with this one. It is harder to set up an OpenID the first time, and there are potential issues involved in using OpenID, particularly if your provider is having problems, or if there is a routing issue from the authorizing site to the provider. Unfortunately, I don’t think this one is answerable.
5. Too Many Cooks - Another good point. More people want to provide OpenID than accept it. I can’t argue this one, but this is a social, not a technical flaw in OpenID.

The article needs to be taken with a grain of salt, however, as the writer is trying to sell people on his own Credentica U-Prove Service which provides a similar single sign-on type experience utilizing strong encryption. It looks like a fine product, but there is not reason to claim that something similar can’t be done with OpenID. Plus, I suspect that his system is susceptible of issues 4 and 5 above. There is one place where U-Prove is superior to OpenID, and that is where U-Prove has restrictions in it’s architecture that make it very difficult to determine that a single user logged in to two different sites are not actually two different people. I suspect that this can be determined without breaking their encryption by watching IPs that the Users are logging in from, which could lead to enough IP Address information eventually to make a strong guess, but it does offer that protection better, and you’d have to have access to multiple sites access logs to determine anything.

However, I don’t believe that most people are interested in keeping their identities completely anonymous online. Facebook and Myspace seem to be strong evidence for that idea. If you don’t want certain activity associated with your OpenID, don’t use your OpenID for that activity, it’s that simple. I will always allow anonymous commenting on this blog (I only filter for SPAM). Anonymous commenting is important, and OpenID in and of itself will not destroy that.

As for trust. If you can trust my provider to authenticate me correctly, you can trust that my ID is who I say I am. That accomplished via multi-factor authentication. On the weekly Security Now Podcast with Leo Laporte and Steve Gibson, Steve spent a few weeks fawning over the YubiKey. The Yubikey is a cryptographically secure authentication token generator, that can be used by an OpenID Provider to verify it’s users. How’s this work? You generate a public and private key pair for your Yubikey, the private key is stored in inaccessible memory on the key, and the public key is stored with your OpenID provider. When prompted for your password from your Yubikey provider, simply hit the button on the USB Yubikey, and it will output a cryptographically secure, one use only password, which your provider will then verify and approve.

That’s two-factors people. First the OpenID URL, which is easy to find, but also a non-repeatable Yubikey code, which only you should have. This system could be augmented further, as the RSA SecurID Fobs are, with a small bit of data that only you know, though that isn’t completely necessary. Lost your Yubikey? Have your OpenID provider revoke access to it, until you’ve replaced it. Now, it’s up to my Yubikey enabled provider to verify my identity, and you can trust my identity because of my provider.

OpenID isn’t a silver bullet. It isn’t appropriate for every situation, either. It is a good solution in the intermediate term, though. Particularly when tied with something like the Yubikey or an RSA SecurID. If providing authentication services via OpenID, I believe you will likely require the ability to accept only certain OpenID providers, but even then, you significantly reduce the number of usernames and passwords people need to know, and that alone is a goal worth seeking.