安全服务商Cloudflare撰文解释为什么要把reCAPTCHA换成图形验证码

导读：2020年4月，安全服务商Cloudflare决定将reCAPTCHA切换为图形验证码。由于切换，可能会对其用户带来一些影响，于是Cloudflare在其官方博客上撰文解释了当时为什么会选择reCAPTCHA、现在放弃的原因，以及为什么最终选择了图形验证码。

《Moving from reCAPTCHA to hCaptcha》作者是Matthew Prince和Sergi Isasi，以下是该篇文章的编译内容：

我们最近将验证码提供商从Google的reCAPTCHA迁移到了独立的图形验证码服务。我们惊喜于这次改变，它帮助我们解决了一直以来因使用Google服务而产生的隐私问题，并且使我们能更灵活地定制所展示的验证码，如下图所示。

因为这次迁移可能对Cloudflare的用户产生影响，所以我们打算对其基本原理作进一步解释。

Cloudflare提供的服务之一是阻止恶意自动化（机器人）流量，我们也使用了一系列技术来解决这个问题。当我们认为某些流量是恶意机器人活动时，我们会完全阻止它。当我们确信其是非恶意的人为流量，或者善意机器人比如搜索引擎爬虫，我们会让它通过。但是当我们不能百分百确定它是否是恶意时，我们就需要给它一个“测试”。

我们有不同类型的测试，有些是完全自动的，而有一个则需要人为干预，这个测试就是CAPTCHAs（验证码）。它是Completely Automated Public Turing Test to Tell Computers and Humans Apart（完全自动化的公共图灵测试）的首字母缩写（CAPTCHAs省略了一些T，不然得写成CAPTTTCHA）。即按提示在方框输入歪歪扭扭的字母、识别交通灯信号或者人行横道。总的来说，它们应该是人类容易做，但是对于机器来说较难的事情。

从早期开始，Cloudflare已经在使用Google的reCAPTCHA服务了。最开始ReCAPTCHA是卡耐基梅隆大学2007年的一个研究项目，Google在2009年收购了这个项目，与此同时Cloudflare第一次启动。Google在收购该项目之后将其作为免费服务提供给客户，从而换取数据来训练它的视觉识别系统。当我们为Cloudflare寻找验证码服务时，我们选择reCAPTCHA是考虑到，它不但有效可扩展，而且更重要的一点是它完全免费——这点很重要，因为很多Cloudflare用户使用我们的免费服务。

隐私和屏蔽问题

从那时候起，一些客户已经表示担心使用Google验证码服务产生的隐私问题。Google的业务会给客户投放广告，而Cloudflare不会，我们有严格的隐私承诺。我们能够适应reCAPTCHA服务的隐私政策，但同时也能够理解一些客户由于向Google传输大量数据而产生的担忧。

我们在一些地区也面临着问题，比如在某些国家Google服务时常被屏蔽，而这些国家有相当人数的网民，因此我们一直担心的问题是，其中的一部分网民如果触发了验证码可能会导致无法访问Cloudflare服务的网站。

多年以来，隐私和屏蔽问题足以让我们考虑迁移reCAPTCHA服务。但是同大部分科技公司一样，不同于产品的新特性和新功能，优先迁移客户常用功能是比较困难的。

Google正在改变商业模式

今年早些时候，Google通知我们，他们将开始对reCAPTCHA服务收费。这完全在他们的权利范围之内。考虑到我们的体量，Cloudflare无疑对reCAPTCHA服务施加了即使对Google来说也相当巨大的成本压力。

因此这对于Google来说是完全合理的。如果图像分类训练的价值没有超过成本，Google要求对他们提供的服务付费是说得通的。在这种情况下，仅仅为了免费用户而继续使用reCAPTCHA服务，我们每年就会增加数百万美元的成本，这就是我们寻找替代方案的动力。

我们为什么要选择图形验证码？

我们评估了许多验证码供应商，并建立了自己的评价系统。最终，我们选择图形验证码作为reCAPTCHA 的最佳替代方案。

为什么要选择图形验证码？主要是因为它有许多让我们感到欣喜的地方：

1、他们不出售个人数据，只收集最低限度的必要个人资料，并且他们收集、使用或披露信息的过程是透明的，他们还同意只使用这些数据为Cloudflare提供图形验证码服务；

2、在我们的A/B测试中，图形验证码的性能(包括速度和解决率)要高于预期；

3、为视障人士和其他有使用障碍的用户提供了可靠的解决方案；

4、支持隐私通行证，以减少验证码的使用频率；

5、可以在Google被屏蔽的地区使用；

6、图形验证码团队敏捷迅速的反应，令人耳目一新。

标准的图形验证码商业模式与reCAPTCHA的启动方式相似。他们计划向需要图像分类数据的客户收费，然后向发行商付费，让他们在网站上安装验证码服务。这听起来很棒，可能对大多数发行商来说行得通，但就Cloudflare的规模而言，这并不适用。

我们与图形验证码的合作问题有两条解决途径。首先，我们正在利用我们的Workers平台来承担大部分验证码服务的技术负荷，并在此过程中降低其成本。其次，我们提议，与其他们付费给我们，不如我们来支付费用，确保他们有资源来扩大服务规模以满足我们的需求。虽然增加了一些额外的成本，但是相对于reCAPTCHA所需的服务费用来说，这只占一小部分。作为交换，我们拥有了一个更灵活的验证码服务平台和一个反应更快的团队。

我们在什么地方使用验证码服务？

当我们最初开始这个项目时就假设Cloudflare Bot（机器人）管理和防火墙规则是迄今为止最大的验证码消费者。这在某种程度上是正确的，虽然防火墙、Bot是第一客户，但是在我们验证码服务中的占比只略高于50%。

下表是根据全部验证码服务，按照Cloudflare客户服务来源统计出来的明细。

防火墙和Bot规则排第一，是Cloudflare验证码服务的主要对象。由我们客户来编写规则，规则匹配时会专门发出验证码。举个例子，如果Bot管理评分低于将该连接判定为自动连接的阈值，又高于无法判定该连接的阈值，就会触发验证码。

另一个常见规则是对全部网站，或者特定终端背后的流量发起验证码。客户这样做可能是为了限制其与访问源头的连接，或者是为了减慢某些自动化系统的执行速度。例如在登录页面上的凭据填充或损坏注册数据之类的操作，这导致Cloudflare服务的网站每天要提供数以亿计的验证码。

排第二的是我们的IP防火墙服务。和防火墙及Bot规则类似，但是在粒度上比IP、ASN（自治系统编号）和国家级别要更细，这类验证码大部分都是针对ASN或国家级别编写的规则。我们的客户可能会对某些特定的ASN存在一定程度的不信任（例如,为什么会有来自云基础设施提供商的用户流量？），或者正受到来自特定国家的攻击。

接下来是安全级别。安全级别有两个不同的案例：

1、作为IP地址信誉度评估工具；

2、“I’m Under Attack”模式。虽然我们建议客户仅在拒绝服务型攻击下使用“I’m Under Attack”模式，但仍有一些客户在所有时间内都将该特性作为网络限速和过滤的基本形式。

验证码的最后一个主要用途是全程应用到我们的自动化系统中：最近，我们的拒绝服务保护工程团队训练Gatebot使用验证码，来缓解特定场景中的流量攻击。Gatebot现在可以编写临时规则，来弹出验证码防御攻击者。

最后，也有一些客户选择它作为网络限速和托管WAF规则集的自保护系统。

点击免费试用网易易盾行为式验证码安全服务。