[OAUTH-WG] Refresh tokens security enhancement
Torsten Lodderstedt <torsten@lodderstedt.net> Sun, 02 May 2010 17:49 UTC
Return-Path: <torsten@lodderstedt.net>
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 61C9F3A6AE2 for <oauth@core3.amsl.com>; Sun, 2 May 2010 10:49:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.423
X-Spam-Level:
X-Spam-Status: No, score=0.423 tagged_above=-999 required=5 tests=[AWL=-1.927, BAYES_80=2, HELO_EQ_DE=0.35]
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 gXwYpmshD0Oj for <oauth@core3.amsl.com>; Sun, 2 May 2010 10:49:28 -0700 (PDT)
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.7]) by core3.amsl.com (Postfix) with ESMTP id B149A3A6AF1 for <oauth@ietf.org>; Sun, 2 May 2010 10:48:57 -0700 (PDT)
Received: from p4fff3848.dip.t-dialin.net ([79.255.56.72] helo=[127.0.0.1]) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1O8dHV-0002Lb-MW for oauth@ietf.org; Sun, 02 May 2010 19:48:41 +0200
Message-ID: <4BDDBAF8.8060807@lodderstedt.net>
Date: Sun, 02 May 2010 19:48:40 +0200
From: Torsten Lodderstedt <torsten@lodderstedt.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Content-Type: text/plain; charset="ISO-8859-15"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Df-Sender: 141509
Subject: [OAUTH-WG] Refresh tokens security enhancement
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: Sun, 02 May 2010 17:49:29 -0000
Hi all, I discussed OAuth with some of the security experts here at Deutsche Telekom. We came up w/ an idea for enhancing refresh token handling I would like to discuss in the WG. Assumption: refresh tokens have a very long duration (month to unlimited) and are stored at the client in a persistent storage (e.g. database or filesystem) Question: How can token theft automatically be detected/prevented? Let me detail the problem using three scenarios: 1) Client is a web site Let's assume an attacker breaks into the server and gets access all tokens stored there along with the client's secret. Abuse could be prevented by changing the client secret, but this requires to _detect_ the theft first! 2) Mobile application/malware on same device Let's assume an application on a mobile device, which stores refresh token(s) in the device's file system. A malware on the same device could read the token(s) from long-term storage and send it to a server under the attackers control. One could prevent such an attack by using a client secret (probably burned into the application), but that's not a very reliable measure. Filesystem security could be used to prevent eavesdropping, but its quality varies very much among mobile operating systems. The token could be invalidated by the user, after he/she realized the theft using some user self care function. But again, the theft has to be detected. 3) Mobile application/cloning device software and configuration Someone could clone a device (operating system, configuration, applications and refresh tokens/client secrets) e.g. using a debug API when the user has left the device unattended. According to our experts, this does not take that much time and is typically not detectable afterwards. The clone could be run on another device identical in construction and could be used to access all applications on behalf of the legitimate end user. As a possible countermeasure, one could bind a refresh token to a device specific properties, e.g. the IMEI - International Mobile Station Equipment Identity. But not every device has a 3G module and access to this data might not be possible on some platforms. The impact of all attacks illustrated above strongly depends on the power associated with a token. As soon as the attacker is able to spend the end user's money or gets access to medical records it's getting serious! All countermeasures mentioned on the scenarios are either out of reach of the Oauth spec, platform specific, or not very effective. What we would like to achive is an automatic detection and at best prevention of such attacks. We came up with the following idea: The authorization server automatically creates a new refresh token with every "refresh" request (section 4) and invalidated the previous refresh token. The client must use this new token for the next "refresh" request. All attempts to obtain access tokens with an invalidated refresh token are refused. Additionally, the authorization server should hold a history of when the refresh token has been used. The client application behavior depends on who uses the refresh token first after it has been stolen. a) If the end user uses the refresh token first, the stolen token is invalidated automatically, any attempts of the attacker to obtain an access token are refused by the authorization server. b) Attacker uses the token first: The end users application attempts to obtain an access token using the (already invalidated) refresh token are refused. The client should notify the user of the problem and recomend him/her to check its application authorizations (refresh tokens) in a user self care portal. There, the user should have acces to information on when the token has been used the last time and therewith detect any odd behavior. The user could then revoke the token and/or alarm its providers helpdesk. We think the proposed change to the API would significantly contribute to the overall security level of OAuth. Thoughts? regards, Torsten.
- Re: [OAUTH-WG] Refresh tokens security enhancement Marius Scurtescu
- [OAUTH-WG] Refresh tokens security enhancement Torsten Lodderstedt
- Re: [OAUTH-WG] Refresh tokens security enhancement Allen Tom
- Re: [OAUTH-WG] Refresh tokens security enhancement Torsten Lodderstedt
- Re: [OAUTH-WG] Refresh tokens security enhancement Torsten Lodderstedt
- Re: [OAUTH-WG] Refresh tokens security enhancement Eran Hammer-Lahav
- Re: [OAUTH-WG] Refresh tokens security enhancement Torsten Lodderstedt
- Re: [OAUTH-WG] Refresh tokens security enhancement Eran Hammer-Lahav