Musings on Digital Identity

Month: May 2008

Even Phishers Have Their Problems

While gone phishing, I discovered that the use of JavaScript puts one barrier up that phishers have to overcome to impersonate a legitimate site. In a characteristically hilarious post, Paul Madsen points out that, besides having to overcome active defenses like Sxipper (“Down girl!”), phishers may also inadvertently present pages localized for their locale, rather than the victim’s.

Intrepid identity adventurer though Paul may be, this stopped him dead in his tracks:

Deutsche Blogger login

Of course, maybe Paul’s German was better than he thought, as the page was urging him to “Gehen Sie auf Nummer sicher! Schützen Sie sich von Phishing und Identitätsdiebstahl.” — “Go safe! Protect yourself from phishing and identity theft.” :-)

Gone Phishing

Fun Communications‘ site idtheft.fun.de 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. idtheft.fun.de 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, idtheft.fun.de 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 myopenid.com. 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 myopenid.com, 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 idtheft.fun.de, you can try this at home!

Fun Communication’s Fun Identity Innovations

Fun Communications logoJohannes Feulner of Fun Communications recently showed me three different identity sites they’ve created, each fun and valuable in its own way. The first, www.webcard-loyalty.com, lets companies create online loyalty cards for their customers. These loyalty Information Cards enable merchants to offer bonuses and discounts when the cards are used, similarly to how physical loyalty cards such as frequent flyer cards and frequent shopper cards are used to provide these benefits in the offline world. You can read more about “virtual loyalty cards” and about the innovation prize they won.

The second, openidbycard.com, dynamically creates a site-specific OpenID to use at an OpenID relying party from any Information Card offering the privatepersonalidentifier (PPID) claim. Type “openidbycard.com” as your OpenID identifier into any OpenID login form and an OpenID will be created for the site based on the site identity and the PPID returned by the card. While I understand value of using public identifiers (such as self-issued.info) in some contexts, it’s great to also have the choice of using unidirectional identifiers at OpenID sites.

Finally, idtheft.fun.de 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.

IBM Product Release for Information Cards and OpenID

IBM logoAs reported in InternetNews (and brought to my attention by Tony Nadalin), IBM has expanded the scope of its Tivoli Federated Identity Manager product to include support for Information Cards and OpenID. This is a fantastic development, as it puts software enabling use of these user-centric identity technologies into the hands of IBM’s numerous important customers, ranging from enterprises to Internet businesses. Congratulations to IBM and the Tivoli team for this significant achievement!

The Certificate Odyssey

I was just reading Ryan Janssen‘s post Becoming an RP with the Pamela Project (pt. 1) and when I got to the end where he wrote “Since it’s going to take a few hours to get my SSL cert issued and installed, I think I’ll post this and go outside for a break!” it reminded me of the certificate odyssey I went through in April last year. After eventually getting the certificate created and installed, I wrote this about it at the time to Stuart Kwan (hip Internet terminologist):

Getting and installing the certificate was an unbelievable odyssey. It was an *incredibly complicated* process, that in my case, involved many visits to Network Solutions’ and GoDaddy’s support sites, several hours of my afternoon on Saturday, using cryptic openssl commands on Linux to create a key pair and a cert signing request (and later to strip the password off the key pair so Apache would start without the password), lots of help on IM from Pam Dingle, and the creation or use of 6 different passwords. Oh, and the cert wasn’t even installed by that point!

And it would have been *so easy* to get any of the steps wrong and have a cert request that was incorrect or to obtain a cert that didn’t do what I wanted it to. I understand the value that certificates provide (and it’s substantial). But we, as an industry, haven’t exactly made it easy for people to obtain and use them…

I’m tempted to blog about that, but I won’t… :-)

But seeing that Ryan is about to go through the same odyssey, I’ve reconsidered, hence this post. I’m now eagerly awaiting part two of his description to see how his experience compares to mine.

Of course, now that CardSpace and other identity selectors have support for no-SSL sites, hopefully this will be an optional odyssey soon — employed only when the security benefits of SSL certificates are called for. I know that Pamela plans to add no-SSL support to PamelaWare for WordPress soon, so after that, the pain that I went through and that Ryan’s in the midst of during a beautiful sunny day on the Lower East Side can be a thing of the past.

Powered by WordPress & Theme by Anders Norén