Slashdot Mirror
A Truckload of OAuth Issues That Would Make Any Author Quit
New submitter DeFender1031 writes "Several months ago, when Eran Hammer ragequit the OAuth project, many people thought he was simply being overly dramatic, given that he gave only vague indications of what went wrong. Since then, and despite that, many companies have been switching to OAuth, citing it as a 'superior form of secure authentication.' But a fresh and objective look at the protocol highlights the significant design flaws in the system and sheds some light on what might have led to its creator's departure."
*sigh* "conflict between the web and the enterprise worlds." is another way of saying users complained when not given an option to aim at their foot.
Join the Slashcott! Feb 10 thru Feb 17!
What are you talking about? The original submitter? Eran Hammer? The blog being linked to?
I honestly don't know what you're referring to -- could you explain for those of us who are out of the loop?
What are you talking about?
Step one: Make digital card game.
Step two: Print cards and sell them.
Step three: Profit more from WOW.
I think it's a complaint about (and I hesitate to link to it) this post which keeps showing up story after story.
OAuth is ugly to implement, no argument there.
Most of the points made in the article were interesting and seemed valid to me but near the conclusion it felt like the author was reaching bit by ignoring the refresh token concept to make the final point.
The threat of a hacked browser was a bit of an eye opener for me -- never heard that one brought up as a possibility while working on an OAuth implementation for a client.
Can a hosts file block apk's posts, though?
The authors biggest complaint about OAuth is that it doesn't do what it was never designed to do....and this is a problem because....? It was never designed for enterprise-level permissions management(there are plenty of other solutions for that). And his solution(copying and pasting tokens) is worse than the disease. It would be easier to go phishing with copied and pasted tokens than it is with OAuth where the login is automatic and tokens/applications can be revoked by the site that manages the account....
I think someone is just bitter and decided to take it out on a protocol.
Monstar L
That's it, I've had enough. It's easy enough to filter this kind of crap out, but /. just don't seem to bother. Yes, I could simply browse at a higher level, but I've usually got mod points and browse at -1 as suggested for very good reasons. But if /. aren't prepared to deal with the most basic levels of spamming then I can't be bothered helping them out any more. Email address deleted, password changed to a long random string that I don't know, sig changed to indicate account has been deleted. Bye everyone, most of the last decade or so has been fun, but frankly, I quit.
Please consider this account deleted, I just can't be bothered with the spam anymore.
oh man, that incredible interminable list of responses is almost as funny as the original post. This is getting to be truly epic. If there were and admins around any more that gave a damn, expect some ham-handed attempt at anti-trolling code soon -- that'll fuck /. up ever further for everybody else.
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
I've implemented sites that use a variety of third party authentication schemes. Its a nuisance for users (multiplicity of accounts, more insecure passwords to remember etc) and a nuisance for developers. Why are we still doing this? Authentication (and user profiles for that matter) belong in the user's browser. I'm not talking about Chrome's password wallet. I'm talking about a certificate-based system that allows the user to control from their end which sites are authenticated, and what data they should have access to. Sites would then implement a simple API (possibly combined with meta data on the front end to let the browser know details) that would allow for login, signing up, or changing particulars. The process could be made completely transparent for users. I have this partially implemented as an insecure proof of concept browser plugin. It wouldn't take too much work to get it running, although it really should be core browser functionality instead.
I would call this neither "fresh" nor "objective".
The author rehashes some well known issues with the OAuth protocol - I assume OAuth 2.0, though he really should make the distinction explicit, makes some contradictory complaints - "Waah, it's too flexible! Waah, it's not flexible enough!", and recommends some simpler "solutions" that conveniently don't address the problems he raises at all.
OAuth 2.0 does not provide a plug-and-go interoperable protocol, and many people, including the original RFC editor Eran Hammer, regard that as a failure.
On the other hand, it provides a framework you can pick-and-choose from to create a perfectly decent authorization API, and it will likely be more sound and familiar to developers than if you had just winged it and created your own.
His name is apk & he's been posting it for over 4 years. Here's one from 2009:
http://tech.slashdot.org/comments.pl?sid=1206409&cid=27661983
He keeps adding new stuff on so it keeps growing longer and longer as the years pass.
His name is apk & he's been posting it for over 4 years. Here's one from 2009:
http://tech.slashdot.org/comments.pl?sid=1206409&cid=27661983
He keeps adding new stuff on so it keeps growing longer and longer as the years pass.
A bit like a Hosts file then? I hate trolls but I do admire that level of dedication.
In a cybernetic fit of rage she pissed off to another age...
In 2013 the world still has a love affair with CHAP and assorted completely broke and useless authentication protocols. Any authentication protocol not cryptographically bound to the underlying transport is total crap yet at this very momement lots of people are hard at work inventing more useless crap.
The more fundemental problem is web doods who think they know shit about anything are the ones working on these schemes... god forbid they ever have to move outside of their comfort zone and understand something they did not invent (TLS). Instead we get layers upon layers of insecure garbage only semantically different than the garbage that came before it.
If you want external software to be able to identify you then use a goddamn client certificate .. then importing these file directly into the browser of your choice ususally takes a few seconds.
You know that old shit that has been around for decades. The only thing untrusted software vendors have to do is make sure their not vulnerable to CSRF. Getting some central authentication database to hand out pk12 files is trivial (and probably more secure than oauth)
With client certs there are no credentials for the "untrusted" entity to steal if they do this all they get is some assurance that you are who you say you are. The rest of it is unecessary scope creep. Untrusted entities interacting with other untrusted entities on your behalf is a receipe for untrusted disaster. Most of TFAs gripes are actually a failure to understand fundementals garbage in = garbage out not the fault of oauth for as crappy as oauth is.
127.0.0.0 slashdot.org
Not really but it always gets modded down to -1 so you might adjust your slashdot settings to hide -1 posts...
You have the right to remain sentient. If you give up the right to remain sentient, you will be elected to public office
Dismissing mobile apps, and non-browser based apps....
I never really understood what oAuth brought to the table that SAML 2.0 did not. I've done several SAML integrations (from the IdP side), and was impressed with the ability to build a 1 size fits all, at least on the enterprise level.
Why the rush to oAuth and not SAML 2.0?
Exchange 2013 has moved to OAuth for server to server communication, ie, to Sharepoint, Lync, etc. I'm trying to wrap my head around what this guy is saying and how that has anything to do with the OAuth that is employed by the new Office Servers Suite from MS. Because like it or loath it, most companies use Exchange nowadays.
shut up you stupid cock. Everyone knows you're wrong.
Do you think you're responding to the real apk? Or do you think you're responding to a fake apk? Or do you even care?
Some guy's rant on Blogspot is news? I guess the "stuff that matters" tagline doesn't apply anymore...
The author makes no distinction between OAuth 1.0a and OAuth 2.0. One of the spec leads did rage quit, not because of how bad OAuth is in general but because of all the "enterprise" help in version 2.0. Saying there is no standard is also dumb, yes version 2.0 can suffer from incompatible implementations but version 1.0 is pretty straight forward, the standard is right here: http://tools.ietf.org/html/rfc5849. The suggestion that we should just stick to HTTP Basic Authentication over SSL/TLS shows that the author doesn't get OAuth. The whole point it that apps shouldn't have your passwords to do what you ask them. Passwords are insecure and we shouldn't be giving them to every single application that wants them no matter how useful the app. We need delegation and permission revoking.
My Hello World is 512 bytes. But it's also a valid Fat12 boot sector, Fat12 file reader, and Pmode routine.
I brought this up with the oauth working group and got snarled at by lots of people including Eran Hammer. It's nice to see that other people are noticing the same problems. When you have a native app, you can show the user anything to get their confidence, and with some work get their credentials, including apps with webview's. OAuth's security model was not designed with native apps in mind, it was designed for ~trustable web browsers. This isn't surprising because OAuth was designed before the current fad for native apps happened around 2006-2007 when the world was all browsers all the time.
I really don't care.
-same AC
IMHO, the only legitimate points in this gentleman's post are: (1) a compromised browser defeats OAuth, and (2) OAuth isn't mobile-friendly because it requires browser interaction to gain user consent to grant access.
While both of these are true, Web browsers are ubiquitous; OAuth is a Web standard. You can abuse it slightly to make it work with mobile devices (see "access code grant") but really, it not was intended to be a be-all end-all authorization mechanism.
Likewise, claims that the protocol isn't "enterprise-friendly" are somewhat silly. OAuth was not intended for fine-grained authorization within an authentication or trust domain. It's for cross-domain (cross-application) grants, between unrelated apps, under the assumption that all three parties in the transaction are basically unrelated.
If an executive wants to delegate calendar permissions to his secretary, he should *just do it* by clicking a checkbox on Microsoft Outlook or whatever product they use for scheduling, which no doubt has its own rich permissions system and obviously has its own authentication mechanism. There's no need for a Web standard to facilitate this use case!
As for claims that "there is no standard" -- that's entirely true. There is a draft standard, which presumably will eventually be ratified by IETF once we have all had a chance to play with the technology and suggest improvements. Standards are not an item of worship; they're just a way to ensure that a protocol has had a reasonable degree of scrutiny, has no undisclosed patent encumbrances, etc. I've heard people accuse OAuth of being complex or flawed, but never fundametnally insecure.
Frankly, anyone who thinks the OAuth draft RFC is complex, should choose a dozen or so documents from the SAML protocol suite, relax in a hot bath, and read through several hundred pages of THAT claptrap. Then we can talk about complexity.
(Disclaimer: yes, I do read security standards in the bath, and I create toy implementations of security protocols and algorithms for fun. That probably makes me mentally ill.)
If people were only using OAuth for web-to-web communication, I don't think those issues would have been raised. But many of the big players have their "API"s based on it. Take a look at this thread on citrix's development site for example. Here, there's a service which is hardly web-based, pretty much the only thing web-based about it is that you join meetings by browsing to a URL, and yet the only authentication model they provide for their "API" is OAuth. This is wrong. It's not what OAuth was designed for. And yet it's what's being used. If people would stick to its intended purpose when using it, there would be no problem, but this is hardly the case.
Frankly, anyone who thinks the OAuth draft RFC is complex, should choose a dozen or so documents from the SAML protocol suite, relax in a hot bath, and read through several hundred pages of THAT claptrap.
Indeed the spec is huge, but it works extremely well. I must confess still do not understand why OAuth exists since we have SAML
hey apk, why haven't you responded to the time cube/adware guy? He issued you a challenge and so far you have been silent as far as I've seen. I want to see the epic post war with gigabytes of bold text and random links! I demand satisfaction!
The problem of storing Application Key & Secret on the device initiating the protocol is the same with OAuth1 or Oauth2. Eran Hammer rant ware not about this at all. It's an old issue that can't really be fixed today. Check this out http://arstechnica.com/security/2010/09/twitter-a-case-study-on-how-to-do-oauth-wrong/