Links

Ben Laurie blathering


OpenID: Phishing Heaven

OpenID announced the release of a new draft of OpenID Authentication 2.0 today. I’m reluctantly forced to come to the conclusion that the OpenID people don’t care about phishing, since they’ve defined a standard that has to be the worst I’ve ever seen from a phishing point of view.

OK, so what’s the problem? If I’m a phisher my goal is to be able to log in to some website, the Real Website, as you, the Innocent Victim. In order to do this, I persuade you to go to a website I control that looks like the Real Website. When you log in, thinking it is the Real Website, I get your username and password, and I can then proceed to empty your Paypal account, write myself cheques from your bank account, or whatever fiendish plan I have today.

So, why does OpenID make this worse? Because in the standard case, I (the phisher) have to make my website look like the Real Website and persuade you to go to it somehow – i.e. con you into thinking I am the real Paypal, and your account really has been frozen (or is that phrozen?) and you really do need to log in to unphreeze it.

But in the OpenID case I just persuade you to go anywhere at all, say my lovely site of kitten photos, and get you to log in using your OpenID. Following the protocol, I find out where your provider is (i.e. the site you log in to to prove you really own that OpenID), but instead of sending you there (because, yes, OpenID works by having the site you’re logging in to send you to your provider) I send you to my fake provider, which then just proxies the real provider, stealing your login as it does. I don’t have to persuade you that I’m anything special, just someone who wants you to use OpenID, as the designers hope will become commonplace, and I don’t have to know your provider in advance.

So, I can steal login credentials on a massive basis without any tailoring or pretence at all! All I need is good photos of kittens.
I had hoped that by constantly bringing this up the OpenID people might take some step to deal with the issue, but they continue to insist on punting on it entirely:

The manner in which the end user authenticates to their OP [OpenID provider] and any policies surrounding such authentication is out of scope for this document.

which means, in practice, people will authenticate using passwords in forms, as usual. Which means, in turn, that phishing will be trivial.

47 Comments

  1. 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.

    Comment by HeresTomWithTheWeather — 19 Jan 2007 @ 15:30

  2. Bravo! Go, Ben!

    Comment by Erik Abele — 19 Jan 2007 @ 15:35

  3. TomWithWeather, you are not getting it.

    What Ben is saying is that OpenID worsens the phishing problem because Relying Parties are not authenticated, meaning anyone can become one then send them anywhere, including places that mimic popular OpenID Providers. All they have to do is create two website, one to lure and another to fool, using a stolen credit card.

    All hope is not lost though. I’ll be introducing a password-less OpenID Provider soon to erase the phishing vulnerability completely since you can’t lose what you don’t have.

    Comment by Don Park — 19 Jan 2007 @ 15:54

  4. Do you have any ideas on how to help solve this in such a way that we don’t lose the ease-of-use nature of OpenID?

    Comment by Scott Kveton — 19 Jan 2007 @ 16:00

  5. this is old news. yawn.

    Comment by HeresTomWithTheWeather — 19 Jan 2007 @ 16:07

  6. [...] 아시다시피  Phising Attack 이라는 것은 교모하게 위장된 로그인 페이지를 통해 사용자를 속이고 낚인 사용자는 무의식적으로 패스워드를 입력하여 자신을 위험에 빠뜨리게 되는 누군가 한번은 겪어 봤을 만한 요즘 아주 흔한 abuse 패턴이다. 야후는 얼마전부터 “personalized sign-in seal” 을 통하여 이러한 문제들에 대한 해결책을 사용자에게 제시하고 있다 아주 ì•…ëž„í•œ 사용자는 OpenID identity provider 의 로그인폼을 그대로 흉내냄으로서 전형적인 man-in-the-middle-attack 을 가할 수가 있다는 점이 지적되었다. Ben Laurie 의 OpenID: Phishing Heaven” 글은 이런 문제를 보다 자세히 다루고 있다. [...]

    Pingback by Keun-woo Ryu’s blog » Blog Archive » OpenID 그리고 Phishing — 19 Jan 2007 @ 19:01

  7. Building on what Scott said, 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. I’ll be in town next week if you have time.

    Comment by David Recordon — 19 Jan 2007 @ 19:54

  8. Scott:

    If I log into my OP before I visit any site, then there is no opportunity to show a login page and so no opportunity to phish. No?

    Comment by Aswath — 19 Jan 2007 @ 20:10

  9. Ben: 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.

    For reference see: http://commented.org/

    Comment by Gary Krall — 19 Jan 2007 @ 20:25

  10. It seems to me that if my local software knows who my ID providers are, rather than being told, then the problem goes away?

    Comment by Adam — 19 Jan 2007 @ 21:05

  11. Actually, this could help prevent phishing, because you would just have to authenticate with *one* OpenID Provider instead of with every service you use. For example, if you save the password in your browser, a fake OpenID Provider site would instantly create suspicion as there would be no password saved for it.

    Comment by Sheepmaster — 19 Jan 2007 @ 21:26

  12. The problem you’re describing here is:
    – usually, identity providers don’t authenticate themselves to the user; and
    – OpenID will train users to expect to be redirected to identity providers.

    I think this is an important criticism, but as far as I know, it could be equally applied to *any* third-party web-based auth system. Passport (without Windows login integration), the former SXIP protocol, you name it. Are there any that handle this better? Or is this something that just can’t be handled at the level of web pages and HTTP redirects level?

    I tend to believe that good OpenID providers will just need to smarten up about things like security images, or other ways to authenticate themselves to the user.

    Comment by Neil K — 19 Jan 2007 @ 22:03

  13. There is the same problem in the very similar Shibboleth system that is widely used in many academic institutions today. As in all phishing situations, the onus is on the client to understand that he needs to a) make sure he is using SSL and that b) when he sees the browser flag a problem with the SSL enabled home provider login page, he better not just click through. Unfortunately there are still a lot of people that could fall for this.

    Comment by Tim Freeman — 19 Jan 2007 @ 23:28

  14. The Verified by Visa specs got that point right god knows how long ago. It would seem obvious to have a third party handle the match-making.

    Merely getting the OpenID site to do the redirecting and provide the authentication result back would handle it. As long as MyKittenPicsPhishingSite.com can’t know who the provider is it can’t fake it.

    Well, it sounds simple that way. The clever bit would involve having the provider validating unique information with the OpenID party independently to prevent MyKittenPicsPhishingSite.com from standing in and proxying everything. Lots of handshaking but then only OpenID has to be trusted, not every sites relying on OpenID.

    Comment by Alexandre Carmel-Veilleux — 20 Jan 2007 @ 0:14

  15. Of course, my comment pre-supposes that by “ease of use”, it’s the user (and possibly authentication service user) who need to have ease of use. Some complexity has to be shifted to the provider.

    Comment by Alexandre Carmel-Veilleux — 20 Jan 2007 @ 0:16

  16. FYI, VbV’s antiphishing protection is limited to a shared text phrase called personal assurance message (PAM) which is, unfortunately, easily overlooked.

    IMHO, security often stems from non-technical factors. In case of OpenID, its typically low-incentive applications that keeps the phishers at bay. Of course, when and if banks start using OpenID, sharks will arrive quickly.

    Comment by Don Park — 20 Jan 2007 @ 15:28

  17. [...] OpenID facilitates phishing. What can be done about this? [...]

    Pingback by The Undevelopment Blog » Blog Archive » Identity Manager: A Browser-Based Solution to OpenID Phishing — 20 Jan 2007 @ 19:17

  18. [...] OpenID facilitates phishing. What can be done about this? [...]

    Pingback by Kim Cameron’s Identity Weblog » Dmitry Shechtman’s Underdevelopment Blog — 21 Jan 2007 @ 0:20

  19. [...] Several people have now written about this problem, including Ben Laurie and Simon Willison.  Here’s an idea for how to deal with it. [...]

    Pingback by Usable Security » Blog Archive » Phishing and OpenID — 21 Jan 2007 @ 1:00

  20. [...] The “Phishing and OpenID” discussions on the OpenID list actually hinges on point #2 above. Ben Laurie wrote about it here. In short, OpenID opens the door for a malicious RP to send a user to a spoofed OP-lookalike and collect his/her password. [...]

    Pingback by dready blog v2.0 » Blog Archive » Security Restricted Domains Database — 21 Jan 2007 @ 17:23

  21. [...] OpenID 2.0 and Phishing January 21st, 2007 | Category: OpenID, JanRain, Identity, Phishing There has been a bunch of discussion about OpenID 2.0 and how the latest draft does not address phishing at all. [...]

    Pingback by Blog by Kveton » OpenID 2.0 and Phishing — 21 Jan 2007 @ 22:51

  22. I had registered at pip.verisignlabs.com and they ask the users to upload a picture of theirs. When trying to login to the Identity provider the user can verify whether it’s a authentic page or a phishing one by looking for his image. The posing website has little chances that it will be able to get hold of your picture upload with the Identity provider. I think that’s a good thinking.

    Comment by Debashish — 22 Jan 2007 @ 20:10

  23. I think you’re right to be concerned about phishing, but I think OpenID is also right to say that how an OP and end user authenticate each other is none of their business. Passwords are easy to implement but they are not the only way.

    I’m using IP address see: http://digitalconsumption.com/forum/A-simple-solution-to-OpenID-phishing-attacks

    Others might use a cryptographic certificate, etc. Awareness of the risks is key and it’s up to the OPs to provide the answer.

    Comment by Charles Darke — 23 Jan 2007 @ 2:34

  24. [...] 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. [...]

    Pingback by Benlog » BeamAuth: Two-Factor Web Authentication with a Bookmark. — 6 Feb 2007 @ 20:47

  25. I’ve now put up proof-of-concept code here:

    http://digitalconsumption.com/forum/A-simple-solution-to-OpenID-phishing-attacks

    Comment by Charles Darke — 6 Feb 2007 @ 23:35

  26. Has anyone noticed that OpenID relies on Diffie-Hellman key exchange for associations between RP and OP? This is strange because DH is subject to a well known MITM attack where the attacker negotiates a separate key with each party (in this case RP and OP) can observe and alter all subsequent messages at will. This essentially renders protections offered by OpenID DH-SHA1 and DH-SHA256 association sessions worthless.

    Comment by Mark — 13 Feb 2007 @ 22:47

  27. It would be great if browsers implemented something similar to ssh known_hosts so you get an alert if some tries to impersonate your OpenID provider. Otherwise surely people will be happily handing over their login details to they know not who.

    Comment by Steve — 25 Feb 2007 @ 14:58

  28. [...] It’s not all rosy though. Many people have pointed out that the OpenID process is very susceptible to phishing attacks; but that’s a problem we’re going to have to solve somehow anyways, and I think the proposed solutions are pretty decent. Technorati Tags: authentication, openid, security, single sign on, usability [...]

    Pingback by Dubroy.com/blog » Warming up to OpenID — 26 Feb 2007 @ 19:20

  29. I think that using client-side SSL certificates works quite well for OpenID. I started https://certifi.ca/ as an OpenID provider that uses only certs from industry-standard CAs for authentication. No passwords, never. Is it possible to phish users of such a system? I’m not sure, but there are probably going to be some small percentage of people who email their certs to strangers if they’re convinced to do so. However, I think the danger goes down considerably.

    I’ve also found the workflow in using OpenID with certifi.ca considerably improved. It’s a very smooth process, since I’m logged in to certifi.ca by default.

    Comment by Evan Prodromou — 2 Mar 2007 @ 23:06

  30. Have you actually used OpenID?

    I have an SSL certificate in my browser that authenticates me with my provider. When a site asks for authentication, it queries my provider who can definitely agree it is me because of my certificate. That is all.

    I don’t enter a password!

    Hence it cannot be phished. That is the whole point of OpenID…

    Comment by Richard — 15 May 2007 @ 16:11

  31. Evan, even if you did email your certificate to someone, they would not be able to use it unless they knew your passphrase.

    Comment by Richard — 15 May 2007 @ 16:12

  32. [...] Let’s start with the security problems of OpenID: As Ben Laurie in a piece called “OpenId: Phishing Heaven” notes: “The OpenID people [have] defined a standard that has to be the worst I’ve ever seen from a phishing point of view. […] I just persuade you to go anywhere at all, say my lovely site of kitten photos, and get you to log in using your OpenID. Following the protocol, I find out where your provider is (i.e. the site you log in to to prove you really own that OpenID), but instead of sending you there (because, yes, OpenID works by having the site you’re logging in to send you to your provider) I send you to my fake provider, which then just proxies the real provider, stealing your login as it does. I don’t have to persuade you that I’m anything special, just someone who wants you to use OpenID, as the designers hope will become commonplace, and I don’t have to know your provider in advance. So, I can steal login credentials on a massive basis without any tailoring or pretence at all! All I need is good photos of kittens.” [...]

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

  33. [...] Checks are very easy to understand. They are like a paper promise that can be easily accepted by many individuals and businesses. The promise is to be paid with money withdrawn from the account identified on the check. There is very low cost for businesses to accept checks. 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 card. [...]

    Pingback by dale olds’ virtualsoul » Banking on the One True Internet identity system — 18 Sep 2007 @ 0:37

  34. [...] OpenID – Phishing Heaven [...]

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

  35. What you are talking about is beyond the scope of the OpenID spec. Anti-phishing mechanisms are the responsibility of OpenID providers as any form of authentication can used, not just orthodox username/password auth.

    It is a balancing act between usability and security. The problem you describe is that OpenID, like PayPal, teaches users that it’s ok to follow links to an apparently trusted site to login.

    PayPal *could* combat phishing by never allowing users to login on the checkout landing page.. instead writing a cookie (containing a unique payment ID) and telling the user to open a new browser window, go directly to the PayPal site (using a bookmark maybe) and login to continue with the transaction. But that sucks from a usability perspective and so many users wouldn’t complete transactions.. so that’s never going to happen.

    Comment by Kristian — 6 Dec 2007 @ 1:42

  36. [...] still some major issues [PDF link] with the system.  The main technical one is to do with phishing and man-in-the-middle attacks (the rogue/malicious identity provider), whereas others revolve around privacy and usage [...]

    Pingback by More sign-ups for OpenID | Mike Andrews — 20 Jan 2008 @ 22:50

  37. [...] critiques.SECURITY PROBLEMSLet’s start with the security problems of OpenID.As Ben Laurie in a piece called “OpenId: Phishing Heaven” notes: “The OpenID people [have] defined a standard that has to be the worst I’ve ever seen [...]

    Pingback by The problem(s) with OpenID « The Identity Corner — 6 Feb 2008 @ 9:07

  38. I made a similar observation in June 2005

    Comment by Paul Crowley — 15 Feb 2008 @ 16:40

  39. [...] don’t trust it: This has been discussed extensively elsewhere, and there’s been more heat than light thrown on the issues. But my own personal [...]

    Pingback by Web Worker Daily » Archive OpenID: A Contrarian View « — 21 May 2008 @ 19:00

  40. [...] is that I do not know whether the basic model is secure or not. I’ve read lots of pro and con posts, and it’s gone so technical I don’t know who to [...]

    Pingback by thomas.apestaart.org » OpenID: yes or no? — 19 Jun 2008 @ 23:06

  41. [...] guy called Thomas asks the very reasonable question (where “this problem” is the OpenID phishing problem): Too much of all of this discussion around OpenID focuses around whether or not it’s OpenID’s [...]

    Pingback by Links » Using OpenID Responsibly — 20 Jun 2008 @ 12:46

  42. [...] level it’s being closely scrutinized. Issues range from traditional phishing attacks to those targeted more towards the OpenID users. (Here is an excellent demo of how a man-in-the-middle attack can phish your OpenID [...]

    Pingback by Passpack Security Just As Strong With OpenID « Passpack Blog — 5 Aug 2008 @ 16:04

  43. [...] has been sent there by the “someone else’s Web site” in question leads to the standard critique of OpenID as increasing phishing [...]

    Pingback by New York Times seriously confused about identity management « Random Oracle — 12 Aug 2008 @ 10:25

  44. A few ways to make OpenID more secure:

    The OpenID standard must make sure that the providers support atleast one of the two methods below (to mitigate a costly set up, so a home user can also become an OpenID provider):

    a) authentication via text message to your registered mobile phone. The text message should be a token generated using a hash of your public SSH key (which you uploaded at time of registration) or a security key (not necessarily SSH key) generated for you by the server at the time of registration. You must reply to that message with the earlier message contents (the token sent to you) and you will be authenticated. The web-page which was redirected to by the consumer would already have just given a message that you were not logged in (in case you were not) and a link to retry which would just invoke the same redirect (or an auto refresh of the same page); if logged in, it redirects back to consumer website

    b) authentication using email. Same as above except that instead of a text message you receive an email at your registered address with the token in subject header and you just reply to that, keeping the token intact. If the provider is paranoid, they may ask you add, at end of subject line, or in email body (option) two random letters (which letters are required would be mentioned in the body of the email) from your atleast 10 letter password – the usual caveats of a strong password must be applied by the provider at time of registration – after all, it is going to be one of the very few passwords you will need because of OpenID.

    If you, as a user, have neither a mobile phone nor an email account, you cannot use OpenID (unless there is a similar secure option, I do not like the static IP address option because it is limiting in my being able to use my OpenID from anywhere on internet)

    Even if Open ID becomes secure due to proper authentication mechanism (use of only one of the explicitly methods must be allowed, and form based authentication as well as the need to enter the password must not be one of those methods), I dislike the idea that my OpenID roams freely on the internet – this can be prevented by making it mandatory in OpenID standard that all consumers send a one way secure hash (SHA/MD5 etc., the hash algorithm options should be explicitly stated in the OpenID standard) of the OpenID, not the OpenID itself. I know a non-legitimate consumer website will still be able to capture your OpenID (I do not want to give the user a cryptic one way hash string generated from their chosen login ID, at time of registration, to use as login ID at consumer websites in future)

    Comment by Mahender Didwania — 30 Jan 2009 @ 1:49

  45. ah, and I forgot to add that the 3rd method, mentioned by someone earlier and adapted here, could be to send the message with the token to your registered jabber ID, to which you reply with the same token…

    so, one or more of 3 methods should make it reasonably resilient (assuming the email may not get delivered instantly for example, if email servers are under attack or in general are under load…)

    client certs may be an option, but not for the average casual user on the internet, who is only too familiar with email and IM (so can adapt to jabber, because I would hate proprietary protocols of Yahoo/MSN/others in OpenID) but is not familiar with client certificates (for this reason, I did not insist on use of public-private keys either, just made it optional)

    Comment by Mahender Didwania — 30 Jan 2009 @ 2:00

  46. If you implement something like a Yubikey (from Yuico) or PhoneFactor.com (which is FREE), then you cut the risk of phishing and man-in-the-middle significantly. You should have the PAPE and AQE OpenID extensions installed too so that Yadis can detect and inform the RP of their presence. This gives the RP some comfort in knowing that certain security policies are in-place.

    Comment by BravoZulu — 2 Oct 2009 @ 0:56

  47. [...] redirects — an undelightful part of the OpenID experience — are also a phishing risk. Ben Laurie explains how OpenID is a phishing heaven with a kitten site [...]

    Pingback by A smart browser that knows who you are | Rebecca Cottrell — 19 Dec 2010 @ 20:39

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress