Subject: [OAUTH-WG] Refresh tokens security enhancement

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 02 May 2010 19:48:40 +0200

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.

---

From: Allen Tom <[email-masked]>
Date: Mon, 03 May 2010 09:55:48 -0700

Hi Torsten,

Thanks for posting this idea - I think that issuing a new Refresh Token (and
invalidating the old one) on every refresh request would help detect token
theft.

HOWEVER - in practice, this mechanism could make implementations very
tricky. For example, some  applications are highly distributed, with each
instance (or component) having its own copy of the Refresh Token. Keeping
the Refresh Token in sync would not really be feasible for these types of
apps.

Invalidating the Refresh Token (and presumably also invalidating any
outstanding Access Tokens) would make sense as an option for applications
that require a high level of security. However, I do not think that
invalidating the Refresh Token on every Refresh request should be required
in the spec - it should be an implementation specific detail.

At Yahoo, we've used the Refresh Flow for all of our proprietary
authorization APIs for many years, and I know of several applications which
would break if the Refresh Token (and Access Token) were invalidated on
every refresh request. Off the top of my head, I know of server based apps,
mobile apps, and desktop apps which are composed of several components which
asynchronously and independently keep their own copies of the user's
credentials.

Thanks
Allen

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 04 May 2010 20:32:17 +0200

Hi Allen,

> the Refresh Token in sync would not really be feasible for these types of

You are right, this approach might make implementing a client more 
difficult, especially clustered web applications.
That's not the case for autonomous devices (gaming consoles, mobile 
phones e.t.c) where the application
architecture will typically be much simpler. On the other hand, these 
are exactly the clients where the current
version of the specification does not contain any countermeasure against 
token theft.

> in the spec - it should be an implementation specific detail.

It could be an optional feature of the spec (as many other features). An 
authorization server could decide
when to use it based on its policy. For example, the authorization 
server could make this decision
depend on client type (mobile vs. web application), client id, or target 
service (security level).

The definition could be as follows

  refresh_token
          OPTIONAL.  A new refresh token replacing the refresh_token 
used as input parameter.
          If set, the client must use this token for the next "refresh" 
request. The former refresh
          token has been invalidated by the authorization server.

The benefit of making it an (optional) spec feature is support by 
libraries, standard service and
applications. From my point of view, OAuth2 has the potential to become 
THE standard for
securing standard protocols like IMAP, SyncML, SIP, WebDav and many 
others. Every feature
defined by the standard is most likely supported by standard clients and 
servers. So depending
on the authorization servers policy, all of this clients could be 
secured with the proposed
countermeasure.

> asynchronously and independently keep their own copies of the user's

As I said, it could be an optional feature, which offers out of the box 
token theft prevention. Every
deployment can decide to use it or not.

The proposed change is small in terms of specification but we could 
demonstrate that OAuth is also
suited for applications with a higher level of security.

regards,
Torsten.

> Thanks
> Allen
>
>
>
>
>
>
> On 5/2/10 10:48 AM, "Torsten Lodderstedt"<[email-masked]>  wrote:
>
>

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 4 May 2010 12:44:38 -0700

On Tue, May 4, 2010 at 11:32 AM, Torsten Lodderstedt
<[email-masked]> wrote:
> It could be an optional feature of the spec (as many other features).

Torsten, can you please have a look a the "explicit request for
refresh token" thread?

Would a "refresh_token_type=single" parameter solve the above?

Marius

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 05 May 2010 21:28:16 +0200

> Would a "refresh_token_type=single" parameter solve the above?

Hi Marius,

I expected the authorization server to decide which kind of token to 
use. Your proposal makes sense as well.
So the client can act according to its security requirements. If the 
authorization server would like to enforce its
own policy, it can detect any mismatch during token issuance.

Nevertheless, support for the optional "refresh_token" response 
parameter of the "refresh" request is the prerequisite.

regards,
Torsten.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 9 May 2010 10:56:17 -0700

Draft -02 made this possible already.

I added the following text:

        The authorization server MAY issue a new refresh token in which case the client MUST NOT
        use the previous refresh token and replace it with the newly issued refresh token.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Torsten Lodderstedt
> Sent: Wednesday, May 05, 2010 12:28 PM
> To: Marius Scurtescu
> Cc: OAuth WG ([email-masked])
> Subject: Re: [OAUTH-WG] Refresh tokens security enhancement
> 
> >>> outstanding Access Tokens) would make sense as an option for
> >>> applications that require a high level of security. However, I do
> >>> not think that invalidating the Refresh Token on every Refresh
> >>> request should be required in the spec - it should be an implementation
> specific detail.
> >>>
> >>>
> I expected the authorization server to decide which kind of token to use.
> Your proposal makes sense as well.
> authorization server would like to enforce its own policy, it can detect any
> mismatch during token issuance.
> 
> Nevertheless, support for the optional "refresh_token" response parameter
> of the "refresh" request is the prerequisite.
> 
> regards,
> Torsten.
> 
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 09 May 2010 23:56:33 +0200

Hi Eran,

I cannot find this text in -02 or -03. Would you please refer my to the 
respective page/section?

regads,
Torsten.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 9 May 2010 14:59:10 -0700

The text is in -04. -02 made the refresh token available in token refresh.

EHL

> From: Torsten Lodderstedt [mailto:[email-masked]]
> Sent: Sunday, May 09, 2010 2:57 PM
> To: Eran Hammer-Lahav
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Torsten Lodderstedt
> >>>>> Invalidating the Refresh Token (and presumably also invalidating
> >>>>> any outstanding Access Tokens) would make sense as an option for
> >> authorization server would like to enforce its own policy, it can
> >> detect any mismatch during token issuance.
> >>