Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)

Niv Steingarten <> Thu, 18 August 2011 18:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8061421F8AF9 for <>; Thu, 18 Aug 2011 11:07:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.574
X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id I3etkKktJzzi for <>; Thu, 18 Aug 2011 11:07:35 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D2E5A21F8AFE for <>; Thu, 18 Aug 2011 11:07:34 -0700 (PDT)
Received: by vxi29 with SMTP id 29so2391141vxi.31 for <>; Thu, 18 Aug 2011 11:08:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=95U14fOADHISdPd0I0zCB9DpCkCyAcbu9XCg/u3Aa6o=; b=v9yysKxT/KgrIG623dXSH40L3vDUxPd9re2mZhtrjPcVZ7dyu4l4wARYmNA/d2vI5L ZGrpfIGdaAHPciiOlVAvnXqOzG2N/6t4ZRJXUDTKrYRI9yBYCJv+UjGMB+9ycEU4farX 5lJEoDzE0+ZGyE9w2TsLczkI3RRnUL2UF7aDo=
Received: by with SMTP id c20mr1075674vdv.188.1313690909124; Thu, 18 Aug 2011 11:08:29 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 18 Aug 2011 11:08:09 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345029DFAA5B@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <> <90C41DD21FB7C64BB94121FBBC2E72345029DFA960@P3PW5EX1MB01.EX1.SECURESERVER.NET> <> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA22@P3PW5EX1MB01.EX1.SECURESERVER.NET> <> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA5B@P3PW5EX1MB01.EX1.SECURESERVER.NET>
From: Niv Steingarten <>
Date: Thu, 18 Aug 2011 21:08:09 +0300
Message-ID: <>
To: Eran Hammer-Lahav <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "" <>
Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
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, 18 Aug 2011 18:07:35 -0000

On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav <> wrote:
>> -----Original Message-----
>> From: Niv Steingarten []
>> Sent: Thursday, August 18, 2011 10:16 AM
>> To: Eran Hammer-Lahav
>> Cc: Torsten Lodderstedt;
>> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
>> Impersonation)
> Can you provide another example with the same level of detail as you provided below?

The malicious client sends a request to the authorization endpoint
with the appropriate parameters, and in return receives the markup of
the web-page which should be displayed to the user in order to get
consent. In addition, since the request is launched not via a
sandboxed user-agent, the client also has access to any 'Set-Cookie'
HTTP headers.

Instead of displaying the page to the user, the client extracts the
web-form data (including the hidden nonce/token) which would be
submitted when 'Allow' is clicked. It then forges the appropriate POST
request with the cookies, form data and referrer, and dispatches it,
to finally receive an access token/authorization code in the

> CAPTCHA and password entry are two completely difference measures and are rarely interchangeable. CAPTCHA does nothing more than increase the likelihood that the entity on the other side is a human. Any attack prevented by CAPTCHA must be one in which automation and speed are crucial. I still don't understand what it *solves*.

CAPTCHAs are used for human testing and passwords for identity
testing, but in this case they both serve the same purpose of
decreasing the likelihood that the flow is automated.

> Two-factor authentication is good, but completely impractical for most web authorization scenario. You need to remember that the authorization page is used for both the initial grant, but also for delegated login (by far a more frequent use). An access token can be issued almost automatically if the client has been previously authorized.

You're right, sometimes there's a trade-off between better security
and user experience. I think it should eventually be up to the
implementer to choose what is right for their applications' security
requirements. I think it is in the scope of the specification to bring
this issue up for developers to consider.

> I don't understand this "family of attacks".

I don't know how to put it any differently than I already have; simply
a class of attacks (the three scenarios described in this thread are
examples thereof) in which a malicious client takes the role of both
the client and the resource owner.

-- Niv