Dick Hardt of Sxip posted a reply to my recent comments on the fears I have about attacks on OpenID:
My good friend Kim Cameron posted the following misinformation on OpenID:InfoCards change the current model in which the user can be controlled by an evil site. OpenID doesnâ€™t.
If a user ends up at an evil site today, it can pose as a good site known to the user by scooping the good siteâ€™s skin so the user is fooled into entering her username and password.
An evil site proxying a web based OpenID Provider is a known security threat in OpenID. There are a number of ways of thwarting this attack, and given that the user has a close relationship with their OP, not difficult to deploy. Similar to the advantages that CardSpace has with a client side implementation, Sxipper is a Firefox plug-in that provides an OpenID user with the same client side protections as CardSpace. OpenID is a protocol, similar at a high level to WS-* â€” so this is somewhat of an apples an oranges comparison. CardSpace could support OpenID and protect the user.Iâ€™d like to see OpenID and InfoCard technologies come together more. Iâ€™ll be presenting a plan for that over the next little while.
Iâ€™m looking forward to seeing your thoughts Kim! Perhaps supporting OpenID in Cardspace?
I'm not just talking about (realtime) proxying. I'm talking about social engineering attacks in general. Where is the misinformation in my description of these attacks?
Dick reassures us that use of the protocol to help convince uers to reveal their credential is a known attack. Should this make me feel better? I don't think so.
I also don't think the mitigations I've heard about are too convincing – with a couple of exceptions.
One of those is the mitigation devised by Dick himself – called Sxipper. This is a plugin for the browser which, as I understand it, take control away from the evil party. If all OpenID implementations were to add this feature it would be a big step forward!
But in that case, if we want to separate apples from oranges, let's not say that InfoCards require a client component and OpenID doesn't. Let's say that to offer reasonable protection, InfoCards require a client component and so does OpenID. That would, as Dick proposes, properly separate discussion of protocols from the overall delivery of an identity solution.
Use of a hardware token at the OpenID site also mitigates the social engineering attack, though not the man in the middle attack.
More later about how Cardspace and OpenID can converge further.
3 thoughts on “Separating apples from oranges”
Comments are closed.