Re: [OAUTH-WG] problem statement

I agree. This is like saying SSL has an issue because it doesn't stop
keyloggers.

Not an oauth issue.

sent from my android phone
On Sep 6, 2011 8:14 PM, "Eran Hammer-Lahav" <eran@hueniverse.com> 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 do not consider this an issue.
>
> EHL
>
> From: Michael Thomas <mike@mtcc.com<mailto:mike@mtcc.com>>
> Date: Tue, 6 Sep 2011 11:58:11 -0700
> To: Eran Hammer-lahav <eran@hueniverse.com<mailto:eran@hueniverse.com>>
> Cc: "igor.faynberg@alcatel-lucent.com<mailto:
igor.faynberg@alcatel-lucent.com>" <igor.faynberg@alcatel-lucent.com<mailto:
igor.faynberg@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" <mike@mtcc.com<mailto:
mike@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" <mike@mtcc.com<mailto:
mike@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.faynberg@alcatel-lucent.com<mailto:igor.faynberg@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
>
>