Slashdot Mirror

← Back to Stories (view on slashdot.org)

A Truckload of OAuth Issues That Would Make Any Author Quit

Posted by Soulskill on from the tell-us-what-you-really-think dept.

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."

13 of 86 comments (clear)

  1. Re:host troll by EvanED · · Score: 2

    I think it's a complaint about (and I hesitate to link to it) this post which keeps showing up story after story.

  2. Re:Genius by GLowder · · Score: 5, Funny

    Step four: suddenly realize you posted under wrong article

    --
    I used to have a good sig...
  3. WTF was that? by antifoidulus · · Score: 2

    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
    1. Re:WTF was that? by Anonymous Coward · · Score: 4, Interesting

      I think the key point of the article is the first part, the "APUI" section. OAuth is "fine" when used for authentication by a user for a service based on a web browser. However, it is increasingly being applied at the "API" level (where services and applications interact, not users). It doesn't work _at all_ at this level.

      I agree that the enterprise level permissions bit is pushing things, but the rest of the article is spot on.

    2. Re:WTF was that? by Anonymous Coward · · Score: 3, Insightful

      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....?

      Because people are, with great gusto, actually using it for what it was never designed to do.

  4. Last Post by History's+Coming+To · · Score: 4, Funny

    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.
  5. Auth belongs in the browser by jeremylichtman · · Score: 5, Insightful

    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.

    1. Re:Auth belongs in the browser by Lennie · · Score: 2

      I don't know if he is a shill, but can you tell me what you don't like about BrowserID, that could be a lot more interresting discussion.

      --
      New things are always on the horizon
    2. Re:Auth belongs in the browser by jeremylichtman · · Score: 2

      I'm not a shill for anyone. Hmm. Maybe for myself. BrowserID uses emails for authentication. Why do we even need to have that? What if you want to change your email address? And why should websites have your email address unless you want them to do so. What I had in mind was that users can create any number of profiles for themselves on their browser, each with flexible set of fields for things like their name, and each field having privacy options. They then can register that profile on a given website; view a list of sites that are authenticated against a given profile; change privacy options for any given field/website combination without going to the site; deregister from a site etc etc. The key is that everything would happen through some kind of negotiated and secure back-channel. Advantages include heightened privacy for users, the ability to have many profiles (each of them having some kind of unique identifying certificate) that can be used globally, and the ability to be able to manage their internet identity from their own end.

  6. Re:totally secure == powered off by DeFender1031 · · Score: 3

    You miss the point. He says to have the user create separate passwords from the primary one, with restricted permissions, and give a different managed password to each application. That way, if the application misbehaves, the user themselves can remove that password without having to affect anything else.

  7. Re:host troll by Spottywot · · Score: 2

    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...
  8. Native apps == insecure by shirikodama · · Score: 2

    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.

  9. Re:totally secure == powered off by DeFender1031 · · Score: 2

    Again, you miss the point. The point isn't separate accounts. The point is, you have a user account, say "JoeCool", and a password, say "12345". Your system allows Joe, when logged in under that password, to create a secondary password, 67890 which, when logged in with, only allows limited access. Joe can then give "67890" as a password a third-party application, which will then have only limited access. If the application misbehaves, Joe can remove the "67890" password, thus locking out the malicious application while keeping his primary password secure, along with any other secondary passwords he's generated for other applications. That's the system being described and that's a system which would avoid a heck of a lot of headache.

    And I'd appreciate not being called names by someone who hasn't even taken the time to understand what's being said.