Re: [OAUTH-WG] problem statement

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. 

EHL

On Sep 6, 2011, at 11:10, "Igor Faynberg" <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
>> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth