OpenID as Authentication Wrapper 1
The idea of using the OpenID provider protocol as an authentication wrapper has been proven by Simon Willison . The concept is not without merit, because not everything is web enabled, but being able to authenticate with your OpenID would be really nice. Again, its the concept of one ID, protected by either you or someone you trust. It’s just not practical in every situation.
Case and point would be integration with subversion. Subversion is a version control system that supports the DAV protocol with some extensions. It means you can use a web front end to look at your repository. It’s what I use both professionally and personally. Most repositories are protected with a combination of SSL and basic authentication. Sure you can do PKI, but that’s a pain and just not practical for open source projects. It has the basic problem of sole sourcing your identities. The basic authentication scheme works well for the command line because the response is just plain text:
> svn co http://d-haven.org/svn/open/trunk/actionpack User name: bloritsch Password: *********
The problem with OpenID is that it is not uncommon for the authentication server (your OpenID provider) to provide some sort of HTML for you to do something to let them know it’s really you. The attached image shows roughly what happens from a user’s perspective (minus a few details) with the OpenID protocol. It’s the challenge screen that gets in the way of using OpenID for the command line. The idea of popping up a screen or incorporating a text HTML browser into subversion is a bit ridiculous. It drops the usability. Note: I also left out the “grant permissions” to the client screen—another wrinkle in the system.
But, let’s assume for a moment that we can create a different authentication system to ensure a user is who they say they are. Let’s also assume for a moment that we can use the user’s OpenID as the user name in this authentication scheme. In essence, “bloritsch.d-haven.org” represents my login ID in either system. All that would be necessary for the web interface would be to use the OpenID protocol trappings around that authentication system.
Of course, why bother with the whole mess in the first place? After all you would have to write some plugins for the server side and client side of things, etc. Well, anyone who does software development has to work with their clients somehow. Many times it means letting them have access to your repository, or at least a portion of it. If the identity management is fairly uniform, it’s easier to integrate all the pieces together. By working on an authentication standard that compliments the OpenID platform (instead of replacing it), it will open up the gates for its adoption. Even more so if it solves the problem of using the “basic authentication” issue. If no passwords are sent, plain text or not, it makes it more difficult for someone to intercept the proof of your identity. Anyway, I’ve got some ideas on it, but no funding or free time. We’ll see how long and when/if it will see the light of day.
OpenID Vulnerabilities and Strategies
Yesterday, I talked about OpenID and its potential. It definitely has the potential to be a very good thing. However, there are some issues to overcome--those same pesky issues of bad people abusing good things for their benefit. These same people send comment spam, wiki spam, email spam, and create phishing sites. They are the cursed underbelly of the internet. It seems that for every good thing, and every advance in security, they try to work around it. It‘s because of them that security is in our way. It‘s just not right.
Let‘s consider the most diabolical approach of a phishing site. It acts as a proxy between you and whatever site it is imitating. The only thing it needs to do is ensure all the forms and links go through the proxied phishing site. It is important to note that this same approach will work for any kind of “in-band” authentication. For example, if you log in to PayPal through a phishing site of this nature, the only clue that it isn‘t really PayPal is the URL at the top of the screen. It gets worse when your authentication pages come up as an AJAX request, because the URL is hidden to the user. To be clear, this is not just an issue for OpenID.
The OpenID spec does not dictate a method of authentication for the OpenID provider. This is an area that is deliberately left open so that the providers can compete based on the level of protection you need. So far the consensus is that the best approach is out of band authentication. The provider should be required to perform its authentication over SSL which enables two valid protections. First, SSL is designed to avoid the man in the middle attack. However, if a site is acting as a proxy for you, and that site has a valid SSL certificate signed by one of the normal certificate authorities, you will be none the wiser. If people won‘t notice a different URL, they will definitely not think to check the certificate of the server which is normally hidden from view. Unless! The OpenID provider requires a client certificate signed by itself. That can also avoid the problem of having to type in passwords all the time.
Browsers are becoming smarter all the time, and just like Thunderbird including scam detection, future versions of Firefox will likely include phishing detection. One of the bullet points for Firefox is OpenID support, so at least the browser can detect if the login page is a phishing attempt or the legitimate provider‘s page.
The current strategies for dealing with out-of-band authentication to address the phishing problem seem to include SMS/text messaging to your phone, browser plugins, or desktop additions. It might even include a combination of them. PKI can work in this situation as well, particularly since you only have to deal with one provider. That‘s probably what Verisign is banking on. Desktop integration just might be one of the best approaches to the problem. Consider being able to log into your machine via OpenID — which automatically sets whatever needs to be set so the server knows it‘s you. The trick is to think about how to avoid the man in the middle, the damnable proxy attack. It has to be something that is obvious to the end user.
OpenID and its Implications
First, let's explore the evolution of how we get to where people think OpenID is needed. We started with every web service from message boards to image sharing sites having their own credentials. In essence every site had to be their own identity provider, but there wasn't a problem of trust because if you can't trust yourself, how can you trust anyone else. This provided a problem for users. They had to remember the user name and passwords for dozens of sites. Sometimes the user name had to be an email address, and other times it could not be an email address, etc. The next idea was the Single Sign On (SSO) approach, where if a site trusted the SSO provider, they could use those validated credentials for itself. The problem here was one of scale. First, there were several large resources that had the same idea such as Yahoo! and Google. Of course, Yahoo! won't trust Google and Google won't trust Yahoo!. Again, the user still had to remember several user names and passwords--but there were fewer of them to remember. If only there was a way to have one place to manage my credentials and use them on every site....
This is the problem that OpenID is trying to solve. With OpenID, you have a URI as your identifier. You can use this same URI on every OpenID enabled site. You can turn any HTML document into your identity by adding a couple <link> entries in your HTML header. The concept is to put the user in control of their own identity, and manage it themselves. In the words of my son, "Shamazing!" The link entries point the consumer (i.e. blogging software, client management software, etc.) to the identity provider (the ID server) so that it can validate whether that ID is owned by you. That means that in order to know who it is that is giving a comment, you only need to require the OpenID and all the rest is taken care of by you.
Now, there is an important distinction to make. Even though OpenID says it is an authentication framework, it does not authenticate! It validates your OpenID, not performs user authentication. Huh? How can they call it an authentication framework? The spec leaves the method of authentication up to your ID provider. It might require a user name/password combination like everything else, or it might use a stronger public key infrastructure, or it might not use anything at all. It's up to the ID provider to choose the method and strength of authentication. The OpenID specification does due diligence to ensure that you aren't going to be intercepted by a man in the middle attack, so the only problem left is whether you trust the ID provider or not. OpenID will only validate that an ID provider recognizes that the URI you provided belongs to you, not whether the ID provider is trustworthy.
What good is it then? It does provide a mechanism to manage the URIs that people use. The consumer software (i.e. your blog provider, etc.) can choose whether or not it accepts/trusts URIs that are guaranteed by a particular ID provider. It also can choose to trust or deny trust to individual accounts. That means that mean spirited trolls can be dealt with, and it means that known spammer ID providers can be outright ignored. It might be important to note that many spammers use a host of DNS names, so it might have what looks like a hundred ID providers even though it is served up by the same server. It might be best to look at the IP addresses when denying spammers.
Honestly, I believe OpenID provides some good benefit to the world in general. First, it puts ID management where it belongs--in the user's hands. Second, it does away with the SSO pissing contests by recognizing that a single authentication system cannot scale to meet the demands of the insanely large user populace. Lastly, it provides one thing for a user to remember to use their identity wherever they want. It allows corporations to manage their own identities while participating in cooperative development projects.
There are additional extensions to the base OpenID spec to allow a consumer site to find out more information about the identity of someone. Here's the kicker: the user doesn't have to share the information if they don't want to. The user is in control of whether they allows a site to consume their email address or not. If the consumer app requests information the user is sensitive about, the ID provider will ask the user if they want to share the requested information with the site or not. Of course the consumer site is allowed to reject comments and such if the information isn't shared, but the user is ultimately in control of their own identity.
Technorati Tags: openid identity architecture
