Links

Ben Laurie blathering


OpenID and Phishing: Episode II

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.

First, the ridiculous (I hope there’s some sublime somewhere): HeresTomWithTheWeather says

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)

There have been, since October 2006, a set of defined OpenID security profiles. The lion part of the profiles have been incorporated into the core spec.

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.

My friend, Adam Shostack, muses

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.

Finally, if I might go all Slashdot on you for a moment, from the light-at-the-end-of-the-tunnel department, David Recordon of Verisign Labs (and an editor of the OpenID specs) says

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.

11 Comments »

  1. So, are those the right ground rules? I think (and I’m not thinking for my employer here) that if we need client software, and I think we do, then we should figure out what that is and build it into the browsers.

    Comment by Adam — 20 Jan 2007 @ 21:45

  2. [...] Problem phishingu w OpenID jest bardzo poważny i nikt nie zamierza tego negować. Ben Laurie napisał na ten temat dwa ciekawe wpisy, w pierwszym z nich dość prowokacyjnie stwierdza, że OpenID jest rajem dla phisherów. I trudno odmówić mu niestety racji. [...]

    Pingback by identity 2.0 / Phishing w OpenID — 21 Jan 2007 @ 0:10

  3. [...] Like me, Ben was struck with how readily the system currently lends itself to automation of phishing attacks.  His second post on the subject is interesting. [...]

    Pingback by Kim Cameron’s Identity Weblog » Ben Laurie explains the “Kittens” phishing attack. — 21 Jan 2007 @ 3:12

  4. How does adding zero-knowledge proofs to the spec address the phishing problem?

    Comment by Krishna — 21 Jan 2007 @ 13:54

  5. [...] Numerous ideas to mitigate phishing attacks have been floating around the OpenID list and on the OpenID mini-blogsphere. Ben Laurie argues for a client-side solution: 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. [...]

    Pingback by dready blog v2.0 » Blog Archive » Browser-based mitigation of phishing attacks — 21 Jan 2007 @ 18:59

  6. [...] Dready’s right about the research.  But rather than calling it a “social problem” I’d call it a “social engineering attack”.  Further, there is a protocol problem.  The protocol is based on telling the RP where the OP is located - such that an evil site can automate a “man in the middle attack”.  Some other protocols, including the one used by CardSpace, do NOT have this problem.  That’s why combining CardSpace and OpenID is useful.  Numerous ideas to mitigate phishing attacks have been floating around the OpenID list and on the OpenID mini-blogsphere. Ben Laurie argues for a client-side solution: 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. [...]

    Pingback by Kim Cameron’s Identity Weblog » Can browser-based plugins solve the phishing problem? — 12 Feb 2007 @ 6:31

  7. I am more or less convinced – and admittedly I am highly biased – that OpenID is unlikely to get into serious usage for anything commercially sensitive. There are already a slew of protocols (SAML 2.0 / Liberty ID-FF, WS-*, Cardspace, Higgins, Shib, blah) that deal with most of the issues much more robustly.

    If the trust issues that you raise here are not addressed by OpenID, then it seems most unlikely that it will achieve significant “real world” deployment.

    Comment by Michael Barrett — 2 Mar 2007 @ 18:30

  8. [...] In sum, OpenID adds up to little more than simple password management with extra overhead and lots of security problems. As Marc Canter stresses: “if we’re to stop phishing, and spoofing and ID theft – we need severe crypto, locked down, secure ID systems.” Ben Laurie elaborates as follows: “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. […] 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. […] the best general way to handle this problem is through zero-knowledge proofs.” (Note: this is exactly what Credentica’s technology does.) [...]

    Pingback by The Identity Corner » The problem(s) with OpenID — 22 Aug 2007 @ 23:30

  9. [...] OpenID and Phishing: Episode 2 [...]

    Pingback by OpenID sucks. « Outside the Bubble… — 19 Oct 2007 @ 20:15

  10. [...] Links » OpenID and Phishing Ben Laurie’s criticisms of openIDs security model, and responses dealt with (tags: identity security blog 2007) [...]

    Pingback by links for 2007-10-30 « Spartakan — 30 Oct 2007 @ 5:26

  11. [...] spoofing and ID theft – we need severe crypto, locked down, secure ID systems.” Ben Laurie elaborates as follows: “The OpenID fanboys want OpenID to work on any old platform using only standard software, [...]

    Pingback by The problem(s) with OpenID « The Identity Corner — 11 Feb 2008 @ 1:31

RSS feed for comments on this post. TrackBack URI

Leave a comment

Powered by WordPress

Close
E-mail It