[OAUTH-WG] client embedded browsers (was: I-D Action: draft-ietf-oauth-v2-threatmodel-01.txt)
Michael Thomas <mike@mtcc.com> Wed, 26 October 2011 20:18 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 B252521F85FF for <oauth@ietfa.amsl.com>; Wed, 26 Oct 2011 13:18:02 -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 ZMwo0kVEzn3J for <oauth@ietfa.amsl.com>; Wed, 26 Oct 2011 13:18:01 -0700 (PDT)
Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id C928321F85F7 for <oauth@ietf.org>; Wed, 26 Oct 2011 13:18:01 -0700 (PDT)
Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id p9QKHwHb015008 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 26 Oct 2011 13:17:59 -0700
Message-ID: <4EA86AF6.3030606@mtcc.com>
Date: Wed, 26 Oct 2011 13:17:58 -0700
From: Michael Thomas <mike@mtcc.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0
MIME-Version: 1.0
To: Torsten Lodderstedt <torsten@lodderstedt.net>
References: <20111026191133.30416.52941.idtracker@ietfa.amsl.com> <4EA85C4F.604@lodderstedt.net>
In-Reply-To: <4EA85C4F.604@lodderstedt.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=3456; t=1319660281; x=1320524281; 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:=20client=20embedded=20browsers=20(was=3A=20[OAUTH -WG]=20I-D=20Action=3A=20draft-ietf-oauth-v2-threatmodel-01. txt) |Sender:=20 |To:=20Torsten=20Lodderstedt=20<torsten@lodderstedt.net> |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=BOKCzeXhxRVTNT0L2U61D6ReNpzHFvG4R255FJJ+mBc=; b=kXRJ9SgaDM5DeaLxZ9sNujtTwJVKGdDhPB4ys7QUsEFM+MNri/cVgzaXk8 cEIkgiBJutXPP8sxA5oNdPtfaWhVWqe4hGTeCqkmzuxyi37fFRF6PO8PlJ2u 8gQTZtq58NpVv9esCw65Gqqy6qMzRRE/SMLyFIuMaLcBG8CVVP0dA=;
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
Subject: [OAUTH-WG] client embedded browsers (was: I-D Action: draft-ietf-oauth-v2-threatmodel-01.txt)
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: Wed, 26 Oct 2011 20:18:02 -0000
First, I think that this threat should be elevated to something more than a threat because it is a fundamental assumption of the protocol that the browser is trustworthy. I have heard far too many people on this list say that that's silly because it is "obvious" but it is not obvious to the uninitiated, who are the remaining 7*10^9-100 people in this world. Second, I think it's worth explicitly pointing out that this PERTAINS TO APPS too. The world has changed significantly since OAUTH was conceived, and native phone, etc apps continue to grow explosively after a long, long decline leading up to OAUTH's birth. I would venture to say that a sizable if not majority of uses of OAUTH will be in app settings. A few inline comments: 4.1.4. Threat: End-user credentials phished using compromised or embedded browser A malicious application could attempt to phish end-user passwords by misusing an embedded browser in the end-user authorization process, or by presenting its own user-interface instead of allowing trusted system browser to render the authorization user interface. By doing so, the usual visual trust mechanisms may be bypassed (e.g. TLS confirmation, web site mechanisms). By using an embedded or internal client application user interface, the client application has access to additional information it should not have access to (e.g. uid/ password). [mat] I think it's also worth mentioning either here, or in another threat that there is a further social engineering misuse/attack where an app offers/demands to keep your credentials so that you don't have to go through the authorization rigmarole. Users are already conditioned to give their credentials up to do things -- just this morning I noticed facebook asking for my email password which they promise with sugar on top to not store. It might be worth mentioning that things like CAPTCHA could be deployed to defend against that sort of attack/misuse. Impact: If the client application or the communication is compromised, the user would not be aware and all information in the authorization exchange could be captured such as username and password. Countermeasures: o Client developers and end-user can be educated to trust an external System-Browser only. [mat] I assume that this is in here just for the amusement factor because it is not a credible countermeasure. o Client applications could be validated prior publication in a application market. [mat] How would this be done in practice? o Client developers should not collect authentication information directly from users and should instead use redirects to and back from a trusted external system-browser. [mat] How would the resource/authentication server enforce such a thing? The main problem here is that the countermeasures -- if they are practical at all -- are deep and complex problems unto themselves. To just handwave them away does no justice to the seriousness of the threat. I realize that this strays more into BCP land but there isn't any B-C-P, and I'm not terribly convinced there ever will be. In that respect, I think this threat and its potential countermeasures need to be discussed in much more detail. If there is anything about OAUTH that will cause it to be junked, it's this threat. Mike
- [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-threat… internet-drafts
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-th… Torsten Lodderstedt
- [OAUTH-WG] client embedded browsers (was: I-D Act… Michael Thomas