Bearer Tokens Considered Harmful - Revision history

Tom: /* Problems */

2020-08-26T20:42:30Z

‎Problems

Tom: /* Solution */

2020-08-26T20:41:32Z

‎Solution

Tom: /* Solution */

2019-04-13T02:13:28Z

‎Solution

Tom: /* Introduction */

2018-11-14T00:28:09Z

‎Introduction

Tom: /* Problems */

2018-11-14T00:27:18Z

‎Problems

Tom: /* Problems */

2018-11-14T00:26:36Z

‎Problems

Tom: /* Problems */

2018-11-14T00:25:45Z

‎Problems

Tom at 21:43, 13 November 2018

2018-11-13T21:43:02Z

Tom: /* Introduction */

2018-10-31T19:07:27Z

‎Introduction

Tom: /* Solution */

2018-10-31T18:52:27Z

‎Solution

@@ Line 23: / Line 23: @@
 Now we have a large number of people using OAuth 2.0, but increasing evidence that not only can Facebook not get it right,<ref>Thomas Brewster, ''How Facebook Was Hacked And Why It's A Disaster For Internet Security.'' (2018-09-28)Forbes https://www.forbes.com/sites/thomasbrewster/2018/09/29/how-facebook-was-hacked-and-why-its-a-disaster-for-internet-security/#5a64b0b82033</ref><ref>Issie Lapowsky, ''The Facebook Hack Exposes an Internet-Wide Failure.'' (2018-10-02) Wired https://www.wired.com/story/facebook-hack-single-sign-on-data-exposed/?CNDID=45183233&mbid=nl_100218_daily_list1_p4</ref> but the UK Open Banking community is not convinced that bearer tokens are acceptable for payment protocols. Note that Facebook acknowledged that they "cannot fix this" as early as 2014<ref>Wang Wei, ''Hacking Facebook User 'Access Token' with Man-in-the-Middle Attack'' (2014-03-11)The Hacker News https://thehackernews.com/2014/03/hacking-facebook-user-access-token-with.html</ref> but they again have promised to find a solution. Does anyone still believe that it will be possible for them to do that?
-To be clear, the bearer token worked as designed; it gave the holder access to a single resource. What all the binding stuff is designed to do is assure that the access is only available to the user that was given the grant. So there are two problems here: (1) the bearer token is not bound to the user and the resource site, (2) the access granted by the token is to a resource that allows additional privilege grants beyond itself. In the case of Facebook, and many other sites that I have seen, the resource even allowed the user to impersonate other users.  In Facebook this was benignly labeled as the "View-As" feature. In European open banking proposals a payment initiator can impersonate the user to get money from their account. I don't believe that any of the OpenID or OAuth standards allows impersonation, but that doesn't stop developers from thinking that they need it and are smart enough to control it. But neither is true in practice.
+To be clear, the bearer token worked as designed; it gave the holder access to a single resource. What all the binding stuff is designed to do is assure that the access is only available to the user that was given the grant. So there are two problems here: (1) the bearer token is not bound to the user and the resource site, (2) the access granted by the token is to a resource that allows additional privilege grants beyond itself. In the case of Facebook, and many other sites that I have seen, the resource even allowed the user to impersonate other users.  In Facebook this was benignly labeled as the "View-As" feature. In European open banking proposals a payment initiator can impersonate the user to get money from their account. I don't believe that any of the OpenID or OAuth standards allows [[Impersonation]], but that doesn't stop developers from thinking that they need it and are smart enough to control it. But neither is true in practice.
 ==Solution==

@@ Line 28: / Line 28: @@
 The obvious solution is a different token type in OAuth 2.0, or perhaps even a different version of OAuth, I guess 3.0. The obvious objection will be that "everybody is using OAuth 2.0 with bearer, we have no choice." The obvious answer is "bollocks, let's do this thing right!" Besides, if so few developers are able to handle the security complexity of OAuth 2.0 as it is, then we would be better off with something new that has securely bound to the user, or perhaps to the user's device. Given the ubiquitous deployment of computers with trusted execution environment, the later should be eminently practical. Of course [[FIDO U2F]] could provide this functionality as well, so perhaps the predicted wide deployment of web authentication will provide an answer. That protocol does require a binding of the web site to the user token. While that does require a trusted user agent, we know that Android, at least, is committed to validating the source of any app that validates the site binding. Apple seems to take user issues seriously, so there is a good chance they will follow suit.
-In summary, OAuth 2.0 has wide adoption across a wide range of deployments. This success is fantastic and somehow it should be leveraged to lead us to the next level of security. I personally have no confidence in the complex binding protocols now being proposed and strongly recommend a new token design with binding as a part of the token itself, not in some separate process that a developer needs to get right for a deployment to be secure. I would also explicitly ban the use of impersonation. The opposite view is that the OAuth 2.0 standards are successful precisely because they are flexible and not too hard line on security. I suspect it is obvious that I tend to be hard line on security, which is what applications like banking require.
+In summary, OAuth 2.0 has wide adoption across a wide range of deployments. This success is fantastic and somehow it should be leveraged to lead us to the next level of security. I personally have no confidence in the complex binding protocols now being proposed and strongly recommend a new token design with binding as a part of the token itself, not in some separate process that a developer needs to get right for a deployment to be secure. I would also explicitly ban the use of [[Impersonation]]. The opposite view is that the OAuth 2.0 standards are successful precisely because they are flexible and not too hard line on security. I suspect it is obvious that I tend to be hard line on security, which is what applications like banking require.
 ==What's in a Name==

@@ Line 26: / Line 26: @@
 ==Solution==
-The obvious solution is a different token type in OAuth 2.0, or perhaps even a different version of OAuth, I guess 3.0. The obvious objection will be that "everybody is using OAuth 2.0 with bearer, we have no choice." The obvious answer is "bollocks, let's do this thing right!" Besides, if so few developers are able to handle the security complexity of OAuth 2.0 as it is, then we would be better off with something new that has securely bound to the user, or perhaps to the user's device. Given the ubiquitous deployment of computers with trusted execution environment, the later should be eminently practical. Of course FIDO U2F could provide this functionality as well, so perhaps the predicted wide deployment of web authentication will provide an answer. That protocol does require a binding of the web site to the user token. While that does require a trusted user agent, we know that Android, at least, is committed to validating the source of any app that validates the site binding. Apple seems to take user issues seriously, so there is a good chance they will follow suit.
+The obvious solution is a different token type in OAuth 2.0, or perhaps even a different version of OAuth, I guess 3.0. The obvious objection will be that "everybody is using OAuth 2.0 with bearer, we have no choice." The obvious answer is "bollocks, let's do this thing right!" Besides, if so few developers are able to handle the security complexity of OAuth 2.0 as it is, then we would be better off with something new that has securely bound to the user, or perhaps to the user's device. Given the ubiquitous deployment of computers with trusted execution environment, the later should be eminently practical. Of course [[FIDO U2F]] could provide this functionality as well, so perhaps the predicted wide deployment of web authentication will provide an answer. That protocol does require a binding of the web site to the user token. While that does require a trusted user agent, we know that Android, at least, is committed to validating the source of any app that validates the site binding. Apple seems to take user issues seriously, so there is a good chance they will follow suit.
 In summary, OAuth 2.0 has wide adoption across a wide range of deployments. This success is fantastic and somehow it should be leveraged to lead us to the next level of security. I personally have no confidence in the complex binding protocols now being proposed and strongly recommend a new token design with binding as a part of the token itself, not in some separate process that a developer needs to get right for a deployment to be secure. I would also explicitly ban the use of impersonation. The opposite view is that the OAuth 2.0 standards are successful precisely because they are flexible and not too hard line on security. I suspect it is obvious that I tend to be hard line on security, which is what applications like banking require.

@@ Line 6: / Line 6: @@
 This paper discusses the limitations of Channel Binding or other half-way measures to fix a broken security feature introduced with OAuth 2.0,<ref>D. Hardt, ''The OAuth 2.0 Authorization Framework.'' RFC 6749</ref> Bearer Tokens.<ref>M. Jones, D. Hardt, ''The OAuth 2.0 Authorization Framework: Bearer Token Usage.'' RFC 6750</ref> The conclusion is that Bearer Tokens themselves are the problem and we need to be working on finding better ways to authorize the release of resources on the web.
-'''Author: [http://tomjones.us Tom Jones]  Date: 2018-10-03 revision 2018-10-25'''
+'''Author: [http://tomjones.us Tom Jones]  Date: 2018-10-03 revision 2018-11-11'''
 ==History==

@@ Line 19: / Line 19: @@
 It was into this environment that OAuth 1.0 (using a convoluted version of shared secrets) morphed into [[OAuth 2.0]] (using public key) which was still based on one computer talking to another computer. Among the many fields that could be addressed was the HTTP header with the type of authorization used, (e.g. Authorization: Bearer mF_9.B5f-4.1JqM). Unfortunately only type "Bearer" is actually supported by any existing implementation. So, in order to expand the functionality of authorization, all modifications to date have been to hack the bearer token in some way to make it more secure. The final solution has been Token Binding<ref>A. Popov +5, Token Binding over HTTP (approved but not yet released RFC) https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/ </ref> only the first of many standards is listing in the draft RFC of 3 to 5 depending on how you count. If you have been counting this is now the hack of a hack of hack. Also known as the great grand hack. But the real problem with the latest (token binding) hack is that while the earlier hacks could be implemented at the Enterprise level by the same development team, token binding requires that all developers of internet solutions implement the hack with no security vulnerabilities. That is certainly something that has never worked in the past.
-The assumption that binding the token to the HTTPS channel will in some manner assure that only sites trusted by the user are able to access user information is flawed. The [[Identifier]] in the HTTPS channel is simply the DN in an [[X.509 certificate]]. That certificate does chain up to a root authority which is trusted by the browser manufacturer, which offers some level of [[Assurance]], but says little about the real-world [[Entity]] behind the [[Web Site]]. It is possible for the site to acquire an [[EV Cert]] which will provide some [[Assurance]] that the site is grounded in some real-world address, but none as to the trust that the user should place in that [[Entity]].
+The assumption that binding the token to the HTTPS channel will in some manner assure that only sites trusted by the user are able to access user information is flawed. The [[Identifier]] in the HTTPS channel is simply the DN in an [[X.509 Certificate]]. That certificate does chain up to a root authority which is trusted by the browser manufacturer, which offers some level of [[Assurance]], but says little about the real-world [[Entity]] behind the [[Web Site]]. It is possible for the site to acquire an [[EV Cert]] which will provide some [[Assurance]] that the site is grounded in some real-world address, but none as to the trust that the user should place in that [[Entity]].
 Now we have a large number of people using OAuth 2.0, but increasing evidence that not only can Facebook not get it right,<ref>Thomas Brewster, ''How Facebook Was Hacked And Why It's A Disaster For Internet Security.'' (2018-09-28)Forbes https://www.forbes.com/sites/thomasbrewster/2018/09/29/how-facebook-was-hacked-and-why-its-a-disaster-for-internet-security/#5a64b0b82033</ref><ref>Issie Lapowsky, ''The Facebook Hack Exposes an Internet-Wide Failure.'' (2018-10-02) Wired https://www.wired.com/story/facebook-hack-single-sign-on-data-exposed/?CNDID=45183233&mbid=nl_100218_daily_list1_p4</ref> but the UK Open Banking community is not convinced that bearer tokens are acceptable for payment protocols. Note that Facebook acknowledged that they "cannot fix this" as early as 2014<ref>Wang Wei, ''Hacking Facebook User 'Access Token' with Man-in-the-Middle Attack'' (2014-03-11)The Hacker News https://thehackernews.com/2014/03/hacking-facebook-user-access-token-with.html</ref> but they again have promised to find a solution. Does anyone still believe that it will be possible for them to do that?

← Older revision		Revision as of 21:43, 13 November 2018
Line 1:		Line 1:
−	Banned: This paper was rejected by the IDPro organization. Probably because it contains ideas that are not in complete agreement with the folks that fund the IDPro organization. It is a response to Brian Campbell of Ping Identity in their newsletter telling people why they should use Token Binding.	+	Banned: This paper was rejected by the IDPro organization. Probably because it contains ideas that are not in complete agreement with the folks that fund the IDPro organization. It is a response to Brian Campbell of Ping Identity in their newsletter telling people why they should use [[Token Binding]].

	'''This paper tells you why you should not use Token Binding.'''		'''This paper tells you why you should not use Token Binding.'''