Aswath Weblog

Another Anti-Phishing Scheme for OpenID

Just as OpenID is getting traction, there has been increasing “chatter” that it could be prone to phishing attacks. OpenID wiki has a section that describes the scenario and also lists different recommended actions OpenID Providers (OP), users and the clients can take to mitigate the problem. The purpose of this note is to suggest an alternate login ceremony that can totally eliminate the risk of a phishing attack. The new scheme does not affect existing implementations at the OP and the Relaying Party (RP).

The new proposal requires that a button be added to the browser toolbar that will facilitate the verification procedure. The user will click that button when it is required to generate and provide ID credential to a RP (as it is shown in the accompanying screenshot).

This will trigger the following sequence of events:

1. The tool will collect the URL of the current page and will ask the user to enter the OpenID.
2. The tool will determine the OP using the standard mechanism and will generate a checked_setup/checked_immediate message. Of course this message will not contain the parameter openid.assoc_handle.
3. If the OP needs to interact with the user, then it will be done on a new window.
4. Once the authentication procedure is completed, the new window will be closed; the OP will generate a response to checked_* message and the client will send it to the RP from the original window.
5. Among other things, the response will contain the user’s OpenID and the token. The RP can use the standard authentication procedure by sending a check_authentication request to OP.

Observations:

1. RP is not involved in redirecting the user to the OP, which is mildly disorienting for new users. Any interaction between the user and the OP is totally isolated from the RP. Hence there is no phishing opportunity for a rogue RP.
2. There is no change to the procedural logic at the OP and the impact to RP is minimal.
3. The proposed scheme does not utilize the Association procedure and consequently may increase the load at the OP. But the use of nonce to minimize the replay attacks suggests that the benefits of using the Association procedure is lost in the base scheme itself.