Re: [OAUTH-WG] problem statement

[Eran Hammer-Lahav <[e-mail]>]

Framing this as an OAuth issue is wrong. In your scenario:

1. Install bad app
2. Do protocol X
3. Bad things happen

X can be anything. For example, the app can add a root cert to your os and break TLS protection. 

EHL

On Sep 6, 2011, at 11:50, "Michael Thomas" <[e-mail]> wrote:

> William Mills wrote:
>> 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.
> 
> Then what I don't see anywhere is that oauth is not applicable to embedded
> web objects, and that end users should *never* trust oauth in a, say, phone
> app. As far as I can tell, the server deploying oauth can't tell that it's
> being misused, so this is all on the shoulders of the end user.
> 
> It sure looks like oauth is easily subverted in the real world.
> 
> Mike
> 
>> 
>> ------------------------------------------------------------------------
>> *From:* Michael Thomas <[e-mail]>
>> *To:* Eran Hammer-Lahav <[e-mail]>
>> *Cc:* "[e-mail]" <[e-mail]>
>> *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" <[e-mail] 
>> <mailto:[e-mail]>> 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" 
>> <[e-mail] 
>> <mailto:[e-mail]>> 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
>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail] <mailto:[e-mail]>
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
>