Mike, Let me say this:
If I hired a developer to write an app for me for, I would expect that developer to not implement a key logger or anything that could damage my company's reputation down the line. If I reviewed the code and found something suspicious, I would terminate their contract. Generally, companies who care about their brand and reputation implement trusted applications. There are times when they may contract with people who are shady, but they will find out later once the damage is done that they needed to do more research and hire someone who could be trusted to not injure their brand. If that company's brand suffered, I would hope they sued the developer for damages to teach that shady developer a lesson. It is definitely up to people to choose what they install on their devices. If they randomly install malicious software, I'm sure that getting credentials to an OAuth enabled site is the least of what they could do. Someone could write an app for anything, like a bank and steal the users credentials for that. It doesn't matter the protocol involved if the application or website, is made to do something malicious. People who are susceptible to installing non-trusted applications might also suffer from a rootkit infestation -- in which case, their social media credentials might be the least of their worries, since all of the information on their device would be available to the writer of the rootkit. I repeat, it is not an OAuth problem. Perhaps, companies that implement OAuth servers for their service should remind developers and users what to expect with OAuth on their service. As for as I know, it is not in the scope of the OAuth specification to clearly state things which are entirely dependent on a certain services implementation of OAuth. -Jill On Tue, Sep 6, 2011 at 12:03 PM, Michael Thomas <m...@mtcc.com> wrote: > Eran Hammer-Lahav wrote: > >> Framing this as an OAuth issue is wrong. In your scenario: >> >> 1. Install bad app >> 2. Do protocol X >> 3. Bad things happen >> > > No. It's > > 1. Install app. > > Users don't know which are which. Have you ever used oauth through a phone > app? How > did you determine it wasn't evil? The yahoo guy here apparently has lots of > money > if you can tell him too. > > Mike > > > >> 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.faynberg@alcatel-lucent.**com<igor.faynb...@alcatel-lucent.com><mailto: >>>> igor.faynberg@alcatel-**lucent.com <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<https://www.ietf.org/mailman/listinfo/oauth> >>>>>>>>> >>>>>>>> ______________________________**_________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>>>>> https://www.ietf.org/mailman/**listinfo/oauth<https://www.ietf.org/mailman/listinfo/oauth> >>>>>>>> >>>>>>> ______________________________**_________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>>>> https://www.ietf.org/mailman/**listinfo/oauth<https://www.ietf.org/mailman/listinfo/oauth> >>>>>>> >>>>>> ______________________________**_________________ >>>> OAuth mailing list >>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>> https://www.ietf.org/mailman/**listinfo/oauth<https://www.ietf.org/mailman/listinfo/oauth> >>>> >>>> >>>> > ______________________________**_________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/**listinfo/oauth<https://www.ietf.org/mailman/listinfo/oauth> > -- Thanks, Jill Burrows CTO / Lead Technologist - uLynk Consultant / Technologist - Creative Sagacity +1 503 208 5455 j...@adaburrows.com http://adaburrows.com @jburrows (http://twitter.com/jburrows)
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
