Difference between revisions of "Bearer Token"

From MgmtWiki
Jump to: navigation, search
(→‎Context)
(→‎Problem)
(19 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
==Full Title or Meme==
 
==Full Title or Meme==
−
A data structure that passes [[Authorization]] grants to a [[Resource]] server.
+
A data structure that passes [[Anonymous]] [[Authorization]] grants to a [[Resource]] server.
  
 
==Context==
 
==Context==
 
RFC 6750 "The OAuth 2.0 Authorization Framework: Bearer Token Usage" defines the [[Bearer Token]].
 
RFC 6750 "The OAuth 2.0 Authorization Framework: Bearer Token Usage" defines the [[Bearer Token]].
 +
<blockquote>Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key).  To prevent misuse, bearer tokens need to be  protected from disclosure in storage and in transport.</blockquote>
  
 
==Problem==
 
==Problem==
−
*Original Problem: Channel Rely is an attack against an [[Authentication]] process in certain scenarios. If an attacker manages to elicit a client to connect to him, that attacker could take advantage of the authentication mechanism and use it to authenticate against a third party server on which the client has an account with identical credentials. In addition, the attacker could even authenticate against a service running on the client itself. Evan so, the attacker could never learn the user’s password.
+
*Any party in possession of a [[Bearer Token]] can use it to get access to the associated [[Resource]]s.  To prevent misuse, bearer tokens need to be  protected from disclosure in storage and in transport.
−
*Using channel binding between endpoints on protects the token between the endpoints. With the rise of off-loading secure support for IPSec and TLS (HTTPS) results in a gap in protection as the packet travels beyond the secure end point to the server that supports the business logic.
+
*[[Bearer Token]]s are valid only for as short time as possible. These tokens work like passwords, and if intercepted can be used immediately by an attacker. Therefore the OAuth2 (with bearer token) specification requires that all communication takes place over SSL - since no cryptography is built into the specification. Typically access tokens have a short validity, which can be refreshed with a "refresh token" which has longer validity but is only transferred when the initial bearer token is received by the consumer, and when a bearer token is refreshed.
−
*Token reuse: [[OAuth 2.0]] or [[OpenID Connect]] use of bearer tokens raises the risk of token theft. For years architects have been waiting for Token Binding to get ratified so there would be transparent mechanism to close this gap. If this feature gets dropped from Chrome, this enterprise use case doesn't go away and only Microsoft Browsers support the feature.
+
*Microsoft reported the replay attack against Kerberos tokens<ref>Microsoft Security Advisory 974926, ''Credential Relaying Attacks on Integrated Windows Authentication'' (2009-12-08) https://docs.microsoft.com/en-us/security-updates/securityadvisories/2009/974926</ref> and addressed the attack with [[Channel Binding]].<ref>Microsoft Directroy Services Team, ''Control Extended Protection for Authentication using Security Policy.'' https://blogs.technet.microsoft.com/askds/2009/12/10/control-extended-protection-for-authentication-using-security-policy/</ref>
 +
*Token reuse: [[OAuth 2.0]] or [[OpenID Connect]] use of bearer tokens raises the risk of token theft. For years architects have been waiting for [[Token Binding]] to get ratified so there would be transparent mechanism to close this gap. If this feature gets dropped from Chrome, this enterprise use case doesn't go away and only Microsoft Browsers support the feature.
 +
*[https://www.pingidentity.com/en/company/blog/posts/2018/token-binding-a-critical-turning-point-for-securing-identity.html?mkt_tok=eyJpIjoiWXpZeFl6WXdNVFE0T1RNMyIsInQiOiJqdmZFOU1ITUo0ZGJXbjhVUGVSOTBsempZbnR0Qmd4cTQxWE1FMkhnMDY5N2k3SE9uakszWFBWRlViOVlUTDBZWmtyMjF3ZlZyMnN4M01ONnZIdHlHdXd2Slgyc1dKNVljU2hhcGlIZU5ZUnYrZ3NQY1JWNXhIWkVzdEswVHZ6MSJ9 Sarah Squire on Token  Binding]]
 +
*[[Bearer Tokens Considered Harmful]] is a paper that discusses the limitations of [[Channel Binding]] or other half-way measures to fix a broken security measure.
  
 
==Solution==
 
==Solution==
−
*Microsoft introduced EAP
+
*Don't use [[Bearer Token]]s without an [[Identifier]] to the audience for the token as included in the spec as:  "Issue scoped bearer tokens:  Token servers SHOULD issue bearer tokens that contain an audience restriction, scoping their use to the intended relying party or set of relying parties."
 +
*Microsoft introduced EAP and [[Channel Binding]]
 +
*John Bradly created RFC on token binding which was supported by Microsoft browsers with [[Channel Binding]] but Google found [https://twitter.com/__b_c/status/1030561000724942848 reasons for token binding] not persuasive and dropped support.
 
*Protection from the secure channel endpoint to a front end server
 
*Protection from the secure channel endpoint to a front end server
  

Revision as of 21:30, 2 October 2018

Full Title or Meme

A data structure that passes Anonymous Authorization grants to a Resource server.

Context

RFC 6750 "The OAuth 2.0 Authorization Framework: Bearer Token Usage" defines the Bearer Token.

Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport.

Problem

  • Any party in possession of a Bearer Token can use it to get access to the associated Resources. To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport.
  • Bearer Tokens are valid only for as short time as possible. These tokens work like passwords, and if intercepted can be used immediately by an attacker. Therefore the OAuth2 (with bearer token) specification requires that all communication takes place over SSL - since no cryptography is built into the specification. Typically access tokens have a short validity, which can be refreshed with a "refresh token" which has longer validity but is only transferred when the initial bearer token is received by the consumer, and when a bearer token is refreshed.
  • Microsoft reported the replay attack against Kerberos tokens[1] and addressed the attack with Channel Binding.[2]
  • Token reuse: OAuth 2.0 or OpenID Connect use of bearer tokens raises the risk of token theft. For years architects have been waiting for Token Binding to get ratified so there would be transparent mechanism to close this gap. If this feature gets dropped from Chrome, this enterprise use case doesn't go away and only Microsoft Browsers support the feature.
  • Sarah Squire on Token Binding]
  • Bearer Tokens Considered Harmful is a paper that discusses the limitations of Channel Binding or other half-way measures to fix a broken security measure.

Solution

  • Don't use Bearer Tokens without an Identifier to the audience for the token as included in the spec as: "Issue scoped bearer tokens: Token servers SHOULD issue bearer tokens that contain an audience restriction, scoping their use to the intended relying party or set of relying parties."
  • Microsoft introduced EAP and Channel Binding
  • John Bradly created RFC on token binding which was supported by Microsoft browsers with Channel Binding but Google found reasons for token binding not persuasive and dropped support.
  • Protection from the secure channel endpoint to a front end server

Reference

  1. ↑ Microsoft Security Advisory 974926, Credential Relaying Attacks on Integrated Windows Authentication (2009-12-08) https://docs.microsoft.com/en-us/security-updates/securityadvisories/2009/974926
  2. ↑ Microsoft Directroy Services Team, Control Extended Protection for Authentication using Security Policy. https://blogs.technet.microsoft.com/askds/2009/12/10/control-extended-protection-for-authentication-using-security-policy/
Retrieved from "http://tcwiki.azurewebsites.net/index.php?title=Bearer_Token&oldid=3745"