Some time back I wrote OpenID: the bad and the ugly which was mostly just a redirect to Stefan Brands’ “The problem(s) with OpenID”. Numerous conversations later I am still finding that most Internet users – even developers who understand web security – just don’t grok OpenID security.

And finally I know why: “you” and “your account” have boundary issues.

When I say “an attacker can target a web site and access your account” these people hear “an attacker can target a web site that I use, attack me, phish my details, steal my OpenID and access my account”. Because that’s the most common mode of attack against password-based authentication on the web.

But it’s not how you attack OpenID. There is no “you” in many OpenID attacks. There is just the attacker and your account … make that your ex-account.

I want to start with the opening sentence of the OpenID Authentication specification (v2.0): “OpenID Authentication provides a way to prove that an end user controls an Identifier”.

Two simple attacks

So what if someone else also controls that identifier?

Let’s add a bit of detail. An attacker Mallory knows your OpenID identifier (the thing you type in to login, in this case “alice.com/alice”) and knows that you use service.com.

1. How does Mallory know your identifier? Well they’re not exactly secret. It may be your published username on a site, Mallory could phish for identifiers, cunningly ask Google for a list, hack a major site (this sort of data breach happens quite often), run a bunch of controversial or karma-whore blogs that require OpenID authentication to comment, or even run ausefulsite.com that is really just a front for harvesting identifiers. It’s not hard.
2. Mallory launches a DNS spoof attack against someservice.com, and convinces their servers that the DNS nameserver for alice.com is a server that Mallory controls. How likely is this? DNS cache poisoning continues to be seen in the wild and new DNS attacks are found almost every year.
3. Mallory browses to someservice.com and attempts to log in as “alice.com/alice” (you). someservice.com follows the OpenID protocol and submits a request to alice.com – but Mallory’s service is telling someservice.com the IP address of alice.com, and lies, giving the IP address of Mallory’s web server instead. How hard is this? Trivial. Mallory sets up a DNS server, web server and OpenID provider with freely available software. Network administrators do this sort of thing all the time.
4. Mallory’s web server (which acts as an OpenID provider) receives an OpenID authentication request and gives an “ok, authenticated” response.
5. server.com is convinced that Mallory is you, and lets him access your account.

What happened here? Well first of all, you were not involved. This happened while you were sleeping, with no phishing attempt, no direct communication with Mallory, nothing. Mallory subverted the DNS system and convinced someserver.com that his OpenID provider was your OpenID provider. That’s all it takes.

HTTPS may defeat this attack … but were you using https? That means you have “https” in your OpenID identifier, not that you have an https connection to someservice.com! Most vanity domains don’t support HTTPS.

Next attack: alice.com is your vanity domain, and it is hosted at somecheapwebhost.com. The web host doesn’t have an OpenID provider, but you can identify any provider using tags in the HTML page located at your OpenID identifier URL (that’s all defined in the specification). So Alice (that’s you) has set up the tags in the page at “alice.com/alice” to point to her OpenID provider.

All Mallory needs to do is hack into Alice’s somecheapwebhost.com storage and modify the web page that contains the tags, so that they point to his OpenID provider. Then Mallory can go to any service, sign in as “alice.com/alice”, authenticate to his OpenID provider (as Mallory), and gain access to Alice’s account.

Let’s see the action replay: someservice.com fetches the page at “alice.com/alice”, looks through it for the appropriate OpenID tags, contacts the provider identified by those tags and asks for authentication of the identity that is given by those tags. This is all exactly what someservice.com is supposed to do as part of the OpenID protocol. Mallory modifies the page and changes the provider and identity. He could change it to one of his own OpenID identifiers, or he could change it to be his web server (the one he has modified to answer “ok, authenticated” in response to any request). someserver.com asks Mallory’s chosen provider for authentication of Mallory’s chosen identity, believing it to be Alice’s provider and identity (because that’s how Alice’s identifier says to authenticate her).

Mallory has subverted the OpenID discovery system, redirecting authentication requests for “alice.com/alice” to any provider and/or identity that Mallory controls.

So I did a bit of a sleight-of-hand around the “modifies the web page” bit — how does Mallory do this? Easy.

1. Mallory uses this month’s bug in your blog software to modify a local file on your web account. Or last month’s bug, because you don’t patch regularly.
2. Mallory guesses your somecheapwebhost control panel password, or hacks the control panel software, or sniffs your password because he’s a colleague on your local network.
3. Mallory is a disgruntled support guy at somecheapwebhome.com and uses his support account to access your web space. “At” in this context includes “outsourced to”.
4. Mallory poisons the web cache upstream of someservice.com so that “alice.com/alice” gives a page of his choosing, and he never has to modify the real web page.

If Mallory is really clever he can use .htaccess files or server-level configuration to redirect only certain authentication attempts for “alice.com/alice” to his provider/identifier of choice (“malice.com/malice”, of course). Or he can redirect all attempts, but have his web server direct them back unless he’s in the middle of an attack. This will make it very difficult for Alice (that’s you) to notice that she has been attacked, or to figure out how she was attacked.

The downward spiral

These are just some of the attacks against OpenID – the ones that are easiest to understand. The “association” feature of OpenID (cryptographic key exchange and data signature) does not mitigate these attacks, nor does the use of TLS/HTTPS (for any of the connections involved; although association/https may mitigate some approaches to these attack under certain circumstances).

These problems are fundamental design flaws – a reliance that OpenID has on other technologies and protocols that are themselves insecure. There is no simple or quick fix.

The problem comes down to the opening sentence of the specification: “OpenID Authentication provides a way to prove that an end user controls an Identifier”. Is it really that hard to control – or to forge control of – a URL?

How hard do you think it is? Hard enough that you will risk having someone deface your flickr account? I mean, how much damage can someone cause by posting photos in your name? Right? How about your facebook account? That stuff’s just for fun – it’s not like it can damage your reputation. What about your e-mail? So a hacker can read your private communications, embarrass you, whatever. It’s not like he can request a password reset for your online banking account … right?