以私有访问令牌取代 CAPTCHA

♪ ♪

Tommy Pauly: 大家好 我是 Tommy Pauly 很高兴能和大家分享 如何让您的 App 和网站 与 Apple 协作 以及行业内的防欺诈提供程序 从而减少对 CAPTCHAs (验证码) 的需求 今天 我将着重讲下 私有访问令牌 及其为何是防欺诈的强大工具 如何在您操作的服务中中 启动支持私有访问令牌 以及您如何在 App 中 使用这些令牌

要介绍私有访问令牌 我首先解释下 CAPTCHAs 最初的使用目的 您在网站注册新账户 或用当前账户登陆时 有可能会遇到 这样的 CAPTCHAs 有时 CAPTCHA只是 一个按钮 但其它填写形式可能会 挑战极大

您应该不喜欢被这些干扰 我是肯定不喜欢的 这些体验的存在原因 是预防欺诈活动

如果您运行一个服务器 也不希望它会充斥欺诈 有些创建账户或产品购买的操作 是来自合法用户的 到哪有些可能是攻击者或机器人 不幸的是 如果 App 或网站 使用了常用的预防欺诈工具 如 CAPTCHAs 用户会更难使用 在良好的体验感和预防欺诈之间 寻求最佳平衡点是一个挑战

CAPTCHAs 通常会带来更慢 更复杂的用户体验 在预防攻击的同时 您也可能会失去一些有价值的顾客

CAPTCHAs 同样也会 构成隐私风险 为了确认用户是否可信任 是否可用较简单的 CAPTCHA 服务器通常要跟踪或识别 用户的 IP 地址 这种跟踪是与 Safari 邮件隐私保护 以及 iCloud 隐私中继 所追求的方向是相悖的

CAPTCHAs 在可访问性方面 也有严重的问题 为了阻止机器人访问 它们也将有残疾或语言障碍的 真实人类 拒之门外 有一个更好的方法 即使有人首次访问网站 如果是通过 App 或如 Safari 的 浏览器来加载的 那其实有许多操作 已经是机器人很难模仿的了 首先 它们要有 iPhone iPad 或 Mac 并且要用密码 触控 ID 或面容 ID 来解锁设备 而且经常用 Apple ID 登陆设备 登陆了代码验证的 App

这一信息可以帮助您的服务器 无需 CAPTCHAs 无需通过跟踪用户侵犯隐私 即可信任合法用户 预防欺诈 私有访问令牌可让您的服务器 在全新的 iOS 16 和 macOS Ventura 中 自动信任用户 解释令牌的运行原理前 我先给大家演示下其实际操作 您一定会喜欢的 我想要阅读 Financial Times 网站上的一篇文章 我非常喜欢这些肉桂面包 我在两个不同的手机中 都加载了这个网站 一个是在 iOS 15 上 另一个在 支持私有访问令牌 的 iOS 16 上 首先看 iOS 15 手机 我点击“sign in” 填写我的账号和密码 然后 CAPTCHA 打了我个措手不及 阅读文章前 我还需要输入字母

而我在支持私有访问令牌的 iOS 16 手机上 做完全一样的操作时 一路绿灯 这将为人们节省许多时间 您的用户也会因被信任 而备受感激 如您刚才所见 私有访问令牌通过 使用 IETF Privacy Pass 工作组中 标准化的技术 可让服务器避免 captchas 为了让其成为可能 Apple 与行业内的 许多公司都进行了合作

使用这一协议 服务器可使用最新的 HTTP 验证方法请求令牌 即 PrivateToken 这些令牌使用的是 RSA 盲签名 以加密签署事实协议 证明用户可以通过验证检查 这些签名是“unlinkable” 意味着接收令牌的服务器 只能检查用户是否合法 但无法随着时间的流逝 得知用户的身份或识别用户 这是协议的运行案例

首先 当 iOS 或 macOS 用户 通过 HTTP 访问服务器时 服务器用 PrivateToken 验证系统 返回一个 challenge 它指定了服务器信任的 令牌发出者

用户需要提取令牌时 它联系 iCloud Attester 发送令牌请求 这一令牌请求 为“blinded” 因此不能链接到 server challenge 中 Attester 用存储在设备中的 secure enclave 进行 设备验证 确认该账户信誉良好

该 attester 也可以通过限速 识别用户设备是否正常 是否被盗用 或是否是一系列设备中之一

如果用户验证通过 attester 向发出者 发送新令牌的请求

当令牌发出者收到请求后 它对用户信息一无所知 但由于它信任 iCloud Attester 于是签署令牌

随后 用户收到签署的令牌 并通过“unblinding”的过程 进行转换 从而原始服务器能进行验证

最后 用户向服务器 展示签署的令牌 服务器确认该令牌 为发出者所签署 但无法通过令牌 来确认或识别用户 那您可以如何在服务器中 利用此项技术呢 您可以在服务器中通过 以下三步应用私有访问令牌 首先 您需要选择一个 令牌发出者 第二 当您要验证用户时 您的服务器需发送 HTTP 验证 challenges 第三 您的服务器需要验证 用户发送的令牌 您选择的令牌发出者 是受信任的提供程序 可签署您服务器验证的令牌 这可能是您当前 CAPTCHA 的 提供程序 您的虚拟主机服务 或您的 Content Delivery Network (内容发布网络) 也称之为 CDN 在试用 iOS 16 和 masOS Ventura 时 您可以先用两个令牌发出者 开始测试 Fastly 和 Cloudflare 是开发 Privacy Pass 标准的 两个 CDN 其令牌发出者现已可用 其它 CAPTCHA 提供程序 虚拟主机服务以及 CDN 可以运行与 Apple 设备有协作的 令牌发出者 发出者于今年晚些时候 登陆 register.apple.com 注册

重要的是 使用具体的令牌发出者 并不是用于识别用户当前 正在访问的网站 这会带来隐私问题 因此 每个令牌发出者需要是 与至少数百家服务器协作的 大型设备

当用户访问您的服务器时 您可以用 PrivateToken 系统 通过发送 HTTP 验证 challenge 来请求令牌 要完成这一目标 有两个选项 您可以与当前 CAPTCHA 或防欺诈提供程序合作 将 challenge 构建到脚本中 因此它能为您自动处理 或者您也可以选择直接 从您的服务器中发送 challenges

如果您网站用的是这个选择 challenge 必须 来自第一区域 您主 URL 的子域 而不是内嵌于您的网站中 独立的第三方区域

当用户向您返回令牌时 您需要用发出者的公开密钥 检查验证 您可能也会想强化检查 从而预防用户多次展示令牌的 回放式攻击 令牌只是一次性使用 您可以通过记忆之前 发送的令牌 或要求用您 challenge 中 说明的独特值来签署 从而预防回放式攻击

您的网站还需要与 无法响应这一验证 challenge 的 旧版用户进行协作 因此 重要的是 验证过程 不会干扰您的主页面加载 而是作为一个备选方式 表达对用户的信任 通过 Safari 或 WebKit 访问的 网络服务器会自动运行 但您也可以直接在 App 中 使用私有访问令牌 私有访问令牌要求 iOS 16 或 macOS Ventura 设备 都有注册 Apple ID 该 Apple ID 仅可用于 attestation 不会与收到令牌的服务器共享 在您的 App 中 如果您使用 WebKit 或 URLSession 通过 HTTP 联系您的服务器 则令牌可用 不管您的 App 何时收到 challenge 只要保持在前端 系统都会自动发送令牌作为验证

如果您使用的是 URLSession 要让私有访问令牌运行 无需进行其它细节操作 URLSession 将会自动 使用 PrivateToken HTTP 验证系统 响应 challenges 然而 如果提取令牌时出现错误 如 App 并未在前端 或设备没有注册 Apple ID 您的 App 将会收到 包含令牌 challenge 的 401 HTTP 响应 这样 您的 App 知道 令牌 challenge 已收到 并提供为您的使用场景 处理错误的机会 私有访问令牌的可用性 避免了 CAPTCHAs 让许多 App 和网站 对每个用户来说都有良好的体验感 去准备好您的服务器 以发送 令牌 challenges 和验证令牌 在您的 App 中 使用 URLSession 或 WebKit 自动支持私有访问令牌 期待看到您构建的 无需 CAPTCHA 的体验