I've been trying to get these two to play nicely together for a while, and it looks as if Will Norris
may have finally slain this here dragon. Will is the principal author of the Wordpress OpenID plugin
In an ideal world, people never, ever disclose passwords on unprotected Internet connections. In general this means the server has to provide SSL support. However, you can sort of sidestep the problem by using OpenID. It's not perfect, but it addresses that particular vulnerability. (Revised 1/28)If the web server uses OpenID, then the login gets redirected to a different service, your OpenID provider. If your provider uses SSL, and most do, then your password is indeed protected while it's typed it. All the server has to do is ask the OpenID provider to verify your identity and send back assurance that you have been reliably identified.
Don't read this as saying that OpenID is 100% accurate. There are still holes in the system, but we can block some of them with SSL.
Most of us use OpenID by providing an abbreviated URL of some sort. When we log in to a server, that server resolves the domain name in the URL to find our OpenID provider. This is where the attack hits.
The attacker can trick the host by attacking the domain name resolution by the host's DNS. In other words, the attacker tells the server that our OpenID provider is "really" at a different Internet address. Then the attacker provides a subverted OpenID provider at that address. OpenID is a pretty basic protocol, so it's easy to create a subverted provider. All the attacker has to do is ensure that the subverted provider authenticates his login to the host under attack.
Many OpenID providers also make use of OpenID delegation
. This provides additional opportunities to spoof DNS. In OpenID delegation, an OpenID user inserts instructions into a Web page or other Internet resource, and uses the address of that page or resource as an OpenID login identifier. When the server follows the link to this resource, it finds the redirection instructions and uses them to find the "real" OpenID provider.
There's an obvious attack on this: the attacker tricks the server into following the redirection to the wrong resource. Again, he can attack DNS to do this.
These DNS attacks can't be addressed by OpenID by itself. We can make the attacks a lot harder by incorporating SSL in the OpenID process. Unfortunately, this isn't 100% supported by OpenID implementations.
In a perfect world you use https: in your OpenID logins and delegations, and this protects you against spoofed OpenID providers. Well, it protects you as long as the SSL certificate providers haven't been tricked, too.
OpenID and SSL
Here's a quote from the OpenID 2.0 specification:
In order to get protection from SSL, SSL must be used for all parts of the interaction, including interaction with the end user through the User-Agent. While the protocol does not require SSL be used, its use is strongly RECOMMENDED. Current best practices dictate that an OP SHOULD use SSL, with a certificate signed by a trusted authority, to secure its Endpoint URL as well as the interactions with the end user's User-Agent. In addition, SSL, with a certificate signed by a trusted authority, SHOULD be used so that a Relying Party can fetch the end user's URL in a secure manner. Following its own security policies, a Relying Party MAY choose to not complete, or even begin, a transaction if SSL is not being correctly used at these various endpoints.
In other words, a fortuitous set of circumstances may allow you to use SSL for your whole login. Or maybe not. It all depends on what your OpenID supporting code will allow.
At present, OpenID on WordPress seems to handle SSL pretty well - I can turn it on in WordPress (a tricky thing) and it seems to work in my delegation files. However, I don't seem to be able to use it in the actual login screen when delegating. But I'm still experimenting.
OpenID and Policy
Security people might ask "Why would SSL be recommended
? Shouldn't it be mandatory
?" Well, we're working with the open source community, and OpenID is for the present more driven by convenience than security. They don't ignore security, but it's clearly not the top priority in their community. Not yet, anyway.
In other words, it's a policy question. Many or most in the user community are not concerned with the risks inherent in untrustworthy host identification. They would rather have the functionality without dealing with the extra work required to make SSL fit into the whole system.
No doubt some users (like me) are interested in making the thing strong. Not enough.
An unfortunate result: I can't forsee using OpenID with my bank, even though my OpenID provider enforces much stronger authentication (I use a token with Verisign
). The bank has to really trust
the authentication, and take all the steps they
can to ensure it is performed accurately. It's hard to do that when it's delegated.
Now if the bank can confidently ensure that SSL is used for the whole OpenID transaction and that I use an approvide OpenID provider (Verisign seems like a promising provider) then it might work.