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.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
