
今天我们隆重推出 Private Attestation Token(PAT),这是一种完全无形和隐私的方式,用于验证访问网站的是真实的用户。如果访问者使用支持这些工具的操作系统,包括即将发布的 macOS 和 iOS 版本,现在能够证明他/她们是人类,而无需填写验证码(CAPTCHA )或提供个人信息。对这些用户而言,验证码将几乎完全消失。
这对您有何意义?
如果您是互联网用户:
- 我们将使您的移动 Web 体验比其他网络更愉快、更私密。
- 在受支持的 iOs 或 Mac 设备(其他设备即将提供支持!)访问 Cloudflare 网络时,您不会看到验证码。
如果您是 Web 或应用程序开发人员:
- 知道您的用户来自真实的设备和已签名的应用,由设备提供商直接验证。
- 无需维护繁琐的 SDK 即可验证用户。
如果您是 Cloudflare 客户:
- 您什么都不用做!Cloudflare 将自动请求并使用 Private Attestation Token。
- 您的访问者不会看到验证码,我们将从他/她们的设备要求提供更少数据。
隆重推出 Private Attestation Token
过去一年来,Cloudflare 与 Apple、Google 等行业领军企业合作扩大了 Privacy Pass 协议,以支持一种新的加密令牌。这些令牌为开发人员和安全团队简化了应用程序安全性,淘汰了传统上基于第三方 SDK、用于确定使用设备者为人类的方法。它们适用于浏览器、浏览器调用的 API 以及应用内部调用的 API。我们将这些新的令牌称为 Private Attestation Token (PAT)。今天上午,Apple 公司宣 PAT 将被集成到 iOS 16、iPad 16 和 macOS 13 中,我们期待在不久的将来会有更多的供应商宣布支持这些令牌。
Cloudflare 已将 PAT 集成到自己的 Managed Challenge 平台中,使用这一功能的任何客户都会利用这种新技术,改善受支持设备的浏览体验。

验证码在移动环境中无法工作,PAT 淘汰了验证码
我们已经多次写到,验证码是一种非常糟糕的用户体验。然而,我们并没有专门讨论过,在移动设备上的体验如何变得更加糟糕。验证码是为基于浏览器的环境构建和优化的技术,并通过小部件或千篇一律的内联框架部署,导致渲染问题,或输入窗口在设备上无法完整显示。移动设备的屏幕较小,使这种技术更难使用,解决验证码更加困难。同时,渲染 JavaScript 和图像文件减慢图像加载速度,并消耗过多的客户带宽。

除了可用性外,移动环境也带来另一个挑战,因其越来越多地由 API 驱动。在 JavaScript 无法渲染或 WebView 无法调用的 API 环境中,验证码不能工作。因此,在需要质询用户的时候,移动应用开发人员往往没有一个简单的选项。他们有时会使用笨拙的 SDK 来将验证码直接嵌入到应用中。这样做需要嵌入和定制验证码,持续维护和监控,导致更高的放弃率。出于这些原因,当我们的客户今天选择显示验证码的时候,仅 20% 的时间在移动设备上显示。
我们最近发文介绍了如何使用我们的 Managed Challenge 平台来将验证码使用减少了 91%。但由于移动设备上的验证码体验要差得多,我们一直另外研究如何进一步削减移动设备上的验证码使用。
当站点不能质询访问者时,就会收集更多数据
因此,您要么不能使用验证码来保护 API,要么用户体验太糟糕,以至于无法在移动设备上使用。还有什么选项可以用来确认访问者是真实的呢?一个常见的方法是查看特定于客户端的数据,这通常称为指纹识别。
您可以要求提供设备 IMEI 和安全补丁版本,查看屏幕大小或字体,检查是否存在指示人类行为的 API(如交互式触摸屏事件),并将其与所声称的客户端的预期结果进行比较。然而,收集以上所有数据成本都很高,而且归根到底也不尊重最终用户。作为一家非常关心隐私并帮助改善互联网的公司,我们希望在不影响我们所提供服务的安全性的前提下,尽可能少地使用数据。
另一种选择是使用提供设备验证检查的系统级 API。其中包括 Apple 平台上的DeviceCheck 和 Android 上的 SafetyNet。应用程序服务可将这些客户端 API 与其自己的服务一起使用,以确定正在与其通信的客户端是有效的设备。然而,采用这些 API 要求同时更改应用程序和服务器,而且维护难度不亚于 SDK。
Private Access Token(私有访问令牌)不使用指纹识别方法来进行验证,从而显著加强了隐私保护
这是 PAT 最强大的一面。通过与第三方合作(例如设备制造商,它们已经拥有能帮助我们验证某个设备的数据),我们将能抽象出验证过程的部分并确认数据,而不用实际收集、接触或存储数据。我们并不直接质询设备,而是要求设备提供商为我们这样做。
在传统网站设置中,使用最常见的验证码提供者:
- 您访问的网站知道 URL、您的 IP 和一些额外的用户代理数据。
- 验证码提供者知道您访问的网站、您的 IP、您的设备信息,收集页面上的交互数据,并将这些数据与 Google 看到过你的其他网站联系起来。这将为您建立一个档案,包括两个网站和设备上的所有浏览活动,以及您个人与某个页面进行的互动。

在使用 PAT 时,设备数据是隔离的,并明确地不在相关方(制造商和 Cloudflare)之间进行交换。
- 网站只知道您的 URL 和 IP,这是建立连接所必须知道的信息。
- 设备制造商(验证者)仅知道验证您的设备所需的数据,但不会得知您访问什么网站,也不知道您的 IP。
- Cloudflare 知道您访问的网站,但不知道您的任何设备或互动信息。

我们实际上不需要也不想要为此过程收集的数据,我们只想验证访问者是否伪造其设备或用户代理。Private Attestation Token 允许我们直接获取验证状态,而不需要任何底层数据。这允许我们对重要信号的真实性更有信心,而不需要我们自己直接查看这些信号。
Private Access Token 如何分隔数据
通过使用 Private Access Token,四方同意在一个共同的框架内工作,以生成和交换匿名、不可伪造的令牌。如果没有这四方的参与,PAT 将无法工作。
- 源。一个从客户端接受请求的的网站、应用或 API。当网站接收到发送到其源的请求时,该源必须知道从发出请求的客户端寻找和请求令牌。对 Cloudflare 客户而言,Cloudflare 充当源(代表客户)并处理令牌的请求和处理。
- 客户端。访问者用于访问源的任何工具,通常是 Web 浏览器或移动应用。在我们的示例中,客户端是一个移动版 Safari 浏览器。
- 验证者。验证者是客户端要求在颁发令牌之前证明某些内容(即移动设备具有有效的IMEI)的一方。在下面的示例中,验证者是设备提供商 Apple。
- 发行者。发行者是这个流程中唯一实际生成或发行令牌的一方。证明者对源选择信任的发行者进行 API 调用,指示发行者生成一个令牌。在我们的案例中,Cloudflare 也将是发行者。

在如下示例中,一个访问者打开其 iPhone 上的 Safari 浏览器并尝试访问 example.com。
- 由于 Example 使用 Cloudflare 托管它的源,Cloudflare 将要求浏览器提供令牌。
- Safari 支持 PAT,因此它将向 Apple 的证明者进行 API 调用,要求后者提供证明。
- Apple 证明者将检查各种设备组件,确认它们是有效的,然后向 Cloudflare 发行者进行 API 调用(因为作为源的 Cloudflare 选择使用 Cloudflare发行者)。
- Cloudflare 发行者生成一个令牌,将其发送给浏览器,后者将其发送到源。
- Cloudflare 接收到令牌,使用它确定我们不需要向这个用户显示验证码。
这听起来可能有点复杂,但最妙的一点是,在这个过程中,网站没有采取任何行动。请求令牌、验证、令牌生成、传递,所有这些都是由用户和网站都不可见的第三方在幕后完成的。Apple 和 Cloudflare 合作提高了这一请求的安全性,减少了来回传递的数据,并消除用户看到验证码的必要性。我们通过收集和交换比过去更少的用户数据来做到这一点。
大多客户不需要做任何事情,就可以使用 Private Access Token。
要利用 PAT,您要做的就是在 Firewall 规则中选择 Managed Challenge 而非 Legacy CAPTCHA 作为响应选项。超过 65% 的 Cloudflare 客户已经在这样做。我们的 Managed Challenge 平台将自动要求每个请求提供令牌,如果客户端兼容 Private Access Token,我们就会收到一个令牌。如果您的访问者使用 iOS 或 macOS 设备,只要他们升级了操作系统,就会自动看到更少的验证码。
对我们来说,这只是第一步。我们正在积极努力使其他客户端和设备制造商也能利用 PAT 框架。只要一个新的客户端开始使用 PAT 框架,从该客户端到您的网站的所有流量将自动开始要求提供令牌,您的访问者将自动看到更少的验证码。
我们很快就会将 PAT 集成到其他安全产品中。敬请关注近期公告。