Slashdot Mirror
After Two Fixes, OAuth Standard Deemed Secure (net-security.org)
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."
"[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.
"First they came for the slanderers and i said nothing."
That tends to be the rub.
much of left-wing thought is a kind of playing with fire by people who don't even know that fire is hot - George Orwell
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:
Likewise section 9 of the OAuth 2 RFC:
And the article "OAuth 2 Simplified" by Aaron Parecki 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. 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
It's free and it's better than nothing at all.
Mission accomplished. God job, boys. Let's go home and get some!
... and doesn't use php or systemd
oauth is currently the most insecure auth protocol there is in wide use, there are way to many vectors that are vulnerable to attacks
Just give up on oauth already and use SAML. SAML has its own problems but every revision is tightening it up and its fixable while oauth isn't, SAML doesn't require client side java script and never will. Goolge were so wrong with oauth its crazy, their sales arm continue to try to mold companies to use oauth and it just embarrasses them whenever they sit in front of security personnel from a large company. Turns out the security they give to individuals is kinda weak when compared to what law requires of a banking transaction.
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.
OAuth2 security issues
Still a good critic from a contributor of OAuth 1.0
http://hueniverse.com/2012/07/...
And the problem is that "making" a correct implementation is where all the hard work is and there is no guidelines.
OAuth is an overly complex framework built upon unsecure fundations (the web).
Security is expensive. The real identity check should be in the real world, and there should be human checking and validating.
Security should not be made 100% in the same plan as communication and THAT is the weakness of all security making MITM so easy.
You can even have trusted CA x509 top of the security without REAL checks.
Computer security is a SCAM.
And now computers can break passwords that human can remember, the secrets are not possibly in the only safe place possible which is a brain.
Over exposure of personnal data (birth, relationship) makes that you hardly have any secrets any way.
The future is to build an internet without security. It will mean the end of e-commerce, ads powered contents ...
You will have your library/swimming pools openings, news that can sustain without ads, university papers, public domain data; administrative forms to print and addresses of administrations, quake servers, BBS, technical sheets.
The serious people in business could drop security and just have human pick a phone number, validate that customers are who they pretend to be and have all the "business data" being given on another plane (coursier, phone, banks) according to the cost/benefits and if they store credentials, they can use totally isolated networks internal to their buildings and use coursier/post to send hard drives with physical seals on them.
I crave for the future boring web that is useful again with 1Kb web pages.
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.