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.
