再见了，打码平台：对抗打码平台的验证码思路腾讯云开发者社区

我们先来回顾一下，验证码的学名是啥？

图灵测试。

图灵测试的目的是为了区分人与机器，而打码平台的加入使得这个过程立即无效——打码平台上活跃的对象还真是人。

但这样就没辙了么？

No。这“人”与“人”之间是有差别的。我们仔细想想，我们加入验证码的目的其实除了图灵测试之外还有一个重要的潜在期望——我需要知道你的确是你。

我们看看过去的验证码都有什么类型：

1、字符型验证码

这个太简单了，不再举例。

顺便吐槽一下，就算是个简单的字符型验证码，很多人却设计的像狗屎，这其中包括了一些安全公司或具有安全属性的产品。基本的字符黏连、形变都没有，光用夸张的混淆色、噪点，一个二值化就如同裸体相亲一样让人一见长短，实在垃圾。

2、短信验证码

这种类型的验证码分为两种（用户主动发送和用户被动接收），通常用在多因素认证中。

被动接受型的验证码对于验证码发起方（服务器）来说成本很高（短信收费）。有些情况下，短信验证码本身就是需要被保护的对象（短信轰炸）。

主动发送型验证码对于用户体验极差（需要用户进行大量操作，用户需要为你的风控策略付费），除非这项业务已被垄断（例如某购票系统），否则老板几乎不会同意你这么做的。

况且这两种验证码都有收码平台可以无缝覆盖，单纯用作图灵测试没啥意义。

3、问答验证码

这是一个大类，包括百度贴吧的看拼音选汉字的验证码、12306的看文字选图片验证码、Googlenorecaptcha的二次图片验证，或者网上爆料出来叫你展开傅里叶级数统统都是问答型验证码的一种。

这种验证码的前身是题库，题库本身存在中容易被穷举的弊端。其他“高级”问答型验证码的安全性，则除了依赖计算机视觉功能受限外，还依赖于人类的认识活动无法被机器模拟的大前提。

对于打码平台来说，问答型验证码还是轻而易举的（你要是用高数题作验证码算我没说）。

4、字符型行为验证码

常见的有Googlenorecaptcha第一次验证或者常见的一些拖动型的验证码。这些验证码每个都声称自己用了什么机器学习、大数据分析、人类行为建模等等一大堆听起来就很牛逼的技术。

5、语音验证码

语音验证码大多属于无障碍设施的一种，为的是视障人士也能正常通过验证，后来演化成对抗猫池的方向之一（需要接听来电）。之前还出现过Googlerecaptcha被Google自己的语音识别API干翻的趣事，这里也不再一一展开。

上面这些验证码呢，应该基本覆盖了日常能见到的绝大部分场景，也是打码平台或者收码平台存活下去的基础。

大家有没有发现，这些验证码有一个共同的特点：上下文无关。

这里我们定义一个概念：上下文无关验证码。

上下文无关验证码是一个问题与答案或规律一一对应的集合，对于任意给定问题，一定能通过问题本身得出答案。

同学们，划线部分是重点，打码平台要考啊！！！

既然验证码的应用有场景性，也有具体的上下文，那我们以前都没用到几个“参数”，我们是不是可以考虑用它一下？

这里的问题设计是有技巧的，它需要满足一个条件：上下文包含的内容中存在用户不愿或不宜公开的信息，且该信息服务器知晓。

用一句话来形容一下这一类的验证码：就算截图发给基友，他也不能给出正确答案。

怎么，这样的形容很模糊，不够形象？

现在，我们把验证码输入策略稍稍往后推一步——在用户提交完账号和密码后要求输入这样一个验证码：

我们设想一下，如果机器或打码平台需要识别出这个验证码要满足什么条件：

做题者需要是人，或具有相当精度的OCR工具（OCR识别几乎不能有错）；

做题者需要知道这个提交者的账号和密码明文；

那么，这样一样来，先不说打码平台如果能实现后费用必须各种增加，光这第二点就会把打码者和攻击者之间的利益约束消灭：既然我已经知道了账号密码，要你攻击者何用？而对于做题者即是提交者来说，这样的设计不会带来什么问题。

请选择下图中您手机号【没有/有】包含的数字。

请选择下图中您地址中【包含/不包含】的【省份/县市/具体地址】。

请选择下图中您获取优惠券名称中【包含/不包含】的汉字。

请选择您要添加的好友名称。

本文只是抛了块砖，希望给大家在设计验证码的时候可以有一个新的思路。标题可能有些夸张，还请海涵。