Re: [OAUTH-WG] problem statement

Michael Thomas <mike@mtcc.com> Tue, 06 September 2011 19:01 UTC

Return-Path: <mike@mtcc.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C54D21F8B46 for <oauth@ietfa.amsl.com>; Tue, 6 Sep 2011 12:01:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jocRgzoOizl8 for <oauth@ietfa.amsl.com>; Tue, 6 Sep 2011 12:01:34 -0700 (PDT)
Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 43B7C21F8661 for <oauth@ietf.org>; Tue, 6 Sep 2011 12:01:34 -0700 (PDT)
Received: from piolinux.mtcc.com (65-165-164-246.volcano.net [65.165.164.246]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id p86J3JvB014835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 12:03:20 -0700
Message-ID: <4E666E73.3050502@mtcc.com>
Date: Tue, 06 Sep 2011 12:03:15 -0700
From: Michael Thomas <mike@mtcc.com>
User-Agent: Thunderbird 2.0.0.14 (X11/20080501)
MIME-Version: 1.0
To: Eran Hammer-Lahav <eran@hueniverse.com>
References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <CD0B1909-8298-4CC3-B273-7B26E71EAB31@hueniverse.com> <4E666512.7010701@mtcc.com> <F4839FCD-CA73-4450-AD12-E07D46BB7746@hueniverse.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com>
In-Reply-To: <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6738; t=1315335801; x=1316199801; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20<mike@mtcc.com> |Subject:=20Re=3A=20[OAUTH-WG]=20problem=20statement |Sender:=20 |To:=20Eran=20Hammer-Lahav=20<eran@hueniverse.com> |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=LnHJUeQEAMRvMe7Lu26fGHt492iQy7tdg67EHEFgLMc=; b=MKtBoWuMxnP6zj/17slnS0q1o5DzMVQoVbt9zCYtJbNwS5MzWJoqlgv3m7 cnXSnILbCpFQNgAh+I6mYVYobXMz6ncr1z3kxoaMN8PZOmTLJskp+VJ1DFe3 i8jLyvnFfEyY/WJA3VSkAc7N6h3MhhMhEzCEP9doxS8U6071zvZAs=;
Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] problem statement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Sep 2011 19:01:35 -0000

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" <mike@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 <mike@mtcc.com>
>>> *To:* Eran Hammer-Lahav <eran@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" <mike@mtcc.com 
>>> <mailto:mike@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 
>>> <mailto: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 <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
>>>
>>>