Let’s start by taking a step-by-step look at the basic OpenID protocol to see how the phishing attack works. (Click on the diagrams to see them on a more readable scale.)
The system consists of three parties - the relying party (or RP) which wants an ID in order to provide services to the user; the user - running a browser; and the Identity Provider (OpenID affectionados call it an OP - presumably because the phrase Open Identity Identity Provider smacks of the Department of Redundancy Department. None the less I’ll stick with the term IP since I want to discuss this in a broader context).
OpenID can employ a few possible messages and patterns, but I’ll just deal with the one which is of concern to me. An interaction starts with the user telling the RP what her URL is (1). The RP consults the URL content to determine where the user’s IP is located (not shown). Then it redirects the user to her IP to pick up an authentication token, as shown in (2) and (3). To do the authentication, the IP has to be sure that it’s the user who is making the request. So it presents her with an authentication screen, typically asking for a username and password in (4). If they are entered correctly, the IP mints a token to send to the RP as shown in (5) and (6). If the IP and RP already know each other, this is the end of the authentication part of the protocol. If not, the back channel is used as well.
The attack works as shown in the next diagram. The user unwittingly goes to an evil site (through conventional phishing or even by following a search engine). The user sends the evil RP her URL (1) and it consults the URL’s content to determine the location of her IP (not shown). But instead of redirecting the user to the legitimate IP, it redirects her to the Evil Scooper site as shown in (2) an (3). The Evil Scooper contacts the legitimate IP and pulls down an exact replica of its login experience (it can even simply become a “man in the middle”) as shown in (4). Convinced she is talking to her IP, the user posts her credentials (username and password) which can now be used by the Evil Scooper to get tokens from the legitimate IP. These tokens can then be used to gain access to any legitimate RP (not shown - too gory).
The problem here is that redirection to the home site is under the control of the evil party, and the user gives that party enough information to sink her. Further, the whole process can be fully automated.
We can eliminate this attack if the user employs Cardspace (or some other identity selector) to log in to the Identity Provider. One way to do this is through use of a self-issued card. Let’s look at what this does to the attacker.
Everything looks the same until step (4), where the user would normally enter her username and password. With self-issued cards, username and password aren’t used and can’t be revealed no matter how much the user is tricked. There is nothing to steal. The central “honeypot credentials” cannot be pried out of the user. The system employs public key cryptography and generates different keys for every site the user visits. So an Evil Scooper can scoop as much as it wants but nothing of value will be revealed to it.
I’ll point out that this is a lot stronger as a solution than just configuring a web browser to know the IP’s address. I won’t go into the many potential attacks on the web browser, although I wish people would start thinking about those, too. What I am saying is the solution I am proposing benefits from cryptogrphy, and that is a good thing, not a bad thing.
There are other advantages as well. Not the least of these is that the user comes to see authentication as being a consistent experience whether going to an OpenID identity provider or to an identity provider using some other technology.
So is this just like saying, “you can fix OpenID if you replace it with Cardspace”? Absolutely not. In this proposal, the relying parties continue to use OpenID in its current form, so we have a very nice lightweight solution. Meanwhile Cardspace is used at the identity provider to keep credentials from being stolen. So the best aspects of OpenID are retained.
How hard would it be for OpenID producers to go in this direction?
Trivial. OpenID software providers would just have to hook support for self-issued cards into their “OP” authentication. More and more software is coming out that will make this easy, and if anyone has trouble just let me know.
Clearly not everyone will use Infocards on day one. But if OpenID embraces the alternative I am proposing, people who want to use selectors will have the option to protect themselves. It will give those of us really concerned about phishing and security the opportunity to work with people so they can understand the benefits of Information Cards - especially when they want, as they inevitably will, to start protecting things of greater value.
So my ask is simple. Build Infocard compatibility into OpenID identity providers. This would help promote Infocards on the one hand, and result in enhanced safety for OpenID on the other. How can that be anything other than a WIN/WIN? I know there are already a number of people in the milieux who want to do this.
I think it would really help and is eminently doable.
This said, I have another proposal as well. I’ll get to it over then next few days.
[...] Użycie innego niż login/hasło mechanizmu uwierzytelniania. Na szeroką skalę jest to niestety trudne do wykonania, aczkolwiek z drugiej strony może być bardzo skuteczne. Niekoniecznie jednak jest skuteczne w 100%: przejęcie np. hasła jednorazowego umożliwia jednorazowe zalogowanie się u naszego dostawcy tożsamości. Kim Cameron proponuje wykorzystanie InfoCards. [...]
[...] Kim Cameron shows exacly how to integrate OpenID with Infocards (I think he means Cardspace.) [...]
[...] UPDATE: Kim Cameron’s latest blog post about Integrating OpenID and CardSpace has some nice pictures of the modal OpenID phishing attack scenario. [...]
[...] We’ve got the proposal for Petnames/Passpet, SRP, the creation of an identity manager, the use of InfoCards with OpenID and a raft of others. This is great. The conversation is happening and solutions are being worked on. Wow. Talk about cool. [...]
[...] I don’t know if my Identity Manager post had anything to do with this, but Kim Cameron hurriedly published his supposed initial proposal for OpenID/CardSpace integration. [...]
Kim responds:  I’m not sure my response was published in a very timely fashion, but I certainly did like your post. 
[...] Today Kim blogged his proposed solution for integrating OpenID and InfoCard in detail. He does a wonderful job of it, making it very clear how using CardSpace and OpenID together can be a win/win for both. With Windows Vista shipping to consumers at the end of the month, and the CardSpace upgrade now available to XP users, this is a very practical solution to increasing OpenID security that I expect all XDI.org-accredited i-brokers (who all provide OpenID authentication service for i-name holders) to implement as soon as they can. [...]
[...] Kim posted a pretty good description of how CardSpace and OpenID can interact. This has been talked about for a while and Kim did a great job of describing it. [...]
[...] Anyway, if you haven’t read Ashish’s piece: Kim posted a pretty good description of how CardSpace and OpenID can interact. This has been talked about for a while and Kim did a great job of describing it. [...]
[...] The JanRain engineers were interested in learning more about CardSpace. We’ve heard about it, seen Kim talk and even read his proposal on a way to integrate OpenID and CardSpace. However, we didn’t know enough about the technology to comment on it either way. Also, we wanted to hear more than just marketing hype and hand waving; we wanted some code. Kim and Mike did not disappoint … [...]
[...] Ping will show OpenID to CardSpace integration http://www.identityblog.com/?p=662 According to this post, Ashish Jain at Ping has a new prototype of how CardSpace / OpenID integration will work in their evolving product. It seems to be a continuation of the work they’ve already done with SAML / CardSpace integration - only now, the OpenID protocol has been added to the metasystem mix. Come to think of it, isn’t *** Hardt’s Whobar pretty close to having this capability as well? So I think a number of us have wanted to integrate this work for some time, but recently it has become more obvious what the advantages are. Anyway, if you haven’t read Ashish’s piece: Kim posted a pretty good description of how CardSpace and OpenID can interact. This has been talked about for a while and Kim did a great job of describing it. In short, I agree. In fact, if you want to see a demo of what Kim describes, please stop by Ping Identity’s booth next week at the RSA Conference and you will get to see exactly that. An OpenID IdP Server that uses CardSpace for runtime authentication. It’s not done by any means. There are still some unresolved items. For instance, If the user already has a profile registered with the OP, at runtime should the server use the persisted attributes or the claims as provided by the card? And the support for multiple cards. But you will get the idea. I still have a few questions though. AFAIK OpenID Authentication 2.0 considers authentication out of scope.. So….to prevent phishing and to build user’s confidence, I can use CardSpace. Or anything on the likes of PassMark’s mutual auth. To provide more confidence to the RP, I can use OTP, device finger printing, biometric, certificates, KBA whatever. However there doesn’t seem to be the SAML AuthnContext equivalent to convey this to the RP. Therefore RP has no way to determine the type of OP authentication or if the authentication ever happened. Even if there is way to communicate the authentication type, there is no trust or relationship between the OP and the RP. So….RP (who as a service provider has everything to loose) has no reason to believe that the OP isn’t lying and may have to employ their own safety measures. I’m still coming up the curve so I may be wrong, but something seems missing. I’ll keep looking. Ashish makes an interesting point about conveying the authentication type in the protocol. I certainly agree with him. I also like his question about trust. It’s one others have asked and which I scratched my head about at first. So I’ll put in my two cents worth. In all identity protocols, you have an authority that makes claims about a subject, and the relying party decides whether or not to believe them. As computer nerds we have called that “trustâ€, though in real business environments it’s usually more a matter of reducing risk to the point that, on balance, it’s better to do a transaction than not to do it. But what is â€the trust†(risk analysis) based on? Usually on business relationships. For example, we trust a bank to make assertions of various sorts. And we trust a partner or customer to make other assertions. So the trust is rooted in our experience - in a relationship. This is where OpenID does something different: the authority is simply the behavior of the internet, and the trust only pertains to an identifier (one could layer other capabilities on top of this). Basic Tenets Every person has a URL to which they lay claim. Every URL has an identity provider that “speaks for†it. When I go to a relying party I tell it which URL I claim. Then it sends me to the identity provider that speaks for that URL to get a token saying I really control it. I give that token to the relying party, which then contacts the identity provider to verify the token is valid (the actual protocol includes optimizations). To believe the claim, the Relying Party (RP) needs to trust that the URL has not been tampered with (an evil party could alter it to say an evil identity provider speaks for it). The RP also has to believe it really contacted the URL when finding out who spoke for it (I could have been misdirected through a DNS attack). And it needs to believe it really contacted the identity provider when getting token validation (again trusting DNS). The last two issues can be mitigated by using https, but that complicates it, and even then, the system has different characteristics than one based on cryptographic tokens. All in all, the closest analogy is to using an email address as an identifier by asking what email address you own, sending you the email, and getting you to click a link showing you own the email. In this case the relying party depends on the underlying mail system, DNS, and all that. OpenID replaces email with web URLs. So it’s a lot more direct. Proving control How does an identity service know you really control some URL? Many approaches are possible. Let me give the example of Yahoo’s system (it’s not OpenID but uses the same general idea). You log into their identity provider and it gives you a key (a couple of lines or random gook). You must then paste the key into your html page and press a button back at Yahoo. This causes their system to open your page and see if the key is there. If so, the service deems that you own the URL. Having done this you can get rid of the key and the Yahoo identity provider is willing to “speak for†your control of the URL. The whole process just takes five minutes. Published Monday, February 05, 2007 7:29 PM by Microsoft Filed Under: News, Strategic Partnerships [...]
[...] As an outcome of the discussions that have been taking place here in the Blogosphere - and in-person meetings - it is exciting to convey the following joint announcement by JanRain, SXIP Identity, VeriSign and Microsoft: [...]
[...] The OpenID project is a distributed, web-based single sign-on system that requires no changes to the user’s browser. Unfortunately, as Kim Cameron and Ben Laurie have recently pointed out, OpenID as it is specified makes phishing worse, because an attacker can simply offer OpenID logins on a semi-legitimate web site and then play Man-in-the-Middle for the user’s OpenID login page. OpenID folks have mostly ruled this issue out of scope, which is unfortunate. As it stands, OpenID makes things less secure than they currently are. Some folks are trying to address this issue by augmenting OpenID with other features, for example using a browser plugin. There are also signs that the OpenID community is starting to take this concern more seriously, though no good solution exists yet. [...]
OpenID Gets a Boost From Microsoft…
Microsoft Infocard Well, the headline comes from O’Reilly Radar, and it’s true. But an alternative would be along the lines of “Microsoft comes to OpenID’s rescue”. The point is that OpenID was torpedoed below the waterline on January 19……
OpenID? Huh?…
…
[...] Cameron proposed using CardSpace to authenticate OpenID users at their identity provider. This sounds like one way [...]
[...] description of process (from Microsoft’s Kim Cameron ): An interaction starts with the user telling the RP (relying party) what her URL is (1). The RP [...]
[...] providers are expected to deploy diverse means for securely authenticating their [...]
[...] Jump to Comments Beginner’s guide to OpenID phishing and kinda solution by Kim [...]
[...] Kim Cameron’s Identity Weblog » Integrating OpenID and Infocard - Part 1 (tags: identity infocard openid) [...]
[...] be a browser-toolbar or built-in, a program on USB stick, or a part of the Operating System such as Cardspace. Users will only be tempted into this way of authentication when such tools have become mainstream. [...]
[...] 2, from Kim Cameron’s Identity Weblog, shows what happens “under the hood” when authenticating with [...]
I am just catching up on Cardspace and openID technologies so if I sound ignorant about anything please forgive me.
I like the security provided by Cardspace. The only issue I have with it is that it’s not mobile. I should be able to carry my identity with me just like the identities I carry in my wallet. On the other hand OpenID is mobile but not as secure as Cardspace as is evident from Kim’s post. Mabe answer to OpenID’s security issue is that you only choose reliable IP that also protect you from phishing attacks. As most banks are doing nowadays, the user would want to know something from the IP that you conveyed at the time of signup. It could be a picture of something or even a passphrase.
[...] Cameron maintains an identity blog and discusses the theory behind combining these technologies if you want a more in-depth read. I suggest adding Kim to your RSS [...]
[...] Cameron explains the phishing attack in greater detail and notes: “The problem here is that redirection to the home site is under the control of the [...]
[...] But checks are not very secure for some purposes. Some problems with checks can be reduced by combining a them with another system, such as an identification or credit [...]
[...] to work with Microsoft’s Mike Jones and Kim Cameron who have both been long time proponents of OpenID + Information Card [...]
Identity theft no laughing matter read the news here…
It can occasionally get laborious to split up the good new citibank identity theft commercials facts from the poor….