IETF Logo Mail Archive

Re: [OAUTH-WG] Hashing passwords for "password" grant type

Kris Selden <kris.selden@gmail.com> Mon, 13 September 2010 07:33 UTC

Return-Path: <kris.selden@gmail.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 303DB3A693E for <oauth@core3.amsl.com>; Mon, 13 Sep 2010 00:33:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.97
X-Spam-Level:
X-Spam-Status: No, score=-0.97 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_20=-0.74, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nXPzSN0QrHq for <oauth@core3.amsl.com>; Mon, 13 Sep 2010 00:33:28 -0700 (PDT)
Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 943683A693D for <oauth@ietf.org>; Mon, 13 Sep 2010 00:33:14 -0700 (PDT)
Received: by pxi6 with SMTP id 6so2660344pxi.31 for <oauth@ietf.org>; Mon, 13 Sep 2010 00:33:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=YfmbiP4wxKN0DbUH7hb0c98NjYeTKbPjOEUg/eONRRw=; b=fJE3DmBqnzg4tnM0y+pVypDYlo4JmLufG0kLFiBop2Jab74Jp01C5uLCsppTHZa5as lIUAy6gj/Sac0iMFPJ9PfzgylRhO4zRu+V39CHcv0gbsH3lsAo+Y/A07JmoFi4z3hEpu 5Q0a4kMeMMvUjmZvWV5wGAeU8Gg6FkFTWHF/0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=Jk4gEOd65BSnD/4NQIp45d3ldPk402ZjE7VC2DRfCnQviU5yCl3/esD33fcbGNDZlY bJwvpprDqURgmmvZuepIIDM5S2TdS7FGoPRS420rn4l7lEQEluoaQvZD33VHPyHhnj6d j7yZ0YL9Q92B25Fj9N+l+d48uHajhTvqFaRAA=
Received: by 10.114.190.20 with SMTP id n20mr2689071waf.126.1284363203404; Mon, 13 Sep 2010 00:33:23 -0700 (PDT)
Received: from [172.16.2.2] (c-71-197-233-96.hsd1.wa.comcast.net [71.197.233.96]) by mx.google.com with ESMTPS id c24sm11476291wam.7.2010.09.13.00.33.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 13 Sep 2010 00:33:21 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/alternative; boundary="Apple-Mail-3--1034162321"
From: Kris Selden <kris.selden@gmail.com>
In-Reply-To: <AANLkTikuVV2av_VR6WLfF0NCTTLUxQ5uBTqAH+stp1iz@mail.gmail.com>
Date: Mon, 13 Sep 2010 00:33:19 -0700
Message-Id: <C476C5FE-D602-4580-A21B-261E92C02790@gmail.com>
References: <AANLkTi=eODzwVYyPjQXwBP-S+po7-hpP8v-YgQpjVR8S@mail.gmail.com> <4C8A46D5.9070207@aist.go.jp> <AANLkTikYTMBP1uLJ7g5ckWsoAg7n+aQ1awSq4kfvRJ+c@mail.gmail.com> <AANLkTikuVV2av_VR6WLfF0NCTTLUxQ5uBTqAH+stp1iz@mail.gmail.com>
To: Aaron Parecki <aaron@parecki.com>
X-Mailer: Apple Mail (2.1081)
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Hashing passwords for "password" grant type
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Mon, 13 Sep 2010 07:33:40 -0000

> Kris - Can you clarify why phones can't protect the client secret? This sounds like it would be a major issue for a lot of people.


Mobile apps on phones like iPhone are installed apps, and it is not possible as far as I know to prevent the client secret from being extracted – you have to rely on the user to know if the app they installed is reputable.

Static string constants can be easily extracted, but even if you tried to obfuscate the secret in the compiled code, one could extract the key out with a jail-broken phone using a debugger to capture the secret when it is passed to the API or installing a root certificate to establish a man in the middle to sniff the client secret when it is sent using https. And if you think you can use push notifications to send your app a new client secret, push notifications have been hacked too.

On an installed app, the client id is more of a user agent string, you can use it to try to clue the user into a mismatch between the app they downloaded and the app the website thinks they've downloaded when they are asked to approve.  With the password grant type, it is totally up to the user to know if they can trust the app.  By allowing that grant type in an installed app, you open up the grant type to an unsavory app with a little determination and it would be up to the user to know better not to give their credentials.

For more perspective, please read the following articles (as it relates to mobile apps, client secret, and the password grant type):
http://hueniverse.com/2010/09/all-this-twitter-oauth-security-nonsense/
http://benlog.com/articles/2010/09/02/an-unwarranted-bashing-of-twitters-oauth/
http://arstechnica.com/security/guides/2010/09/twitter-a-case-study-on-how-to-do-oauth-wrong.ars

v2.23.0 | Report a Bug | By Email