Separating apples from oranges

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&#39m not just talking about (realtime) proxying.  I&#39m 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&#39t think so. 

I also don&#39t think the mitigations I&#39ve 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&#39s not say that InfoCards require a client component and OpenID doesn&#39t.  Let&#39s 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.