May 26, 2008
Gone Phishing

Fun Communications’ site lets you mount your very own man-in-the-middle based phishing attack against the OpenID provider of your choosing. Rather than redirecting you to the OpenID provider you specify, it instead redirects you to a page impersonating the OpenID provider, created using content scraped from the real site behind the scenes.

This is the same kind of attack shown in Kim’s phishing video. lets you have the fun of doing it yourself!

I tried it myself with several OpenID providers I use. Predictably, I was typically able to “steal” the passwords for OpenIDs when logging into them with passwords and hijack the resulting logged-in sessions. “Protecting” an account with a one-time-password (OTP) device did nothing to stop this; my “attack” still succeeded in hijacking the session established using a password in combination with an OTP value.

Two things did defeat these attacks. Because Information Cards generate site-specific sign-in information and the attacker’s site is different than the authentic site, even when I was “tricked” into submitting an Information Card to the imposter site, it didn’t give the imposter the ability to log into the real site. No shared secret was present to steal and no session was established to hijack.

The other thing that defeated this specific attack was the use of JavaScript in the sign-in process by the OpenID provider. While a slightly more sophisticated attack could almost certainly get past this obstacle, apparently doesn’t correctly mimic JavaScript site features like “Sign In” buttons invoking an onclick method.

This ability to both phish passwords and hijack the resulting logged-in sessions is exactly why I and others are working on finishing the OpenID Provider Authentication Policy Extension (PAPE) extension. As I wrote when the first draft was published, PAPE enables “OpenID relying parties to request that a phishing-resistant authentication method be used by the OpenID provider and for providers to inform relying parties whether a phishing-resistant authentication method, such as Windows CardSpace, was used.” It’s time for PAPE to become an OpenID standard.

What follows are screen shots from a successful phishing attack and a thwarted one – both against the same OP. The difference is whether passwords or Information Cards were used to log in.

Figure 1: idtheft start

Figure 1: About to mount my attack against my OpenID at I’ve typed the URL of my OpenID into the relying party.

Figure 2: idtheft signin

Figure 2: Next, I’m logging in with a password. An observant user could notice several things wrong: the address bar shows the imposter’s URL, the imposter’s URL is present in the “You must sign in to authenticate to …” message, and the “Your Personal Icon” space is blank. Unfortunately, there is strong evidence that users are not observant.

Figure 3: idtheft allow

Figure 3: Phishing already accomplished. Same cues are present that something’s amiss. Of course, a more sophisticated attack could replace the imposter’s URL in the page with the “real one” in both of these screens, eliminating the most obvious cue. I scroll down and click “Allow Once”.

Figure 4: idtheft accomplished

Figure 4: Result after being redirected back to the “relying party”. Yes, that was my real password.

Next, I tried to attack my account again but was surprised that I wasn’t asked to log in this time. Of course – the attacker’s session was already logged in! So I signed out as the man-in-the-middle (that was weird), enabling me to try again.

My next steps looked just like Figures 1 and 2, except instead of typing a password I clicked the purple Information Card button. This brought me to:

Figure 5: idtheft cardspace

Figure 5: CardSpace informs me that I’ve never sent a card to this site before. An observant user would realize that they don’t normally see this screen and might decline. But then, we’ve already discussed how observant users aren’t. I click “Yes”, choose the card I normally use to log into, and send it.

Figure 6: idtheft prevented

Figure 6: Phishing prevented. “Error processing Information Card token” isn’t the most informative error message I’ve ever seen but behind it is great news: the phishing attack failed because the token constructed for the imposter site wasn’t usable at the real site.

And thanks to, you can try this at home!

16 Responses to “Gone Phishing”

  1. Mike Jones: self-issued » Fun Communication’s Fun Identity Innovations on 26 May 2008 at 2:57 am #

    […] Finally, demonstrates the ability of attackers to mount man-in-the-middle attacks against OpenID sites (and lets you try it yourself!). The site phishes OpenID passwords and other information sent through the browser, all via web pages that look authentic, but that are actually under control of the attacker. This will be the subject of my next post. […]

  2. Carsten Pötter on 26 May 2008 at 5:00 am #

    Either I did something wrong or the demo doesn’t work with SeatBelt enabled. Or SeatBelt works and prevented me from signing in to the fake provider.

  3. Cardspace Community Bloggers on 26 May 2008 at 5:30 am #

    Security through localization…

    Mike brags about how Infocards can interrupt/prevent a phish. I tried the phishing demo and, even without…

  4. Cardspace Community Bloggers on 26 May 2008 at 11:27 am #

    openid is toast…

    Mike (one of those who need no sleep) blogged about Fun Communication’s openid idtheft site and I encourage…

  5. Mike Jones: self-issued » Even Phishers Have Their Problems on 26 May 2008 at 1:37 pm #

    […] Using Information Cards « Gone Phishing May 26, 2008 Even Phishers Have Their […]

  6. OpenID, Phishing, and a strange choice in browser support « Identity Blogger on 27 May 2008 at 4:54 am #

    […] 27, 2008 · No Comments Mike Jones points out a site where you can test drive a man-in-the-middle Phishing attack against OpenID. This is […]

  7. Michael Graves on 27 May 2008 at 10:17 am #

    Good post, Mike!

    You’ve pointed out here a set of cues, each of which *should* alert the user to a problem, but note — correctly, alas! — that many users can’t be bothered by such cues. User education on topics like this is definitely one area where the OpenID community needs to do better. And of course, the user experience isn’t optimal in making those cues to the presence of a problem clear and prominent.

    OpenID is a web technology, and uses only resources and messages that are available as part of the web. This is one of the reasons it has gotten to be as popular as it is, and growing in popularity fast. But the “webness” of OpenID also means it inherits many of the weaknesses of the web, and the vulnerability to phishing attacks is one of those weaknesses, to be sure.

    JanRain’s, which is the OpenID provider in your post and in the phishing example, has implemented InfoCard support for just this reason. As you show, an InfoCard will fail just the way we want it to as part of an authentication process hijacked by phishers (and I agree: the error message should be more clear and informative!). InfoCard isn’t available to all web users, unfortunately, so it’s not been a ‘universal balm’ for the SSO and digital identity problem. But where it is available, it’s a nice addition to the toolkit for OpenID providers and users, and as the OpenID ecosystem develops, I expect to see more and more adoption of “desktop and chrome” tools that provide protections against phishing and other attacks that are inherent in any pure-web technology like OpenID (Verisign’s Seatbelt being another example of such tool that comes to mind).

  8. Mike Jones on 27 May 2008 at 4:42 pm #

    Thanks Michael. I’ll also take a moment to point out that’s support for client certificates would have stopped this attack cold in its tracks as well.

    For what it’s worth, I don’t think CallVerifID would have, though, because the real OP would place the phone call for the attacker. Maybe someone can try this and verify that my analysis is correct.

    What I love about is that it lets people try these things themselves and find out! Data is good…

  9. Kevin Fox on 27 May 2008 at 6:29 pm #

    Hi Mike,

    I work for Vidoop and tried out our provider and could not get our ImageShield to load. Would be interested to hear what other hits and misses people have had with their providers.


  10. Mike Jones on 27 May 2008 at 6:48 pm #

    In fact, it was trying to phish my identity that led me to conclude that the use of JavaScript thwarted the attack in this case.

  11. on 28 May 2008 at 12:06 am #

    My provider survives quite nicely against that attack (try it with as the OpenID and see) – it uses the approach described here:

  12. Axel Nennker on 28 May 2008 at 2:54 am #

    Great that information cards stopped the phishing attack.
    Although openid providers offering information card support have to be aware that the security is only as good as the weakest link. If fun’s proxy would remove the information card support or replace it with an apology about a currently disabled information card support and the openid provider would allow username/password as a fallback then we are back to zero.

    I like the story of the leader of a car-thieve-ring who protected her own Mercedes with a wireless-key and who removed the traditional locks and doorknobs.

  13. » Blog Archive » OpenID phishing demo on 31 May 2008 at 8:20 pm #

    […] phishing demo (via). A demonstration of the OpenID man-in-the-middle phishing attack. OpenIDs are immune […]

  14. Johannes Feulner on 05 Jun 2008 at 5:06 am #

    Thank you Mike, for featuring on your blog. The discussion here prove’s once more: seeing is believing.

    For those who missed JavaScript support at We at fun communications added JavaScript support to this demo, so you might see more OpenID-Providers “failing” this test.

    Since I got a lot of feedback concerning, let me explicitly state the obvious:
    1. OK, if you find your OpenID password on the screen, you should definitely reconsider the choice and/or implementation of authentication methods your OP provides.
    2. If the test fails, there is not much of a result. Perhaps your OP is doing a good job. BUT, is a quickly built demonstration based on and far from being perfect.
    3. Attacking OpenID by a proxy running a man in the middle attack is just one way. There are many others.

    The question nagging on my mind (I’d appreciate to hear your ideas): What is a safe way to responsibly implement username/passwort authentication for an OpenID OP? What is there beyond Verisign’s SeatBelt, Yahoo’s Sing-In Seal or’s dead end landing page?

  15. Mike Jones: self-issued » PAPE Specification Entering Public Review Period on 22 Oct 2008 at 8:53 pm #

    […] that the OP perform phishing-resistant authentication, the need for which has been discussed here and elsewhere. Another capability I’m a fan of is the ability for the RP to “freshness date” […]

  16. Mike Jones: self-issued » PAPE Specification Approved and Ready for Use on 30 Dec 2008 at 10:33 pm #

    […] approved as an OpenID specification. Deployment of PAPE will go a long way towards mitigating the phishing vulnerabilities of password-based OpenIDs by enabling OpenID Relying Parties to request that OpenID Providers employ phishing-resistant […]