Background

This page is intended as a central place where anti-phishing ideas for OpenID are documented. Please see this thread on the OpenID general discussions list for more information. 

Attack Vector

The following use case is central to the issue:

1. User visits a malicious RP page containing what looks like a regular OpenID login form.
2. User enters OpenID URL
3. Malicious RP redirects user to another page that looks like the user's OP (call this Fake-OP)
4. Fake-OP asks user for password
5. User not noticing the difference from his usual OP, enters his password
6. Fake-OP now has user's password.

Note that anyone can set up the malicious RP, and techniques for spoofing varies in sophistication level.

A detailed description of the problem (not of the solution!) on Kim Cameron's blog 

OpenID Realm Spoofing

Similar to OpenID Phishing is OpenID Realm Spoofing. It is very easy to for a malicious RP to craft an Authentication Request with an openid.realm set to a trusted domain, including *.microsoft.com, *.google.com, *.aol.com, or *.go.com by using open redirect servers or by exploiting XSS flaws on the trusted domain. When signing in, the user's OP will assert to the user that they're signing into the trusted domain, when in fact, they're being redirected back to the malicious RP.

Steps to reproduce:

1. User visits a malicious RP page that issues an Authentication Request to the user's OP with a spoofed realm. The spoofed realm is a realm that the user trusts, for instance, their bank, isp, email provider, an auction site, etc.
2. The malicious RP hides its return_to behind an open redirect server on the spoofed realm, such the one on go.com: http://x.go.com/cgi/x.pl?goto=http://www.jyte.com
3. User's OP displays the realm, and the user signs in, thinking that they're signing into the spoofed realm
4. User is redirected back to the RP thinking that the fake RP is the spoofed realm

The key issue with Realm Spoofing is that the OP asserts to the user the identity of the RP. Because the realm is easily spoofed, and because users trust their OP, the OP can be used to phish users when they signin to a malicious RP. This issue could potentially result in huge liability risks for OPs whose users get phished because their OP told them that they were signing into a trusted site.

Additionally, Attribute Exchange is very dangerous because neither the user nor the OP knows where the user's data is being sent.

Mitigation

Scope of OpenID Authentication 2.0

It is generally agreed that the OpenID specifications suite needs to address the spoofing issue - whether or not it is in scope for OpenID Authentication.

Recommendations for OP

• Never show a password-based login form in response to an authentication request. (Ka-Ping Yee, Mike Beltzner, Hans Granqvist, Terry Hayes)

• Use password-less authentication such as client X.509 certificates.
• Use one-time passwords, which are only valid for a single session (and not for account management).
• Request user to navigate via bookmark or typing into URL bar in order to get to the login form.
• External authentication (email, IM, or other out-of-band channels), may be combined with one-time passwords created by user.
• Encourage users to install anti-phishing browser plug-ins, and educate users on how to tell a phishing site.
• Include some special markup (not specified yet) to make browsers/plug-ins aware that this site claims to be OP and should be processed in a special way Marcin Jagodzinski
• Long living cookie. The cookie value not directly used, it's rather identifier of some resource on server (eg. cookie contains: "what's your favorite color", server knows the answer for user X: "red"). Displaying both before login: "what's your favorite color? it it's RED proceed to login". marcin

Recommendations for Users

• Examine domain name
• Install anti-phishing browser plug-ins, learn to use it
• Pre-authenticate with your OP to eliminate the need to re-enter your login information. (Within the window of your session.)
• Force your IP to only allow you access if you're on a preset static IP address.

Client-based Mitigation

• Petnames -- generally cited as a good way to indicate to the user if a site that he/she is interacting has been visited and assigned an alias before
• Passpet -- a combination of petnames (to help users identify sites) and password management (so users don't have to type passwords into webpages)
• Chrome password entry -- browser (or extension/add-on) solicits password for a login form using "chrome" (UI elements not drawn in the web page or in dialog boxes like these presented during HTTP simple/digest authentication); a feature of: Passpet, Smart keywords
• Identity manager -- a browser-based cross-protocol secure authentication system [1]
• Browser warning with time delayed button
• PhOff
• Emphasize the domain part of the URL, such as is done with the locationbar² extension.
• Bookmarks -- always use a bookmark to navigate to the login form (see blog post and mailing list)
  • Smart keywords -- log in by typing a smart keyword followed by your password into the URL bar; gains some advantages of password entry in chrome without browser changes or extensions (see mailing list)
  • Bookmarked credentials -- include the credentials in the bookmark, so clicking the bookmark immediately logs you in (see blog comment)
• Shared secret -- during setup of the OP, establish a shared secret. Henceforth, all messages between the user and her OP are encrypted (symmetric encryption) with this shared secret. This authenticates the OP to the user since the user is the only one that can decrypt and use the messages. It also authenticates the user to the OP for symmetric reasons! Note: this requires client side capabilities beyond what's available today. Namely, the capability to remember such secrets (keys) and use them to encrypt and decrypt messages. You can think of it as SSO with your OP where the single sign-on and mutual authentication happens during the setup process and all sessions in the future between user and OP can be automated because of the shared secret.

Discussion on the topic of Phishing and OpenID

You can find lots of discussion on the OpenID General mailing list. In addition, there have been several blog posts on the topic:

• Integrating OpenID and InfoCard Part I
• Identity Manager Illustrated
• Phishing and OpenID: Bookmarks to the rescue?
• Yet another anti-phishing idea
• OpenID 2.0 and Phishing
• Phish Stories
• Beginner's guide to OpenID phishing