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" <m...@mtcc.com> 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 <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 >> <mailto: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 >> <mailto: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 <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 >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> >> > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
