Re: [OAUTH-WG] client embedded browsers (was: I-D Action: draft-ietf-oauth-v2-threatmodel-01.txt)

Mark Mcgloin <> Thu, 15 December 2011 17:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1E9D021F8A35 for <>; Thu, 15 Dec 2011 09:32:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q3QMRf9alNyC for <>; Thu, 15 Dec 2011 09:32:48 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C767821F8A7A for <>; Thu, 15 Dec 2011 09:32:47 -0800 (PST)
Received: from /spool/local by with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for <> from <>; Thu, 15 Dec 2011 17:32:46 -0000
Received: from ([]) by ([]) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 15 Dec 2011 17:32:09 -0000
Received: from ( []) by (8.13.8/8.13.8/NCO v10.0) with ESMTP id pBFHW97p2343120 for <>; Thu, 15 Dec 2011 17:32:09 GMT
Received: from (loopback []) by (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pBFHW8hS007696 for <>; Thu, 15 Dec 2011 10:32:08 -0700
Received: from ( []) by (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id pBFHW84E007691 for <>; Thu, 15 Dec 2011 10:32:08 -0700
X-KeepSent: C81B6CF6:738D246C-80257967:005EFB87; type=4; name=$KeepSent
To: OAuth WG <>
X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010
Message-ID: <>
From: Mark Mcgloin <>
Date: Thu, 15 Dec 2011 17:32:02 +0000
X-MIMETrack: Serialize by Router on D06ML091/06/M/IBM(Release 8.5.2FP1 ZX852FP1HF12|September 28, 2011) at 15/12/2011 17:32:03
MIME-Version: 1.0
Content-type: text/plain; charset="US-ASCII"
x-cbid: 11121517-6892-0000-0000-0000007A2396
Subject: Re: [OAUTH-WG] client embedded browsers (was: I-D Action: draft-ietf-oauth-v2-threatmodel-01.txt)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 15 Dec 2011 17:32:49 -0000

Hi Michael

We reviewed the threat model document in light of the concerns you raised
(originally in a thread called "Problem Statement") and decided that we
already provided enough information on threats and countermeasures from
malicious applications.

In addition, the consensus from the Oauth WG on that email thread ("Problem
Statement") was that the issue of users installing malware or any malicious
client is not an oauth specific problem and is not something we need to
educate users on, over and above what is stated already in section 4.1.4 of
the threat model. Based on that consensus, I would consider this issue
closed and we will not be making any changes to the threat model

Mark McGloin

On Wed, 26 Oct 2011 13:17:58 , "Michael Thomas" <mike at> wrote:

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
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/

[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
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


   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
no justice to the seriousness of the threat. I realize that this strays
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
about OAUTH that will cause it to be junked, it's this threat.



Mark McGloin
Tel: +353 1 8155263
Mobile: +353 87 9932662
Security Architect, LotusLive and Cloud Business Support Systems
IBM Software Group
Building 6, IBM Technology campus, Damastown Industrial Estate, Mulhuddart,
Dublin 15

IBM International Holdings BV registered in Ireland with number 903924.
Registered office: Oldbrook House, 24-32 Pembroke Road, Ballsbridge, Dublin