Eran Hammer-Lahav wrote:
You are one making the argument that no one should be installing apps.
There is no known way to stop users from installing malware and viruses
other than not letting them install anything off a whitelist. The
problem you are describing has nothing to do with OAuth, its a
fundamental problem with running untrusted code on your devices. Once
you do that, yes, OAuth can be exploited but that's true for every
authentication scheme when one side is compromised.
My point, which you seems to miss, is that the same argument can be made
against any other protocol. TLS offers your certain protections but they
are all gone if you install a bad native app – following your logic
people should not use TLS in apps either.
I haven't missed the issue. OAuth is fundamentally trying to make an assertion
that it protects you from third party snooping. Except that it doesn't in some
large use cases. As far as I can tell that's not documented anywhere. How many
oauth server-owners know that their users have this vulnerability?
I do not consider this an issue.
That's the real problem here.
Mike
EHL
From: Michael Thomas <m...@mtcc.com <mailto:m...@mtcc.com>>
Date: Tue, 6 Sep 2011 11:58:11 -0700
To: Eran Hammer-lahav <e...@hueniverse.com <mailto:e...@hueniverse.com>>
Cc: "igor.faynb...@alcatel-lucent.com
<mailto:igor.faynb...@alcatel-lucent.com>"
<igor.faynb...@alcatel-lucent.com
<mailto:igor.faynb...@alcatel-lucent.com>>, "oauth@ietf.org
<mailto:oauth@ietf.org>" <oauth@ietf.org <mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] problem statement
Eran Hammer-Lahav wrote:
I'm dismissive of this being an OAuth problem.
Which brings us back to my original problem: what is the problem
it's trying to solve?
What are the assumptions it makes? What is its applicability? None
of those are addressed
very well if at all in the drafts. I'm sure that I'm not the only
one who would be very
surprised to hear that using oauth on a phone app is a bad idea.
Put it this way: your favorite example of a photo printing service
needing access to flickr.
It's ok if you do that from a browser, but not if the photo printer
makes an app. How many users,
exactly, are going to know that they shouldn't do the second one?
I think that's an oauth problem because oauth makes it *seem* like
you're protected from
the third party, whereas if the app itself asked for your login
credentials there would
be far less confusion. So in that sense, oauth is making things
worse, not better.
Mike
EHL
On Sep 6, 2011, at 11:35, "Michael Thomas" <m...@mtcc.com
<mailto:m...@mtcc.com>> wrote:
Eran Hammer-Lahav wrote:
Don't install crap on you device or computer. OAuth is
the least of your concern if you install bad software.
If there was a solution to this we would not need an
antivirus.
How exactly does an end user know what is "crap" or not? Or
are you just dismissive of apps in
general? I don't think that apple and google are going to
close up shop because it breaks oauth's
trust model.
Mike
EHL
On Sep 6, 2011, at 11:23, "Michael Thomas"
<m...@mtcc.com <mailto:m...@mtcc.com>> wrote:
Eran Hammer-Lahav wrote:
I agree. If you are going to install a native
app, you better trust it not to do bad things.
Grabbing your password is the least interesting
thing such an app can abuse. I don't see any
need to change the v2 draft.
How, exactly, is the user supposed to protect
themselves against rogue apps?
It sounds like the solution is to tell them to never
use oauth in an app at all.
Is oauth only intended to be used on standalone
trustable web browsers? I don't recall
seeing that anywhere.
Mike
EHL
On Sep 6, 2011, at 11:10, "Igor Faynberg"
<igor.faynb...@alcatel-lucent.com
<mailto:igor.faynb...@alcatel-lucent.com>> wrote:
Mike,
You've got the problem statement right:
allowing the user to authorize
resource access to another party without
divulging user's credentials is
the objective of OAuth. You are also right
in that the attack you have
described defies the whole purpose of
OAuth. I do not think though that
it is related to OAuth per se.
To this end, the security work led by
Torsten has thoroughly analyzed
the protocol and specified protection
against multiple protocol
attacks. From what you described, it
appears to me that the attack you
mention is not related to the protocol but
rather to the user's
environment. There is no possible
protection from key loggers that a
protocol can implement. I could be mistaken;
in any case, it looks like
the problem rests with the implementation of
WebView.
If I am wrong, I would appreciate a detailed
description of what happened.
Igor
On 9/6/2011 1:40 PM, Michael Thomas wrote:
Hi all,
Barry suggested that I might subscribe
and explain what I sent him.
My basic problem is that in neither the
protocol nor the threats drafts,
I can't seem to find what problem is
actually trying to be solved with
oauth, and what assumptions you're
making about various elements.
Here's what I did. I've written an app,
and I wanted re-integrate the
ability to send tweets after they
deprecated Basic. So the app has a
webView (android, iphone...) which it
obviously completely controls.
With oauth, the webview UA will
ultimately redirect off to Twitter's
site to collect the user's credentials
and grant my app's backend an
access token (sorry if I get terminology
screwed up, i'm just coming
up to speed).
What occurs to me is that webview
affords exactly zero protection from
my client (ie, the app) from getting the
user's twitter credentials. All
I have to do is set up a keypress
handler on that webview and in a few
minutes of hacking I have a key logger. etc.
So what I can't tell is whether this is
a "problem" or not, because I
don't know what problem you're trying to
solve. If the object of oauth
isn't to keep user/server credentials
out of the hands of a third party,
then what is it trying to solve? Is
there an expectation that the
UA is trusted by the user/server? What
happens when that's not the case?
Regardless of whether I'm
misunderstanding, it would sure be nice
to have
both the problem and your assumptions
laid out, hopefully with some
prominence
so you don't get these sort of dumb
questions.
Mike
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
