iOS 16内置“机器人”能绕过所有验证码？事实没有那么简单
本文来自微信公众号：APPSO（ID：appsolution），作者：郑智文，头图来自：unsplash
就在前几天（6月20日），许多媒体报道XDA论坛发现苹果发布的iOS16系统中包含“验证码机器人”的新闻。
升级到iOS16开发者预览版后，你可以在“设置”app中的AppleID部分找到“密码与安全性”，拉到最底下，就有“自动验证”的开关。
如果你了解验证码（即CAPTCHA）的全称与作用，那么就会对这个开关有许多疑问：既然验证码是“防止机器人”的，那这个功能岂不是要让验证码形同虚设？
事实当然不是如此。这个功能不能被称为“验证码机器人”，它利用的是一种全新、开放的验证机制——私密证明令牌（PrivateAttestationToken，PAT）。
一、验证码有什么问题？
从电子邮件和BBS社区诞生以来，垃圾信息泛滥一直都是互联网上的“老大难”问题。而解决这个问题最有效的方法（几乎也是目前唯一方法），就是一种称作CAPTCHA的机制，即我们常说的“验证码”的一种（另一种用来进行实名制和信息验证的验证码，不在本文讨论范围内）。
CAPTCHA又称被作“反向图灵测试”。顾名思义，它通过一些对机器很困难、但对人类很简单的问题，来帮助网站验证用户是否是真人。
这类验证码诞生差不多20年左右，基本原理几乎没有怎么变化，变的只是让用户判断歪歪扭扭的色块，变成在一堆图片中找出对应的物体。只不过只要是有过一定网络阅历的人，一定有过在十万火急的时候被“找出喷气式飞机的图片”的要求搞得特别想砸电脑手机的时刻，体验算不上良好。
目前，也有另一种区分人和机器的方法，即通过读取尽可能多的用户访问痕迹，用AI模型判断用户的行为是否是一个正常人。Google推出的noCAPTCHA服务就是使用这种方式来判断用户的真实性。
这种验证方式确实可以帮助用户尽可能绕过明显的验证过程，但同时也牺牲了隐私。毕竟，为了证明“我是人”，我需要把我的上网痕迹全部都告诉Google或者其他大公司，想想都有点不对劲。
二、PAT是什么？它如何验证用户不是自动程序？
PAT并不指代某一种技术或某一种服务，而是一个验证用户的协议。它需要用户、硬件设备厂商和验证码服务提供商三方共同参与，才能完成验证过程。
整个协议流程是这样的：
网站接入支持PAT的验证码服务；
用户向网站发起请求，网站要求用户前往验证码服务进行验证；
验证码服务向硬件制造商发起验证请求；（帮我看看这台机器有没有被破解？）
硬件制造商检查用户所持硬件编号等，并通过类似DeviceCheck或SafetyNet等技术框架检查用户设备的完整性；
确认用户硬件未被破解（越狱或root）之后，硬件制造商要求验证码服务向用户发放证明；
用户将证明随后续请求发送给网站，网站将证明拿给验证码服务进行验证；
验证通过，请求正常处理。
看起来很复杂，但整个流程的重点有两个：一是整个验证流程没有任何需要人工介入的验证过程（输入字符或点击图片等）；二是证明“我是人”的方式也从答题、隐私让渡，变成更合理的检查设备是否被破解等信息。
因为PAT验证的重点，从“你是不是人”改为“你的设备是否被篡改而有滥用嫌疑”，自然也不需要用户输入复杂的验证码，也不再需要持续追踪用户的行为进行判断。
三、是不是真的可以和“验证码”说拜拜了？
还不一定——至少在未来几年里，我们还是得和验证码“斗智斗勇”。
首先，技术推广需要一定时间。即使PAT是由IETF、苹果、Google和Cloudflare这样的大机构共同起草、推出的验证协议与标准，但目前只有iOS16和Cloudflare（防止网站被攻击的云服务商）支持这个验证协议（注：开发者和在线服务目前可以在Cloudflare和Fastly接入测试版PAT验证）。
无论是终端用户的软硬件更新，还是验证码服务与各大网站与服务跟进，都需要一定的时间。
其次，由于中国大陆Android系统生态的特殊情况，Android机型并不能直接通过GooglePlay服务中内嵌的SafetyNet框架来完成验证。也就是说，每家Android系统厂商都要单独接入PAT协议，才能为自家产品添加PAT支持。
另外，在桌面设备领域，还有许多DIY组装机的存在。由于此类设备无法找到可供担保的PAT验证人（设备制造商），因此也很有可能无法真正享受到PAT带来的便利。
不过，对于大多数人而言，PAT确实是一种能够兼顾体验和隐私的验证协议。我们期待国内的Android厂商和在线服务可以尽快跟进协议，让普通人也可以享受更好的互联网体验。
本文来自微信公众号：APPSO（ID：appsolution），作者：郑智文