Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Bug Networking The Internet IT

After Two Fixes, OAuth Standard Deemed Secure ( 19

An anonymous reader writes: OAuth 2.0 is one of the most used single sign-on systems on the web: it is used by Facebook, Google, Microsoft, GitHub and other big Internet companies. A group of researchers from University of Trier, Germany, have performed the first formal security analysis of the OAuth 2.0 standard, and have discovered two previously unknown attacks that could be mounted to break authorization and authentication in OAuth. However, says the article, "[w]ith these problems solved, the researchers ultimately concluded that OAuth 2.0 is secure enough to provide both authorization and authentication -- if implemented correctly."
This discussion has been archived. No new comments can be posted.

After Two Fixes, OAuth Standard Deemed Secure

Comments Filter:
  • by phantomfive ( 622387 ) on Sunday January 10, 2016 @02:57AM (#51271463) Journal
    The problems haven't been fixed yet, the summary would be more accurate to say:

    "[w]ith these problems solved, the researchers ultimately concluded that OAuth 2.0 WOULD BE secure enough to provide both authorization and authentication -- if implemented correctly."

    The problems they found were two man-in-the-middle attacks. One of them is kind of silly: it uses an HTTP 307 redirect to redirect the login request to a malicious server. The malicious server will be given the user's credentials.

    • The summary is stupid anyway. It was deemed secure before the two problems were discovered; and it will be deemed insecure when the next issue comes up.

      • True, true. Whether or not it is deemed secure has very little to do with whether it is actually secure. As Bruce Schneier says, "Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can't break."
    • by WoOS ( 28173 ) on Sunday January 10, 2016 @06:58AM (#51271819)

      No, the first attack assumes the identity provider to use an 307 request in answering a valid used identification request from the malicious server (which might look to the outside as a normal service while secretly retrieving user password). As far as I understand the forward will always happen in the protocol. The assumption is that this is done with a 307 request [] instead of 302 (or 303). This was apparently allowed by the OAuth specification (although one can of course wonder why any ID provider would not use 302 or 303).

      Reading the original paper [] (and not just the blog) really helps to understand the attacks. With respect to the second attack I immediately thought that it wasn't worse than any authentication not using HTTPS. But the authors point out that they attack a step of the protocol (selection of ID provider) not normally considered sensitive so it could happen in HTTP.

    • Bull (Score:4, Insightful)

      by Etherwalk ( 681268 ) on Sunday January 10, 2016 @08:13AM (#51271905)

      Oauth 2.0 will never be "secure enough" until it is very, very hard to implement it *incorrectly*.

      Right now there are a lot of modules out there to integrate Oauth 2 into your website, and you can re-use a lot of your code from old projects, but there is no single trivial way to make your website secure. So long as that's the case, people are going to screw it up. LOTS of people are going to screw it up. Especially when they're being paid to deliver a marketable website, and nobody outside of a few key market sectors are going to pay for serious security auditing. Or, you know... any security auditing.

    • If implemented correctly......our current software is full of bugs, full of security problems, but it doesn't need to be that way. When security is taken into consideration by every member of the team from the beginning, then security bugs will be an exception rather than something that happens every hour.

      The problem is, companies don't care, and so programmers are not trained to focus on security. So we have the internet in the current messy state.
    • That's not the rub. This, this is the rub.

      You look tense. Buck up, amigo. *slap* Oh wow, you feel tense. All through your shoulders. Let me get that.

      No no, it would be a favor to me. I got to keep my hands in shape. Feels tense right here, is that where you feel it? Oh, yeah that's tense too.

      Bow chicka bow wow...

  • The requirement for client credentials in implementations of OAuth produces a couple practical problems.

    OAuth 1 and OAuth 2 are unrelated protocols with similar names. The spec for each discourages servers from requiring client credentials (a client ID and client secret) in an API intended for use in an app that runs on the user's computer, such as a desktop or mobile app. As stated in section 4.6 of the OAuth 1 RFC []:

    In many cases, the client application will be under the control of
    potentially untrusted parties. For example, if the client is a
    desktop application with freely available source code or an
    executable binary, an attacker may be able to download a copy for
    analysis. In such cases, attackers will be able to recover the
    client credentials.

    Likewise section 9 of the OAuth 2 RFC []:

    Native applications that use the authorization code grant type
    SHOULD do so without using client credentials, due to the native
    application's inability to keep client credentials confidential.

    And the article "OAuth 2 Simplified" by Aaron Parecki [] states:

    If a deployed app cannot keep the secret confidential, such as Javascript or native apps, then the secret is not used.
    mobile apps must also use an OAuth flow that does not require a client secret.

    Yet several service providers offering APIs built on OAuth 1 or OAuth 2, notably Twitter, require them. Despite it being trivial to pull client credentials out of an executable with tools such as strings, Twitter has been known to disable any client credentials that leak to the public []. There are two workarounds, both cumbersome:

    • The first, recommended by OAuth 1 spec author Dick Hardt [], is to proxy all API calls through a server that the app developer operates. The API keys then never leave this server. Yet the app developer needs to find some way to recover the cost of operating this proxy server.
    • The other, as recommended by Raffi Krikorian [] and Chris Steipp [], requires each user to register with the service provider as a developer, obtain API credentials through the developer console, and enter those into the user's own copy of the application. Because providers tend to refuse to offer a means of automating application registration, each application has to include a walkthrough for registering a copy of an application and update this walkthrough whenever the service provider changes the design of the developer console. In addition, developer consoles tend to require a minimum age of 18 to rather than 13.

    OpenID 2.0, an authentication protocol, did not require relying parties to obtain client credentials. It was intended that a user would paste his identifier URI into a form on the relying party's web site (or use a browser extension to autofill it), and the user would be briefly redirected to the identity provider's web site for verification. Very few identity providers required relying parties to register; the only one I could think of was PayPal.

    But unlike OpenID 2.0, which was open by default, the OAuth 2-based OpenID Connect is closed by default. It requires each relying party to obtain client credentials from each identity provider's developer console, which requires O(n^2) contract executions. There's theoretically a way for a relying party to obtain client credentials automatically, called Dynamic Client Registration (dyn-reg), but to my knowledge

    • by naasking ( 94116 )

      That's quite sad. It seems like a good way is to simply assume your keys have a short lifetime (perhaps a few days), and obtain new ones on expiry.

      • It seems like a good way is to simply assume your keys have a short lifetime (perhaps a few days), and obtain new ones on expiry.

        Twitter's reply was phrased such that Twitter would ban the developer from creating new keys if it has to expire the new keys because the new keys leaked.

%DCL-MEM-BAD, bad memory VMS-F-PDGERS, pudding between the ears