an unwarranted bashing of Twitter’s oAuth

Posted on September 2, 2010 by ben

Ryan Paul over at ArsTechnica claims a compromise of Twitter’s oAuth system, but fails to demonstrate such a compromise. It’s unfortunate, because some of his comments are indeed worthwhile, and there are a few interesting recommendations that Twitter should follow (hah, no pun intended). But what we have here is not a “compromise”, and the citation-and-reasoning-free fear-mongering about oAuth is poor reporting.

the consumer secret is not important

The article’s main argument is that the oAuth consumer secret is embedded in desktop clients and can be extracted. Yes. That sounds really bad doesn’t it? Except, as the article itself says:

It’s very important to understand that a compromised consumer secret key doesn’t jeopardize the security of the users of the application. The key can’t be used to gain access to the accounts of other users, because accessing an individual account requires an access token that individual instances of the client application obtain automatically on behalf of the user during the authorization process.

Ahah, you say, but the article also says:

the problem is how Twitter is using the key

Oh no! What are they possibly doing with this key that they shouldn’t be doing?

These keys are particularly significant because Twitter has configured them to enable access to special APIs which aren’t generally available yet that can be used to exchange login credentials for an access token

So in other words, with a consumer secret, you can exchange a username/password for an oAuth access token. That’s not ideal, because it means that we’re back to clients proxying usernames and passwords, but how is that a compromise? If an app successfully captures your username and password, and the app is evil, you’re screwed already! In fact, it’s probably a good thing that Twitter then pivots and says “ok, fine you got the password, but can you please just exchange it for this access token now and not store the password?” Furthermore, Twitter even says that this approach, which they call xauth, is the “least desirable way to authenticate,” and they require apps that want to use this feature to request special approval.

I don’t see a security compromise here. I see a complicated set of design issues on which Twitter is trying to make practical security decisions. It’s certainly reasonable to disagree with them, but it’s unwarranted to claim that oAuth security has been “compromised” or that Twitter made this decision “against all reason.”

spamming is a darn good explanation

The article says:

The issue here is that Twitter wants to use the keys as an abuse control mechanism to centrally disconnect spammers and other unwanted users of the service, but OAuth was simply not designed to be used for that purpose. The idea is that centrally disabling a spammer’s consumer secret key will lock out all of the spammer’s user accounts, theoretically simplifying spam control for Twitter. It’s unlikely that this naive strategy will work in practice, however.

Any spammer with a hex editor can trivially compromise the keys of popular applications and use those keys to evade Twitter’s abuse controls.

Ummm, no. As the article itself states, a spammer who takes another application’s keys still doesn’t have the access tokens, and so it cannot spam.

In fact, spamming is a very good reasons for Twitter’s use of consumer keys and secrets even in desktop clients: a spammer in this case is going to be an application that has legitimately authorized a bunch of users, and then decides to go crazy and spam their feeds. In that scenario, Twitter can very easily temporarily disable that one consumer key+secret, or throttle it, or kill it altogether, without having to trace down all the access tokens that consumer generated. I like this reason a lot.

increase the risk of phishing? No

In the past, I’ve been critical of OpenID for increasing the risk of phishing. So one might think I would agree with the article when it says:

Individual implementations aside, the general concept behind OAuth’s redirection-based authorization process materially increases the risk of phishing. The people behind the standard are fully aware of that fact, but they don’t believe that the issue should necessarily be addressed by the standard itself.

I think that’s wrong. There’s a key difference here: what’s the alternative to oAuth? The alternative is the password anti-pattern, where all those third-party apps capture your username and password. So sure, it would be good if oAuth providers had more phishing-resistant login mechanisms, say like BeamAuth (shameless plug). But, on the whole, oAuth is still a heck of a lot less phishing-prone than the password anti-pattern it’s trying to replace.

open-source and DOS: fair points

The article does make a fair point about open-source software, JavaScript-based clients, and generally the possibility that some loser might sabotage a legitimate app by copying a consumer token and secret and abusing it. If that happens a lot, then Twitter will certainly have to come up with a new approach. But let’s at least understand that there is no good approach to this problem. If no attempt is made at tracking which client is which, then one bad spamming apple could ruin it for everyone, since there’s no way to differentiate the good from the bad. Twitter may have to rethink its automatic consumer-kill policy and become a bit more nuanced, but that’s just a policy decision. At the protocol level, I don’t know how they could do much better, given that even closed-source software, as pointed out by the article, can be easily disassembled.

override the callback URL? That’s a good point

The article claims that an attacker can change the callback URL in a Twitter oAuth session, which would indeed enable a very sneaky phishing attack. I didn’t think that was the case, but it may be. I agree with the article’s take on this:

Ideally, OAuth implementors should require application developers to supply the callback address when they configure their key and should not allow that setting to be overridden by the client application in a request parameter. Twitter has a field in the key configuration that allows the developers to specify a default, but they still allow client applications to use the dangerous callback override parameter.

I think the article is right on this point. There are many reasons to disallow callback overrides, and there’s no good reason for it: oAuth web apps need cookie-based session support anyways to complete the oAuth process, there’s no need to dynamically add state to the callback URL. It would be good to do away with this “feature.”

a few very good small points

The article makes some very good smaller points that Twitter (and other oAuth providers) should heed:

  • debugging oAuth is hard, and having more explicit error messages is a good idea
  • logging out is confusing: if you log out of the app, are you logged out of the oAuth identity provider? Flickr does this very well with Yahoo ID integration, so oAuth and Twitter should indeed provide more guidance on this front.
  • giving users more cues for trusting certain apps is probably a good idea. This can evolve over time, though, and the protocol won’t need to change.

These are all useful points. But they’re small, and they do not warrant a big scary title.

all hail oAuth 2.0!

The most confusing part of the article is the constant harping on oAuth 1.0a as “immature” when it has been deployed by dozens of high-profile providers, and the constant praise of oAuth 2.0, which has only just been released and actually weakens security to make developers’ lives easier (I’ve written before about the oAuth 2.0 problems). It’s possible that oAuth 2.0 is much better in ways I haven’t considered, but where’s the evidence? The article doesn’t say.

unnecessary insults

The article concludes:

Although I think that OAuth is salvageable and may eventually live up to the hype, my opinion of Twitter is less positive. The service seriously botched its OAuth implementation and demonstrated, yet again, that it lacks the engineering competence that is needed to reliably operate its service. Twitter should review the OAuth standard and take a close look at how Google and Facebook are using OAuth for guidance about the proper approach.

There’s no evidence of this so-called “botched” job. Sure, some smaller points are absolutely worth considering, and I applaud the author for digging deep on some of these. But I find unfortunate the overall tone of the article, the baseless and gross exaggerations, and the condescending writing that ignores reasonable justifications for Twitter’s decisions.

This entry was posted in security, web. Bookmark the permalink.
  • Miguel de Icaza

    You are missing the point Ben.

    The article claims that oAuth does well web to web connections and it does. The problem is that native-client to web to oAuth and oAuth+xAuth is completely useless. You might want to read on that, because your entire article misses that point, over and over:

    http://dev.twitter.com/pages/xauth

    It does not avoid the pishing problem as the user does not have a way of telling if an app is any more trusting than anything else.

    Your whole section of phishing is based on assumptions, and not facts about OAuth/xAuth at twitter. Read the doc.

    And since oAuth+xAuth require you to enter the login+password in the first place, it turns out that they are 100% dead weight. There is /nothing/ that oAuth+xAuth gives you that Basic authentication over SLL or the built-in HTTP challenge/response system would not have provided (this one would safeguard your password just as oAuth/xAuth do).

    Your section on “spam” is incorrect too, it takes 10 minutes to extract the official twitter keys and build a proof of concept.

    And the “consumer secret” discussion is irrelevant.

    The problem is that twitter is using oAuth/xauth for clients where it does not solve /any/ problems in that space, merely makes things worse.

  • Miguel de Icaza

    You are missing the point Ben.

    The article claims that oAuth does well web to web connections and it does. The problem is that native-client to web to oAuth and oAuth+xAuth is completely useless. You might want to read on that, because your entire article misses that point, over and over:

    http://dev.twitter.com/pages/xauth

    It does not avoid the pishing problem as the user does not have a way of telling if an app is any more trusting than anything else.

    Your whole section of phishing is based on assumptions, and not facts about OAuth/xAuth at twitter. Read the doc.

    And since oAuth+xAuth require you to enter the login+password in the first place, it turns out that they are 100% dead weight. There is /nothing/ that oAuth+xAuth gives you that Basic authentication over SLL or the built-in HTTP challenge/response system would not have provided (this one would safeguard your password just as oAuth/xAuth do).

    Your section on “spam” is incorrect too, it takes 10 minutes to extract the official twitter keys and build a proof of concept.

    And the “consumer secret” discussion is irrelevant.

    The problem is that twitter is using oAuth/xauth for clients where it does not solve /any/ problems in that space, merely makes things worse.

  • Ben Adida

    I challenge you to build that proof of concept: you’ll still need the access tokens to perform spamming.

    For desktop apps, there are fewer benefits than for web apps, I agree, but there are still some:
    (a) you have a real log of which apps are doing what on your behalf, as opposed to every app proxying as *you*
    (b) you can disable an app without having to change your password
    (c) your password isn’t stored anywhere in the clear.

    But even this discussion we’re having I don’t mind: let’s have it. That’s not what that article says. That article says that Twitter’s oAuth has been compromised. I think that’s just false.

    But it’s easy to prove me wrong: build the proof of concept and see if you can spam my account.

    (reposted as me)

  • Ben Adida

    I challenge you to build that proof of concept: you’ll still need the access tokens to perform spamming.

    For desktop apps, there are fewer benefits than for web apps, I agree, but there are still some:
    (a) you have a real log of which apps are doing what on your behalf, as opposed to every app proxying as *you*
    (b) you can disable an app without having to change your password
    (c) your password isn’t stored anywhere in the clear.

    But even this discussion we’re having I don’t mind: let’s have it. That’s not what that article says. That article says that Twitter’s oAuth has been compromised. I think that’s just false.

    But it’s easy to prove me wrong: build the proof of concept and see if you can spam my account.

    (reposted as me)

  • http://ben.adida.net Ben Adida

    Miguel and I have been having a fun discussion about this, so I’m adding one clarification: stealing someone’s consumer key+secret is not a big deal. Why? Because that key doesn’t let you access any accounts on its own.

    So, if I steal Miguel’s awesome open-source Mono-based Twitter client’s oAuth’s consumer key+secret, the best I can do is release a piece of code or web site that behaves like it’s his code. That sucks, but nothing practical can prevent that kind of spoofing. The good thing is, say you logged in with Miguel’s client, I have no access to your account even though I took Miguel’s consumer key+secret. Because to access your account, I also need the *access token* that Miguel’s client obtained from Twitter when you logged in using his software. And of course that I cannot get from his open-source code repo, because that’s stored locally on your machine where the software was installed.

    So, again, I maintain that making a big deal about this consumer key/secret is for nothing. You can’t do much with that consumer key/secret. In the worst case, you can blame another app for your actions, but you can’t see what they see.

  • http://ben.adida.net Ben Adida

    Miguel and I have been having a fun discussion about this, so I’m adding one clarification: stealing someone’s consumer key+secret is not a big deal. Why? Because that key doesn’t let you access any accounts on its own.

    So, if I steal Miguel’s awesome open-source Mono-based Twitter client’s oAuth’s consumer key+secret, the best I can do is release a piece of code or web site that behaves like it’s his code. That sucks, but nothing practical can prevent that kind of spoofing. The good thing is, say you logged in with Miguel’s client, I have no access to your account even though I took Miguel’s consumer key+secret. Because to access your account, I also need the *access token* that Miguel’s client obtained from Twitter when you logged in using his software. And of course that I cannot get from his open-source code repo, because that’s stored locally on your machine where the software was installed.

    So, again, I maintain that making a big deal about this consumer key/secret is for nothing. You can’t do much with that consumer key/secret. In the worst case, you can blame another app for your actions, but you can’t see what they see.

  • Pingback: All This Twitter OAuth Security Nonsense « hueniverse

  • http://robertgentel.com/ Robert Gentel

    I took his Ryan Paul’s article as largely excoriating that Twitter is willing to block applications on the basis of failure to protect a secret they can’t protect.

    The compromise is clearly illustrated, you can break third-party twitter applications by publishing their keys and force them to issue an updated client with new keys from Twitter.

  • http://ben.adida.net Ben Adida

    I’m sure that policy will evolve if people are breaking third-party apps maliciously. And if the article focused on that, I wouldn’t really raise any issue. But the title of the article is a “compromise of Twitter’s oAuth”, and that’s how it’s spreading. And that’s just not true.

  • http://robertgentel.com/ Robert Gentel

    If you look at it from the perspective of the developer, it *is* a compromise of their security.

    I’m sure Twitter policy will change, in the comments of that article misguided folks are talking about publishing the tokens to popular clients to force Twitter to do so, and even running servers providing valid tokens extracted from clients so that open-source software can continue to function.

    But saying that the policy will indubitably change because it is untenable is no way to indict pointing out that said security policy is untenable.

    Yes it will change, that is the inevitable consequence of their implementation (at least as it is described in that article, full disclosure would be for me to point out that I have not touched the code myself).

  • http://robertgentel.com/ Robert Gentel

    If Twitter is willing to invalidate the extracted keys as Paul claims, that is *not* the worst you can do. You can break their app, making all their users get a cryptic authentication error until you can push out a new update to them.

  • http://twitter.com/KateYoak Kate Yoak

    I am still confused.

    1. It sounds to me that transmitting the secret key is fundamentally the wrong approach to security, specific application aside. It’s one of those things that senior people teach junior members of the team before they give them they keys to the car, so to speak.
    2. Creating a situation where to combat spam, you have to disable an entire hub hurts innocent lives. :-) In other words, I wouldn’t want to face the fallout of a major twitter client being locked out for even hours! The advertising industry has learned to avoid blanket approaches to spam control, lest they ban their entire client base.

  • http://ben.adida.net Ben Adida

    OK, I see this as a valid point. I suspect that policy will be quite a bit more nuanced soon. But they can change that policy without changing anything about the protocol. They can finesse it, depending on how badly things get abused.

    So again, valid point, but it doesn’t change the fact that this article grossly exaggerates its claims, and there isn’t any compromise of Twitter’s oAuth protocol itself.

  • http://ben.adida.net Ben Adida

    I hear you, the whole oAuth thing is a bit confusing.

    (1) The secret key isn’t being transmitted in the protocol, it’s just part of the client software. There’s no other way to do it, really. You could just NOT have a secret key, but then that simply removes Twitter’s ability to do *some* tracking of which apps are posting stuff. In other words, the only other design is one that has even fewer capabilities.

    Robert’s says Twitter’s current decision process for handling a bad actor is bad. I think he’s got a point. Twitter will have to see if their policy hurts a lot of good guys more than bad guys. But that policy can be altered without changing the protocol, and the protocol still provides *some* ability to tease out some of the bad actors in some cases. That’s useful, even if it’s not perfect.

    (2) I think the specific spam situation that Twitter is trying to address here is this: some Twitter client, say AcmeTwitter, has a security compromise that allows an attacker to remotely control it and start spewing spam into your stream. How can Twitter easily disable *all* of those clients. Certainly, this is not a solution to one user spamming away, and I doubt Twitter would disable AcmeTwitter if just a handful of its users are spammers. But if AcmeTwitter the software itself goes bad, it’s a good idea for Twitter to have that extra control point to shut it down instantly.

  • http://twitter.com/KateYoak Kate Yoak

    (1) Are you sure? Ryan Paul’s article claims “Against all reason, Twitter requires every single application—including desktop and mobile software—to supply a consumer key and a consumer secret. ”
    Obviously, if that statement is wrong, I grant your point.

    (2) I yield the gavel to Robert Gentel. His makes enough sense for both of us!

  • http://ben.adida.net Ben Adida

    (1) Quite sure, I’ve built a few Twitter apps and have implemented oAuth in a bunch of other settings. I’m pretty sure Ryan Paul was complaining about the fact that desktop+mobile software also have to use a consumer key and secret, but I’m quite sure the secret is not sent in the protocol, it’s used to compute a signature, which is then sent.

    (2) Robert makes good points for sure! But if you read the comments on the article, it’s clear everyone thinks Twitter is being bone-headed, stupid, and their oAuth implementation is so broken that you can compromise accounts. That’s just not true. And that kind of misleading content is poison to productive debate. So let’s debate the exact Twitter policy for shutting down Twitter apps, I think Robert’s points are very worthwhile. But let’s not call it a security compromise of Twitter accounts, because it’s not.

  • Tatu Saloranta

    But how exactly do you think it could be changed? Either you invalidate consumer secret (with nasty consequences), or you let abusing fake client impersonate the other app. I think that was the exact point — best they can do seems to be to NOT use consumer secret for anything, which offers less authentication (wrt which client app it is that is being used for whatever abuse), but also less downside since there is nothing to revoke.

    Now as to no compromise of protocol… that goes into semantics; maybe wording is not optimal, but clearly there is a significant issue and one that seems very likely to materialize very soon. This based on seeing how various abuser (like spammers) make use of opportunities available to them.

  • Ed Finkler

    It doesn’t help matters that Twitter has dropped the ball in addressing many of the concerns raised by OSS devs — concerns raised many, many months before Basic Auth was dropped. Concerns raised directly on the dev mailing list were frequently met with silence. When plans were put in place to offer a somewhat more workable solution for obtaining consumer keys, it was prototyped, implemented by a couple FOSS projects… and subsequently ignored. Weeks went by without comment on the project, until finally a Twitter employee admitted it would not be ready for Basic Auth deprecation.

    Cynicism is going to run deep for people on the dev side, especially folks who have been part of that community for years.

    There are a lot of very smart people on Twitter’s dev team, but an an organization Twitter has done a poor job of engaging with developers and addressing concerns, particularly open source devs. This is, I think, where Twitter blew it.

  • http://ben.adida.net Ben Adida

    I can’t speak to that, Twitter may well have screwed up in the communication effort with FOSS developers. That’s unfortunate.

    But that was not the point of the article, and not the point of my response. If Twitter screwed up on communication, then that should be pointed out. But false claims of security compromises help no one.

  • http://ben.adida.net Ben Adida

    No, this is not semantics: Twitter could choose to allow for bogus consumer keys/secrets, or to never revoke them, and that would be purely a policy decision that doesn’t change the technical protocol. They may do that, I have no idea.

    But again, regardless of this, the claim of account compromise and spamming are just wrong.

  • Pingback: an unwarranted bashing of Twitter’s oAuth (Ben Adida/Benlog) | Home Equity Loan Rates Online

  • Pingback: an unwarranted bashing of Twitter’s oAuth (Ben Adida/Benlog) | Website Hosting Providers

  • Pingback: » links for 2010-09-03 (Dhananjay Nene)

  • http://auth.mit.edu/keithw Keith Winstein

    Ben, fair enough, but I don’t read the Ryan Paul article as making any claims of account compromise or spamming; in fact he stresses “It’s very important to understand that a compromised consumer secret key doesn’t jeopardize the security of the users of the application.”

    In fact Twitter did just ban the MIT BarnOwl client yesterday (used for Zephyr and Twitter) because, hey, it’s an open-source program and its client secret is public. I think there were similar troubles with Gwibber that were fixed by schmoozing. My colleague Nelson Elhage has discovered that Twitter’s own Android client continues to use basic auth, albeit with a special query string (“source” parameter) that opens up a Twitter backdoor where basic auth is still accepted.

    I can’t say I feel strongly about Twitter, but as a case study they just do not seem to have thought this through.

    No other Web site seems to have decided to permit apps in control of the principal, while attempting to distinguish them and screen out malicious apps. Flickr does not have a plan for disabling a Windows app that claims to upload your pictures to Flickr, accepts your credentials, and then uploads child porn instead. Gmail does not have a plan for disabling an IMAP/SMTP client that claims to connect to its servers and show you your email, but really it sends the emails to a bad guy. This kind of phishing simply isn’t something a remote protocol counterparty can effectively police — isn’t it exactly the kind of principal-agent problem that you and your colleagues have studied probably a lot more thoroughly than anybody else here?

    The solution to malicious Twitter Web services is probably browser blacklists (like any other phishing site), and the solution to malicious client apps is probably a similar kind of backlist — or in the case of software distributed centrally (e.g., Ubuntu, Debian, iPhone), revocation from the repository.

    If Twitter thinks that, alone among all Web sites, they can successfully remotely police ersatz clients acting with legitimate end-user credentials, that seems crazy ambitious and unlikely to succeed. Am I wrong?

  • http://auth.mit.edu/keithw Keith Winstein

    Ben, fair enough, but I don’t read the Ryan Paul article as making any claims of account compromise or spamming; in fact he stresses “It’s very important to understand that a compromised consumer secret key doesn’t jeopardize the security of the users of the application.”

    In fact Twitter did just ban the MIT BarnOwl client yesterday (used for Zephyr and Twitter) because, hey, it’s an open-source program and its client secret is public. I think there were similar troubles with Gwibber that were fixed by schmoozing. My colleague Nelson Elhage has discovered that Twitter’s own Android client continues to use basic auth, albeit with a special query string (“source” parameter) that opens up a Twitter backdoor where basic auth is still accepted.

    I can’t say I feel strongly about Twitter, but as a case study they just do not seem to have thought this through.

    No other Web site seems to have decided to permit apps in control of the principal, while attempting to distinguish them and screen out malicious apps. Flickr does not have a plan for disabling a Windows app that claims to upload your pictures to Flickr, accepts your credentials, and then uploads child porn instead. Gmail does not have a plan for disabling an IMAP/SMTP client that claims to connect to its servers and show you your email, but really it sends the emails to a bad guy. This kind of phishing simply isn’t something a remote protocol counterparty can effectively police — isn’t it exactly the kind of principal-agent problem that you and your colleagues have studied probably a lot more thoroughly than anybody else here?

    The solution to malicious Twitter Web services is probably browser blacklists (like any other phishing site), and the solution to malicious client apps is probably a similar kind of backlist — or in the case of software distributed centrally (e.g., Ubuntu, Debian, iPhone), revocation from the repository.

    If Twitter thinks that, alone among all Web sites, they can successfully remotely police ersatz clients acting with legitimate end-user credentials, that seems crazy ambitious and unlikely to succeed. Am I wrong?

  • Anonymous

    > it’s clear everyone thinks Twitter is being bone-headed, stupid

    For being the least technically inclined reader of this article, I can assure you: no, not “everyone”—most Ars readers are heavy-duty geeks with massive contrarian reflexes, but even then, most are not technical enough to go forward; only those moderately interested in hacking social network distributed autentification (aka they have a Shrine to Schneider’s Church of pragmatism in Computer Security visible from their multi-screen set-up) make it to the jest of it, and if they have, they come accross many counterpoints — so I’d say, he shouldn’t be more concerned about superficial readers that you were when you wrote “Twitter may well have screwed up in the communication effort with FOSS developers.”
    He could be less rude, less sensationalist, more to the point and use more visual explanations, but he uses enough alphabet soup to assume that little harm has been done.

  • Anonymous

    > I’m sure that policy will evolve if people are breaking third-party apps maliciously.

    I like you assumption that twitter is an intelligent agent that adapts to its environment. ;)

  • Anonymous

    You mean, you would make twitter not work for some time? Users will be so-o surprised. ;)

    Thank you for clarifying that, thought.

  • http://ben.adida.net Ben Adida

    Keith,

    I agree with you and others that Twitter should rethink their approach of auto-banning consumers whose secrets have been “compromised,” and yours is a particularly good example of why. At some point I’ll write an additional post on why I think there remains value in asking clients to announce themselves (it has to do with defense-in-depth), but let’s put that aside for now: let’s assume for the sake of this argument that there is indeed no value in announcing desktop consumers.

    My claim is that the article is very misleading and makes a number of unsupported security claims against Twitter. Look first at the title: “Compromising Twitter’s OAuth security system.” There’s no such thing happening. Then consider these additional quotations pulled from the first few paragraphs:

    • “Twitter’s extremely poor implementation of the OAuth standard offers a textbook example of how to do it wrong.”
    • “The OAuth standard has many significant weaknesses and limitations.”
    • “The current version of the standard—OAuth 1.0a—is an inelegant hack that lacks maturity and fails to provide clear guidance on many critical issues that are essential to building a robust authentication system.”

    These claims could be true… if the author presented any evidence! The only evidence presented points to Twitter’s consumer-deactivation policy for desktop clients, not to the overall security of their oAuth implementation. Worse, these statements are made without context regarding desktop vs. web-based apps. The article’s only complaint, really, is regarding desktop apps, yet the one-liner that clarifies that is buried after paragraphs that condemn Twitter’s entire implementation.

    The problem with the article’s spamming claim is that it forgets the biggest hurdle a spammer would have to go through to succeed: first extract the consumer keys, then authorize a whole bunch of accounts using a stolen consumer key and secret, then spam. I’m not saying it can’t be done. But the way it’s phrased implies that all the spammer needs to do is get the consumer secret. Most comments I’ve seen on that article around the Web indicate that people missed that large caveat and assume there’s a security hole that’s immediately exploitable. There isn’t. And spammers could do exactly the same thing to Google and Facebook’s implementations, since you don’t have to announce yourself there.

    The only “there there” is a problematic consumer-deactivation policy.

    I tried to take great care to give credit to the author regarding the valid points he made: in particular I’ll point out that Twitter should definitely stop allowing the redirect_url to be overridden. I think I was pretty fair to him. Even upon re-reading the article just now, I get the same overall impression I got the first time around: this is a deactivation-policy problem, and maybe a “Twitter overreaching on what oAuth can do for it” problem, but it’s being touted as a big security compromise, in the title, in the wording of a number of paragraphs, and in the effect it’s having on even savvy readers around the Web. It’s not a security compromise, and given how difficult it is for any company to combat rumors of security holes, I find the article irresponsible. I think in that respect the author should issue a correction.

  • http://ben.adida.net Ben Adida

    I’m unable to rethread my response to this comment appropriately, that’s what I get for changing commenting systems half-way through the life of this post…

    I’ll restate one important thing in response to your last point, Miguel: you say “The problem is that twitter is using oAuth/xauth for clients where it does not solve /any/ problems in that space, merely makes things worse.”

    I disagree that it solves no problems, and I’ll post something soon to argue that at length. But even if you were entirely right in that statement, the article on ArsTechnica is unjustified in its security attacks. There is no major compromise of Twitter’s oAuth implementation, at best there is valid criticism of their client disabling policy.

  • Pingback: Gentel ben | Mycfosandiego