Re: [OAUTH-WG] problem statement

Michael Thomas <mike@mtcc.com> Tue, 06 September 2011 20:08 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 5022721F8E1A for <oauth@ietfa.amsl.com>; Tue, 6 Sep 2011 13:08:41 -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=[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 mOVAtGgYauWd for <oauth@ietfa.amsl.com>; Tue, 6 Sep 2011 13:08:40 -0700 (PDT)
Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 69C5A21F8E17 for <oauth@ietf.org>; Tue, 6 Sep 2011 13:08:40 -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 p86KAQcp005614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 13:10:27 -0700
Message-ID: <4E667E2E.7090304@mtcc.com>
Date: Tue, 06 Sep 2011 13:10:22 -0700
From: Michael Thomas <mike@mtcc.com>
User-Agent: Thunderbird 2.0.0.14 (X11/20080501)
MIME-Version: 1.0
To: John Kemp <john@jkemp.net>
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> <4E666E73.3050502@mtcc.com> <CAMrm-MJHKTxaj1iEm_Lr=X92sOiWZcYN4F6dNqb5w5gh4OPndQ@mail.gmail.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net>
In-Reply-To: <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net>
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=4448; t=1315339827; x=1316203827; 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:=20John=20Kemp=20<john@jkemp.net> |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=JfDSc5amkTXXNWwHWoTeHhJXXWN1ApfKErpUhFPpgbQ=; b=iTk8RLgd60KJP0HtZNsoOCltoZcUCuSA3/2ntIi4R41yRIdIo17MDKcf8n wjcUtSiMy/k4zorI3+hAlckmYmms5f2A7/eTl2yli+u5At9k0aWoPYVgcpPt 8Df5E/ecciQIxJV8yxKNjgZgCxAIVQH6vdEWai7m78amHNdTSuqg4=;
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 WG <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 20:08:41 -0000

John Kemp wrote:
> On Sep 6, 2011, at 3:49 PM, Michael Thomas wrote:
>> Except in the desktop web world, I choose from a *tiny* set of browsers:
>> chrome, firefox, opera, and, uh, ie. To a lesser or greater extent, I don't
>> expect that the browsers themselves are malicious. Which is a pretty ok
>> assumption.
> 
> It is? I would certainly question it. The WebKit WebView is embeddable in the C/C++ programming languages and APIs are available for that on most platforms - all are open to the same attacks you mention. How about the plugins you get for your browser from various places - they could have key loggers too. It's also possible for an app delivered from a server to present a login form that looks like it is from Twitter, but is actually from an attacker site. Such attacks are very common indeed, and don't require a key logger. They do require the user to "trust" the app though, just as the user would need to trust the key logger he installed.

I didn't say they weren't embeddable elsewhere. I just gave my example. And if I don't
use plugins, the browser is relatively trustable, especially in comparison to standalone
apps -- on desktop *or* phone, etc.


>> With embedded web views, that assumption goes out the window. There are
>> 100's of thousands of apps, all of which can use webviews. I have no way
>> to know if a given app is evil or not, and *lots* of apps provide facebook
>> and twitter integration. Not because they're evil, but because that's what's
>> expected by users. So the use model of oauth in this case is *very* different
>> than the desktop use case.
> 
> I disagree. If anything, because desktop machines tend to be less 'locked-down' than mobile platforms (app stores for desktops followed app stores for mobile platforms), they are more widely open to abuse.

I can tell you from experience that Android absolutely doesn't check anything of this
sort, and it would take extremely deep voodoo for Apple to do the same: they never see
source.

So the reality is that neither are trustable.

> 
>> But I'm being told that use cases aren't the problem of oauth. I'd say that
>> there has all along been a hidden assumption that the browser was
>> a trusted entity.
> 
> The point is simply that if you can subvert the actual platform, then OAuth problems are the least of your worries (as a user).

People keep saying that to deflect criticism, but I don't buy it. Other protocols aren't
availing an attacker to user credentials to third party servers by simply snooping on the
webview key traffic in an otherwise completely normal use pattern.

Have you ever signed on to facebook in an app before?

Mike

> 
> - John
> 
>> Since it isn't always, it should be very explicit in the
>> protocol, threats, and security considerations of what could happen if it's
>> not.
>>
>> Mike, frankly this is why apps do suck but i'm not king of the world
>>
>>> -- Justin
>>> On Tue, 2011-09-06 at 15:28 -0400, Michael Thomas wrote:
>>>> Melinda Shore wrote:
>>>>> On 09/06/2011 11:11 AM, Jill Burrows wrote:
>>>>>> I repeat, it is not an OAuth problem.
>>>>> If I'm reading Mike correctly (and if I'm not it won't be the
>>>>> first time I've misunderstood him), he's not really asking for
>>>>> OAUTH to solve this particular problem but to clarify the
>>>>> documents and beef up discussions of what is and is not in
>>>>> scope.  He read the document and couldn't figure out whether
>>>>> or not this particular problem is the business of the working
>>>>> group.
>>>> I'm fairly certain that if somebody were deploying oauth for their servers
>>>> that unless the document told me that oauth doesn't provide protection
>>>> against third party snooping if it's embedded in any app, most people wouldn't
>>>> have a clue that that was a dangerous assumption.
>>>>
>>>> What this says is that oauth only works in one use case, and that only the
>>>> user can tell the difference. Given the proliferation of phone apps and
>>>> embedded webviews, it seems that the original assumptions of oauth are
>>>> no longer up to date.
>>>>
>>>> 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