After Two Fixes, OAuth Standard Deemed Secure (net-security.org) 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."
Summary wrong, not secure (Score:5, Insightful)
"[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.
Re: (Score:2)
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.
Re: (Score:2)
Re:Summary wrong, not secure (Score:4, Informative)
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 [wikipedia.org] 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 [arxiv.org] (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)
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.
... secure enough ... if implemented correctly. (Score:1)
That tends to be the rub.
Re: (Score:2)
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.
Re: (Score:2)
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...
Client credentials are a roadblock (Score:5, Informative)
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 [ietf.org]:
Likewise section 9 of the OAuth 2 RFC [ietf.org]:
And the article "OAuth 2 Simplified" by Aaron Parecki [aaronparecki.com] states:
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 [nelhage.com]. There are two workarounds, both cumbersome:
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
Re: (Score:2)
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.
Multiple leaks would lead to a ban (Score:3)
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.
OAuth2 is rife with security issues (Score:1)