Simon Willison’s Weblog

Solving the OpenID phishing problem

19th January 2007

Most of the arguments I hear against OpenID are based on mis-understandings of the specification, but there is one that can’t be ignored: OpenID is extremely vulnerable to phishing.

Phishing attacks work by tricking a user in to visiting a replica of the login page for a service, usually through a spam e-mail. OpenID compounds the problem by training users to use login forms that they have been redirected to by untrusted sites. A malicious site could easily redirect to a proxy that copies the login form from the user’s identity provider, and the vast majority of users would be none the wiser—a classic man-in-the-middle attack. Ben Laurie’s OpenID: Phishing Heaven describes this problem in more detail.

I have a proposal for identity providers which I think could dramatically reduce the risk of phishing, without mandating a client-side plugin.

When an OpenID consumer application redirects a user to their identity provider there are three possible outcomes:

1. The user is already logged in to their identity provider but has not previously used the application in question. Show them a “Do you want to share your identity with X?” confirmation prompt.
2. The user is already logged in to their identity provider and has previously stated that they always trust this application. Redirect them straight back without any further steps.
3. The user is NOT already logged in to their application provider. Show them the provider’s login form.

Phishing attempts target the third one, and that’s where identity providers can fight back. Instead of displaying the login form directly, providers should show a page that looks something like this:

To log in, please navigate to login.example.com. The page your are currently viewing should contain no links; if there are any links or this text is changed in any way you may become a victim of online identity theft.

Identity providers should never display their authentication interface directly on the page shown to a user after an OpenID redirect, or even provide a link to it. They should instead use that page to inform their users about the dangers of online identity theft. Educating users is a demonstrably flawed strategy in computer security, but forcing them to learn how to browse to the login page themselves should be far more effective than just displaying a warning notice.

It’s important that the login page URL be short, distinctive and memorable. This is a good rule of thumb for all applications, not just OpenID providers.

This proposal certainly isn’t 100% fool-proof, but I doubt that any solution to phishing ever could be (someone can always invent a better fool). The effectiveness of the approach could be dramatically increased by disciplined usability testing of the instruction page itself.

I don’t know of any identity providers that currently do this, but delegation makes switching providers trivial and security is likely to emerge as a key way for them to compete. There’s plenty of scope for innovation here.

If there are any holes in my thinking I’d love to hear about them in the comments. Update: Tons of smart comments on this one.