It is good to see that someone understands the bigger picture here.
This conversation suffers from a presumption of a specific use-case
(web application communicating with Twitter), and a particular
presumption of trust, or lack thereof. The particular comments such as:
> You can lead a horse to water ...
> This is not rocket science.
pretty much demonstrate a very narrow contextual view, in which their
view might make sense, but outside of which it does not. Restated,
this is optimistic thinking from the perspective of their particular
use case, and ignores the perspective of either other use cases, and
overlooks someone trying to exploit a security vulnerability. To my
knowledge, and certainly in this conversation, OAuth is being touted
as an across-the-board superior security approach for ALL use cases.
Having spent the better part of the last two and half years doing
secure data storage development far more complex than that of just
authorization, but also securing the payloads across an entire cloud
and desktops, and the network as a whole, my comments here are simply
to see the claim of OAuth being undisputably superior supported with
fact against legitimate breach points. I'll give an example.
My personal development use case for security is communicating with
Twitter from an iPhone app. Applying the same broad brush "you
wouldn't give your data to a complete stranger" comments to the
iPhone, your "complete stranger" here is the iPhone app you are using.
So effectively, your "complete stranger" assertion maps to the
1) You've downloaded an app from the App Store with the intention of
using it for communicating with Twitter, yet it is considered a
"complete stranger", and untrusted.
2) You use the app, and explicitly initiate communication to Twitter
within this very "complete stranger".
This "complete stranger" assertion is absurd. First, you haven't
treated the iPhone app like a "complete stranger". You explicitly
downloaded (and likely paid money) to explicitly put this application
on your phone. Furthermore, it doesn't really matter if you pull up
the OAuth login page within your iPhone app. That "complete stranger"
iPhone app could capture keyboard events and/or filter EVERYTHING you
send across the wire prior to any encryption being applied.
Furthermore, even if OAuth itself isn't breached, as soon as your
token is acquired, what's to prevent the app from then going
absolutely haywire with your account, posting malicious status,
following / blocking who it chooses, etc.?
Furthermore, all of the "other apps" comments don't directly apply --
every app on the iPhone is sandboxed, which protects it from any other
app tampering or accessing data. The only breach of this, of course,
is jailbreaking, but then again this is analogous to someone hacking
and "owning" the desktop you are browsing on, in which case OAuth is
no protection again.
The variance for desktop apps is that they aren't sandboxed away from
other apps on the machine, but other than that, most of this all
applies to that environment too.
Unless other information surfaces, Christopher, best I can tell, you
are spot on. OAuth seems particularly relevant to web applications,
and relevant to desktop and iPhone apps primarily if your desktop /
iPhone are NOT password protected, and the application in question has
stored credentials, and you either lose or have stolen your desktop /
In conclusion, addressing one last example of ATM cards and pins --
you picked the safe example. A credit card is far less safe than all
of this, because lose one of those, and the finder is on a shopping
spree, no ID or pin required. And I'd bet 99% of this mailing list,
including the OAuth devotees, carry a credit card, and don't think
twice about the fact that they are one hole in their pocket away from
receiving a truckload of Shamwow's delivered to their house.
On Jul 31, 2009, at 7:41 AM, Christopher St John wrote:
On Thu, Jul 30, 2009 at 6:07 PM, Bradley S.
I really want to hear stated, or read on a FAQ, is the pre-requisite
security trust, that in that scenario, it necessarily makes OAuth
superior to basic authentication.
The problem here is that you're paying attention, instead
of just accepting "oauth is better because it is!" statements :-)
For desktop apps (and in any case where the application has
has control of the UI and/or your computer) OAuth has no
security advantage (since the app can snoop the interaction)
I'm sure bad people are working on a way to make this true
in browser apps as well, but I don't know of any examples.
For web applications, many commentators acknowledge an
increased risk of phishing as a potential problem with OAuth,
although I haven't personally read any studies that indicate
whether it's a theoretical or practical problem at this point.
In any case, the primary benefit in OAuth is not protecting
the user immediately from an evil application (since the
authorization tokens an OAuth server hand out are just as
powerful as passwords and must be protected like passwords)
- the owners of the service can (in theory) administratively
ban an application without forcing all the users to change
their passwords (a potentially very big benefit, maybe the
single benefit that justifies the general inconvenience)
- an individual user can ban an application by revoking its
authz token without having to change their password (a
moderate-at-best benefit, since you could always just
change your password)
- an individual who is using exactly the same password
at many sites doesn't have to expose out their mono-password
to an app (people mention this a lot, but come on, should
security system try to make people feel better about hitting
themselves on the head with a hammer? but this gets
mentioned a lot, so there you go)
So, the security picture is actually a little fuzzy. There are
some big wins for service administrators, some real (but
medium-sized?) wins for users, some fundamental limits
of applicability (web-apps only) and some open questions
about phishing and snooping. And lots and lots of hype :-)
Christopher St. John