Various browser vendors (Apple, Google, Mozilla) have recently announced support for private access token (PAT), a new standard being developed by the IETF. Privacy Pass is designed to bring more privacy to web users and reduce data collection or the need to interrupt user experience with a CAPTCHA challenge commonly used by website owners when collected data shows anomalies for verify that the customer is legitimate and prevent bots from committing fraud.
CAPTCHA stands for ‘Completely Automated Public Turing test to tell Computers and Humans Apart’ and was one of the first methods to detect bots on the Internet. Since then, the technology has evolved and is usually coupled with a detection layer that will look for anomalies in the request and only invoke the CAPTCHA challenge when needed. With advances in detection accuracy, legitimate users are rarely prompted to complete a CAPTCHA challenge.
High level architecture
The private access token architecture consists of four key roles:
- The client, running a web browser and requesting content from an origin
- The origin, hosting content with the ability to prompt a client for a privacy token before providing access to a resource
- The mediator, a service that authenticates the client before requesting tokens from the issuer
- The issuer, applying the origin policy and issues tokens at the request of the mediator
To put this into context, web browser vendors (Mozilla, Google Chrome, Apple Safari) will act as the client. As a web security provider protecting against fraud and abuse, Arkose Labs intends to expand its product offering to become a mediator. CDN publishers (Cloudflare, Fastly) can act as issuers. website owners will assume the original role.
Instructions for use
The PAT protocol defines the interaction between the different entities; however, not all request types should be processed with PAT. Some website workflows or resources are just too critical to be authorized based solely on a masked token that cannot be tied to a specific device. For example, using a privacy token to allow users to access a product page on an e-commerce site, an article on a media site, download an advertisement, or even search for flight on the website from an airline makes perfect sense to ensure the smoothest user experience and preserve privacy. However, exchanging a token when the user tries to log in, create a new account, or change account settings is more risky. The PAT protocol is flexible and allows the website owner to define when to request a token. This hybrid approach offers the best compromise between privacy and security where fraud detection and eventual challenge will only occur on a very small part of the site.
Arkose Labs customers primarily use our product for critical endpoints, such as login and registration. Upon introduction of the Privacy Pass, Arkose Labs will continue to help detect fraudulent activity when the user begins their interaction with the site, but will also interact with issuers of tokens so that the customer can redeem them and access content on the originating web server. We anticipate that privacy tokens will be used primarily to manage content and ad fraud use cases.
The workflow with Arkose Labs
The diagram below represents the interaction between the client, Arkose Labs, and the origin web server:
- The client makes an origin request for a protected resource
- If the distribution of the resource needs to be protected (product page, search query, ad, etc.), the origin will ask a client for an access token. If the request is for a critical resource (e.g. login, account creation), the origin can perform further assessment using Arkose Labs products, Arkose Detect and Arkose Protect
- Assuming the origin has asked the user for an access token, if there is one available in the local browser cache, the client will send it to the origin to redeem in exchange for the access to the resource. If no token is available, it will contact the mediator, Arkose Labs. The Arkose Detect or Arkose Protect workflow is called. During this process, we will consider many factors beyond simply solving a CAPTCHA to determine whether the request should be forwarded to the issuer.
- If no anomaly is detected with the request, the Arkose Labs server will forward the request to the sender
- The issuer will apply the origin policy and issue a token which will be returned to the mediator
- The mediator will forward the token received from the issuer to the client
- The client will store the token in its local cache and exchange it for access to the resource. Tokens will be tied to a specific client and can only be valid for the duration of the session
- The origin will verify that the token is valid and respond to the client with the requested content. The origin must keep track of the tokens exchanged to avoid replays.
food for thought
All new protocol: The PAT protocol is brand new and various vendors are implementing specific roles. It’s great to see early adopters, but it can take a while for the implementation to mature. Attackers are experts in finding and exploiting vulnerabilities in new products, which can increase the number of security incidents until the technology has reached a certain level of maturity.
Website owners will need to keep the state as the origin: Some logic is required at the origin to keep track of the swapped token. They have in the past relied on their web security vendors to manage this logic which can be complex to synchronize in the case of a distributed infrastructure.
False positives at the mediator level would have a multiplier effect: Let’s face it, despite industry efforts, it is very difficult to achieve 100% accuracy in detection, simply because threat vectors tend to evolve faster than defense. If for a session a client receives 10 tokens (thereby reducing the cost of the attack by a factor of 10), the multiplier effect could cause significant damage to the owner of the website, which is why we recommend not to use PAT for critical points.
The PAT protocol only includes basic security: The protocol suggests using rate limiting, binding the token to the IP subnet, and limiting the validity of the token to detect abuse. These are unfortunately known security measures that attackers learned to circumvent years ago and may not be sufficient to prevent abuse with tokens, which is why advanced web security products need to collect a variety of data to Accurately assess traffic.
Arkose Labs is fully committed to supporting Internet user privacy and the IETF PAT protocol provides a framework to achieve this goal. Our support for these features will be designed to ensure that adversaries do not gain an unequal cost advantage, and the feature would be opt-in for our customers. Expect more announcements from Arkose Labs to come on this topic.
*** This is a syndicated blog from Arkose Labs’ Security Bloggers Network written by David Senecal. Read the original post at: https://www.arkoselabs.com/blog/privacy-access-token/