Search Results for: openid

OpenID was designed as a lightweight solution for “trivial” use cases in identity management: its primary goal is to enable Internet surfers to replace self-generated usernames and passwords by a single login credential, without needing more than their browser. Concretely, OpenID aims to enable individuals to post blog comments and log into social networking sites without having to remember multiple passwords. (Of course, local password store utilities already do that; more on this later.)

Beyond this, OpenID is pretty much useless. The reasons for this are many: OpenID is highly vulnerable to phishing and other attacks, creates insurmountable privacy problems, is not a trust system, suffers from usability problems, and makes it unappealing to become an OpenID “consumer.” Many smart people have already elaborated on these problems in various forums. In the rest of this post I will be quoting from and pointing to their critiques.

SECURITY PROBLEMS

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

Kim Cameron explains the phishing attack in greater detail and notes: “The problem here is that redirection to the home site is under the control of the evil party, and the user gives that party enough information to sink her. Further, the whole process can be fully automated.” Elsewhere, Kim points out “think of what we unleash with OpenID… It’s way easier for the evil site to scoop the skin of a user’s OpenID service because – are you ready? – the user helps out by entering her honeypot’s URL! By playing back her OpenID skin the evil site can trick the user into revealing her creds. But these are magic creds, the keys to her whole kingdom!“

Marco Slot in his “Beginner’s guide to OpenID phishing” demonstrates the phishing problem by providing code samples. Quoting: “There’s a new phish in town and it is big and easy to catch. A single OpenID may be used for hundres of websites. This alone makes OpenID more vulnerable as losing one password means you’ve lost them all. Moreover, each of those OpenID enabled websites is able to trick the user into giving away her password. […] Would your grandma notice http://f5888d0b1.07e1c41c97a.be/a15 is not her real openid provider?” Marc also explains why naïve attempts to solve this (such as using cookies, identifying users by their IP address, bookmark login, and displaying personal icons) do not work.

Eugene and Vladimir Tsyrklevich in a recent Black Hat presentation furthermore point out that “the phishing attack can also be carried out by the host that the site consults to retrieve the URL of the identity provider.“

On a note related to phishing, Kim Cameron says: “How do I know I am looking at his web page or talking to his identity provider? By calling them up on DNS. […] OpenID is as strong, and as weak, as DNS. In other words, it is great for transactions that won’t attract criminal attack, and terrible for those that will.” Similarly, Tim Anderson remarks: “The whole OpenID structure hinges on the URL routing to the correct machine on the Internet. In other words, DNS. Now do some research on DNS poisoning. Scary.“

Then there are various browser vulnerability exploits that could have devastating consequences (not just with regard to phishing) if one were to rely on OpenID for anything beyond trivial uses with no real value at stake. Quoting Petko D. Petkov: “Cross-site scripting, also known as XSS, […] works in situations in which attackers need to circumvent the browser security settings […] to get access to unauthorized data using the browser as a proxy. […] Cross-site scripting is an injection attack in which attackers supply malicious code as part of a GET or POST request. It is sent to the attacked application and is then rendered as part of the remotely delivered HTML page. This attack is perfect for stealing session identifiers or creating massive worm outbreaks […] if [users] happen to visit a malicious website that contains an exploit of cross-site scripting vulnerability found on a page from the identity provider origin that is used by the user, attackers could inject malicious code within that scope and hijack the user’s online identity.[…] there are [other] threats such as the cross-site request forgery (CSRF), which is an attack vector that also abuses the browser’s same origin policies, but without the need to inject malicious code within the attacked website context. CSRF attacks perform blind GET or POST requests to resources that are not protected by unique tokens. Since the browser is configured to supply the necessary information, such as browser cookies and other settings to every request, attackers can perform actions on behalf of the user. In this case, if the user is logged into the identity provider and visits a malicious page that executes a CSRF attack that causes a password reset, for example, attackers can hijack the user’s identity again.“

On a similar note, Tom Allen Allen Tom in “What’s broken in OpenID 2.0″ says: “[A phishing site can] spoof the realm using an open redirect server or by exploiting an XSS flaw on a trusted domain means that neither the user nor the OP knows what site that the user is signing into. This leaves users vulnerable to being phished on the RP site because OPs, including AOL and MyOpenID, use the realm and return_to parameters to assert the identity of the RP to the user before redirecting the user back to the RP. For example, it’s pretty trivial for a phishing site to get the AOL or MyOpenID OPs to tell the user that they’re signing into *.aol.com, *.microsoft.com, or *.go.com by exploiting redirect servers or XSS flaws on these trusted domains. […] Redirect servers, open reverse proxies, XSS flaws, and the like are widely known and eagerly circulated within certain communities, and without a doubt these bozos would be cranking out millions of SPIMs and SPAMS every hour if OpenID were to gain any traction in the mainstream.“

It does not stop here. Alex Kuza says: “[There is a] feature to set a site to be able to accept your credentials without you having to enter your OpenID password, and since your OpenID provider does not provide these details to the host, they do. Of course, you still need to be logged into your OpenID provider, but since you’re meant to be using this login for several sites, its not too much of a stretch to believe that you’re going to be logged in all the time you’re online – which is quite a large time frame. […] This means that an attacker can log you into any site you decided to trust via CSRF attacks because the site cannot tell if you’ve entered a password. Now this might not seem important, but it is very important for both large and targeted attacks because the user no longer needs to be logged into the service you want to attack, but merely logged into the central service. Even worse, this fact is completely misrepresented to users. […] Another insecure ‘feature’ is the lack of need to enter a password to register for a site. Out of […] 3 OpenID vendors, only [one] asked users for a password when registering for a site, the other two had only CSRF protections. This is admittedly not particularly serious because you still need an XSS (or similar) flaw in the OpenID provider’s site before you can take advantage of the design idea, but it is rather worrying that people designing secure systems don’t seem to want to implement defence in depth.“

As an example, the Tsyrklevich brothers at the recent Black Hat conference showed how using OpenID for online banking would allow attackers to wire money to their own account using a simple cross-site request forgery attack. They also provided simple sample code for several hijacking, spoofing, and phishing attacks.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.)

PRIVACY PROBLEMS

Second, OpenID suffers from fundamental privacy problems.

For starters, Tom Allen in “What’s broken in OpenID 2.0″ points out the following privacy problem: “In order to free up desirable userids, many large OPs recycle userids belonging to inactive accounts. If an OpenID is recycled, the new owner will be able to access the previous owner’s data if the RP is not aware that the OpenID has changed ownership. This is a very problematic issue for mainstream OPs. For example, if someone (unknowningly) uses a recycled OpenID to sign into Zooomr, the user may see the previous owner’s private photos.“

Secondly, as Jan Miksovsky notes, OpenID’s claim on their site that “OpenID starts with the concept that anyone can identify themselves on the Internet the same way websites do—with a URI” sounds “dehumanizing and more than a little bit frightening.“

These issues may not be of grave concern to many users. There is, however, a much more fundamental privacy problem with OpenID. In the words of Ralph Bendrath : “I have looked into it a bit closer now, and I just can say it sucks. […] Your identity provider is able to track all websites you log into. They even tell you it’s a feature. User profiling made easy! […] You have a unique identifier (your OpenID uri) for all relying parties, so you can’t choose between different cards or identities for different sites. Cross-sites profiling made easy! […] The latter of course can be worked around if you use many different IDs. But then you run into the usability problems that OpenID was meant to overcome in the first place – having to remember several logins, passwords and so on.“

As a blog commentor puts it: “Is nobody of you guys concerned about the openid tracking capabilities? Who would wanna sign up with openid and let them know what websites you visit on a daily basis?” The Tsyrklevich brothers sum it up as follows: “the IdP can spy on the user’s activity on the Internet as it is a central clearing place for all of the user’s logins.” Or, in the words of a blog poster with the pseudonym Mordaxus, OpenID is “a huge boon for anyone who wants to start tracking on the web. […] if you want to steal from people or invade their privacy, OpenID is for you.“

In a piece called “Why OpenID is going to destroy the Internet”, Ilya Lichtenstein says: “I’m not the paranoid conspiracy-theorist type, but even I am terrified of what could happen if all of our actions on the Internet could be tracked to a single identity. Imagine Big Brother coming across an offensive post you made on an anti-government website, and then tracking you through every book you bought, every comment you made, every song you listened to. Don’t say that this is already possible with an IP address- it takes a court order to get a name from an IP address, but your creepy neighbor could easily stalk you from your OpenID. […] Anonymity is one of the strengths of the Internet that allows for so much free expression- without it, the Internet loses one of its key strengths. […] Imagine a key logger or trojan compromising your OpenID password because you logged in from an insecure public computer. Now, the hacker controls every element of your digital life- so much for using different passwords on different sites for security. Imagine an OpenID server being compromised- there go thousands of identities, full complete identities compromised with ease. OpenID would be a ripe target for hackers. […] And, finally imagine what OpenID promises- all of your online identities, connected and unified. Do you really want that?“

Clearly, if OpenID were to be considered uses on a grander scale, the privacy implications would be enormous. As the author of a blog post titled “OpenID: A great thing… going amok?” puts it: “More than anything else, privacy and free will would be my biggest concerns. […] What I don’t like is being assigned an OpenID (or anything else for that matter). […] Personally, I was a bit peeved when WordPress turned this blog into an OpenID without ever asking me. […] Now, let’s take that to another level: an entire nation requiring citizens to use OpenID. The thought sets butterflies on a wild ride through my belly.“

So much for privacy. Credentica’s technology, in contrast, provides ultra-strong privacy guarantees that are provided by design. These features, as do our multi-party security features, require more client-side intelligence than today’s standard Web browser. Even if OpenID were to embrace such client-side intelligence, however, its simplistic URL architecture would be fundamentally incompatible with privacy features such as untraceability, unlinkability, authenticated anonymity and pseudonymity, and minimal disclosure.

TRUST PROBLEMS

Third, there is the OpenID issue of trust (or rather, the lack thereof). The old OpenID site was quite explicit in this regard: “ What about trust? This is not a trust system. Trust requires identity first.” As the author of a piece titled “The OpenID Farce” objects: “Ummm, no. Actually, Identity requires trust first. Identity without trust is meaningless. […] OpenID is Yet Another Identity Transport System… without trust. […] an identity/trust system needs to convey that “‘This is Steve’ and I’ll back that up with $XX if I’m wrong” or “‘This is Steve’ by the authority of the State of California with all of the rights and responsibilities thereof”. […] If you can’t make that promise, don’t talk to my about ID.” Or, in Jeremy Schoemaker’s words: “There’s nothing stopping a fake Mark Cuban from creating a fake OpenID, or worse, a fake identity provider.“

Even for the trivial use cases that OpenID is used for today, this poses a major problem if OpenID were to gain in popularity. By way of example, a commentor at Slashdot notes: “Once this system is widely used, and spammers begin to register OpenIDs in huge numbers, how will site owners prevent spammy registrations? […] Blindly trusting OpenIDs and allowing them into a site, or giving them posting rights would be crazy. […] If [this problem] it isn’t solved we have a one-stop-shop for spammer IDs.“

USABILITY PROBLEMS

Fourth, OpenID suffers from usability problems.

Neil Cauldwell in a piece titled “OpenID is too complicated” says: “I can log-in to any OpenID friendly site just by typing in ‘NeilCauldwell.com’. But do I ever use it? […] I’m already signed-up with all the services I use on a regular basis, and have a password manager that handles the usernames. In it’s current state, OpenID isn’t going to do much for me […] Why sign-up to OpenID when your favourite sites are bookmarked by the browser, and authenticated by a password manager? […] Even if they have an OpenID, [users] still need to create and fill-out a unique profile within each service they use. This means OpenID creates a double login procedure. As we already know, once is bad enough.“

Jan Miksovsky notes: “The process of selecting an OpenID provider will stump the average consumer. […] Why would a site operator let anyone leave their site to perform a task from which they will never return? […] Currently, even those sites that do implement OpenID generally treat OpenIDs as a second-class form of identification. They put their own proprietary means of signing in (generally with a user name and password) on their home page, and bury the OpenID sign in facility behind a link. […] And all this is for—what, exactly? To save me from having to pick a user name and password? [….] I can’t imagine a sane business operator forcing their precious visitors through this gauntlet of user experience issues just for the marginal benefits that accrue to a shared form of ID. […] there’s no business of any size that can afford to direct their traffic down a dead end.“

ADOPTION PROBLEMS

Fifth, while lots of organizations are jumping in to become OpenID providers, there are virtually no OpenID consumers.

Dana Epp writes: “I could care LESS if Six Apart or Technorati can be an OpenID provider. I don’t particularly have a lot of care or trust in them. I want these sites to trust MY provider… which in this case is my own corporate authentication server. […] I think that is getting lost with all these players.“

Nik Cubrilovic in a piece titled “OpenID: Too many providers, not enough consumers” writes: “There have been a spate of announcements recently with a number of companies both large and small announcing that their products will ’support’ OpenID. […] All these OpenID support announcements and I am not getting anywhere with my OpenID. [….] it seems that while we have plenty of companies wanting to step up us providers (easy) and have their users use their OpenID’s with other applications, we don’t have enough companies stepping up as consumers of OpenID. […] it seems that OpenID is flavor of the month and everybody is jumping on for the ride (I could post ‘Burger King Supports OpenID’ and it would make the frontpage of digg). […] It seems that most of the justification for the big companies and other apps not wanting to be providers is so that they can protect their customer base and maintain a hold.“

Microsoft’s Dare Obasanjo points out that this reluctance to become an OpenID consumer may well be a fundamental problem: “When you look at the long list of Open ID providers, you may be notice that there is no similar long list of sites that accept OpenID credentials. In fact, there is no such list of sites readily available because the number of them is an embarassing fraction of the number of sites that act as Open ID providers. Why this discrepancy? If you look around, you’ll notice that the major online services […] all provide ways for third party sites to accept user credentials from their sites. This increases the value of having an account on these services [which] increases the likelihood that I’ll get an account with the service which makes it more likely that I’ll be a regular user of the service which means $$$. On the other hand, accepting OpenIDs does the exact opposite. It actually reduces the incentive to create an account on the site which reduces the likelihood I’ll be a regular user of the site and less $$$.“

Last, but not least, becoming an OpenID consumer means that another site (potentially a competitor, now or in the future) learns in real time which person is visiting at what time – potentially very valuable competitive information.

IMPERSONATION PROBLEMS [this section added on June 3, 2008]

As a consequence of the fact that an OpenID provider sees in real time which sites you log into, it also has the capability to log into any of these sites as “you”, possibly without you ever being able to find out. This is particularly problematic in cases of sites that would give access to personal account information following login via OpenID. Do you really want to give that much power to insiders at OpenID providers? Keep in mind that an “insider” may not just be unscrupulous management, but also a rogue employee, a virus, or a hacker with the proper privileges. [end of addition made June 3, 2008]

AVAILABILITY PROBLEMS

Still another concern is pointed out by the author of a blog called Internet Duct Tape: “The decentralization that is openID’s strength is also it’s biggest weakness. If your openID server goes down then you’re locked out of *all* of your other web accounts that used that login. […] In order to login to a web app with openID the web app needs to be working AND my openID server needs be working. The greater number of interconnecting parts decreases my chances of getting everything to work together much more than the benefit of not having to manage multiple user accounts. […] if you use someone else’s openID server then you’re screwed.“

PATENT PROBLEMS

What all of the above points at is that OpenID is lots of pain with little (if any…) gain. If that is not enough reason for concern, then perhaps the following issue is. This particular concern relates to OpenID’s claim that it is an “open, decentralized, free framework for user-centric digital identity:“

The issue here is not so much the one that Neil Cauldwell points out: “If [users] sign-up to a service that only supports OpenID’s from certain servers, OpenID isn’t even open. At least with a proprietary sign-in process you be under no illusions that the username you created with service ‘x’ would work with service ‘y’. But if the big players decide to mess about with server authentification, your OpenID may or may not work at another site. This is where it becomes a complete mess.

No, the real issue is that various parties have made claims that OpenID is covered by their patents. One patent is mentioned at the Wikipedia page on OpenID, which mentions a pending USPTO patent application with PCT priority from Denmark of March 9 2001 that “covers the central aspects of OpenID.“

Other patents may apply as well. Jeff Bohren says, “Dave Kearns […] talks about the patents that Sxip Identity has applied for which appear to cover OpenID. He relates that Dick Hardt assured him that Sxip Identity will be issuing non-assertion statements on OpenID soon. Of course I find it odd that a company would spend the time, effort, and money to pursue IP that they already don’t intend to enforce. […] the Sxip Patent Applications so far made public include […] these.“

Chuck Mortimore, who used direct SXIP’s engineering efforts, states “I think its a gross mis-representation of the truth to say OpenId was based upon SXIP,” but that is not necessarily an indication that the SXIP patents do not cover OpenID.

Even if one were to take the position that the abovementioned patents are pre-dated by tons of prior art and/or are “obvious to those of ordinary skill in the art,” that may hardly be reassuring for sites that establish themselves as OpenID providers or consumers – they risk being presented at any time in the future with litigation threat for patent infringement. The “pledges” made by various players involved in OpenID that they will not sue for patent infringement do not prevent certain litigation scenarios from becoming a reality.

CONCLUSION

So, there you have it – why we’re not working to ensure that our technology works with OpenID: there are simply irreconcilable differences between the two. Now, mind you, it IS possible to do a drastic overhaul of OpenID so that it will be possible to provide multi-party security and privacy. Doing so would amount in essence to discarding most of the OpenID work, keeping only the notion that in some cases it might be useful for individuals to facilitate “identity provider discovery” by providing a URL. The reality is that at such a point we’re not talking about an improved OpenID system anymore, as the use of a URL for IdP discovery would pretty much all that would remain.