I do intend to write about mitigation at some point in the near future, but in the meantime points have been raised that I want to respond to.
criticizing the openid spec for not addressing phishing seems to be no different than criticizing the ip protocol because it doesn’t provide reliable, ordered data delivery.
Strangely, people want unreliable, unordered data delivery: it’s a useful service, unlike phishing. He goes on to say
this is old news. yawn.
So are murder and children starving to death.
Gary Krall says
A fair bit of time and consideration was given to some of the issues you raised here at VeriSign. Hans Granqvist drove alot of this in the use of Security Profiles.
and Hans Grinqvist whines (his own words, I promise)
Firstly, the really important stuff: Gary, its “a lot”, and Hans, “the lion’s share”. But seriously, if these address the phishing issue I’m obviously missing something major. From the security profiles document
By agreeing on one or several such security profiles, an OpenID relying party and identity provider can decide the security properties for their mutual OpenID communication before such communication takes place.
Phishing needs security between the identity provider (OP, actually, in OpenID parlance, I wish they’d be consistent) and the user. Can’t really see how security between the RP and the OP is going to address this. How about the “lion’s share” that’s gone into the main document?
A special type of man-in-the-middle attack is one where the Relying Party is a rogue party acting as a MITM. The RP would perform discovery on the End User’s Claimed Identifier and instead of redirecting the User Agent to the OP, would instead proxy the OP through itself. This would thus allow the RP to capture credentials the End User provides to the OP. While there are multiple ways to prevent this sort of attack, the specifics are outside the scope of this document. Each method of prevention requires that the OP establish a secure channel with the End User.
I think this is rather poorly expressed, but clearly describes the attack I have in mind. Almost consistently, it nearly punts on the issue. The one piece of information it adds: “each method of prevention requires that the OP establish a secure channel with the End User” strikes me as unsound, unless you take a rather wide view of the meaning of “secure channel”. There are, for example, zero-knowledge protocols that will not reveal any credentials to a man-in-the-middle, but do not require a secure channel for their execution. In any case, no useful advice is offered, despite claims to the contrary.
It seems to me that if my local software knows who my ID providers are, rather than being told, then the problem goes away?
Indeed, but OpenID’s ground rules are that you should not need local software, and this is the nub of the issue.
Authentication on the web is broken, and has been for a long time. The OpenID fanboys want OpenID to work on any old platform using only standard software, and so therefore are doomed to live in the world of broken authentication. This is fine if what you protect with your OpenID is worthless, but it seems clear that these types of protocol are going to be used to authenticate for things of value. Why else would Verisign be in this game, for example? Or, indeed, Microsoft? Or IBM, HP and T-Mobile?
This is the root of the problem: if you want to protect anything of value, you have to do better than existing Web solutions. You need better client-side software. In an ideal world, this would be a standard component of browsers, but it isn’t. Why? Well, the reason is fairly apparent: the best general way to handle this problem is through zero-knowledge proofs. SRP is an often-quoted example, but there are many simpler ones. However, various (already rich) greedy bastards have successfully blocked wide deployment of these protocols in a cynical attempt to profit from patents that (allegedly) cover them. Sad, I think, that the world continues to suffer whilst a few seek a drop in their ocean of money. Since these general (and, I should add, very simple) solutions cannot be deployed, we end up with purpose-specific plugins instead of general-purpose mechamisms.
we’d love to spend time working with you to figure out what it would take to resolve your issues with the spec. With that said, I really do think that it will come from browser plugins and such.
which is nice. I will accept.