OAuth doesn't solve this problem, and can't. Generally the question is whether
the app appears to come from a reputable source, and nowadays whether it's
signed (in windows land) or otherwize certified by the provider.
If you manage to solve this problem in a real way I'd be interested in
investing in your company.
________________________________
From: Michael Thomas <m...@mtcc.com>
To: Eran Hammer-Lahav <e...@hueniverse.com>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Sent: Tuesday, September 6, 2011 11:34 AM
Subject: Re: [OAUTH-WG] problem statement
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> 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> 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
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
