yahoo邮箱在九几年的时候，业务深受各种邮箱机器人的困扰，存在着大量的垃圾邮件，于是他们找到了当时仍在读大学的路易斯·冯·安(Luis von Ahn)，并设计了经典的图形验证码，即通过简单的扭曲图形文字进行机器的识别。
通过这个简单的图形，他们很快的控制住了垃圾邮件的数量，并将大量的机器人据之门外。
但是即使验证码解决了垃圾邮件的问题，我们仍要提出一个问句：
验证码是必要的吗？
阿里有句简单的话：不忘初心，方得始终。
验证码不是一个功能性的需求，他并不能带来业务的提升，也不能带来任何价值。
验证码只是为了解决机器问题才诞生的。在设计和验证码演化的过程中，必须同时考虑安全性和体验。
让我们老考虑验证码的最简化模型，关键点在于：生成的问题能够由人来解答，并且机器难于解答。
于是传统的图形验证码的重点就放在了如何生成让机器难于解答的图片上来。
从上图看来，相应的各种方法已经有了相当成熟的一些对抗办法，更不用说现在已经广泛泛滥的打码平台了。
结合我们安全性和体验两方面来讲，传统验证码在两方面来说都已经不能满足要求了。
树林里分开了两条路
现在随着攻防的升级和对抗的不断加强，验证码的面前针对安全性和体验这两个关键点分出了两条路：
- 从体验上来：基于人类用户的行为
- 从安全性上来：基于人类认知问题的答案
基于人类认知问题的答案，我们已经碰见过很多种了，这里简单贴两个：
当然也存在这类：
简要分析，优点明显：机器没有这个认知能力（废话，好多我都做不出来）
存在的问题有：
1.题库维护的难题。如果题库被遍历完成，那么其安全性无法保证。
12306为什么后面把问题变成了图片呢？ 因为有攻击者将每次的答案与出现的可选问题进行了多次重复遍历，当这个遍历到达一定次数后，会发现某个答案与某张图常常会关联出现（因为问题必定会有正确答案），通过这个出现概率即可得到答案。于是，12306才把文字变成了现在扭曲的图片。 并且还有研究人发现，12306的图片可能大量来自某百科，通过逆向使用该公司的图像识别服务，可以得到该图片的部分标签。
2.体验差
过年的时候，正常人平均都要答3、4次才能答对答案。而且部分图片因为分辨率不高、再加上缩小图片以后，会更加的看不清了。
基于人类用户的行为，具体点就是用户在进行相应操作时，会产生的操作记录和环境信息（详见设备指纹一文）等。
基于人类用户行为这条路是基于以下基础的：
- 机器人的环境有别于正常用户
- 机器人的动作或频率等有别于正常用户
- 机器人的在相应关键业务点的行为逻辑有别于正常用户
但是这个基础在技术对抗上有个更关键的点，在于如何构建一个安全的信道，将这些数据回传回来。如果这个信道的采集机制、加密机制和传输机制被攻击者所探知，那么以上采集的信息将没有秘密可言。（换句话说，攻击者会伪装成正常用户的行为发送数据）
阿里所采用的前端采集和加密机制，利用自动化混淆、加密函数随机选择、线上自动迭代等能力将web前端打造为了一个可信的端，并将数据回传。（详见验证码的前世今生系列）
该类方法的优点：
收回了对用户的强打扰将基于知识和问题的对抗转变为前端加解密采集等机制的对抗如果攻击者无法攻破这一层堡垒，即使打码平台存在也无法攻击成功
缺点：
加解密机制需要做到足够强，并且需要拥有攻击感知能力、线上的自我变更能力和自动化测试等能力
我们选择了同时走两条
基于上述思考，阿里滑动验证综合考虑两种类型的方法，结合并推出了滑动验证的体系：
通过基于用户行为的第一道防御将对正常用户的打扰降低，使得正常用户可以以极小的代驾通过滑动验证，而同时对不确定的用户实施知识型问题的验证，在拦截机器人的同时，保障业务的正常平稳运行。
再看看google先阶段的norecaptcha：
可以看到，google的模式与阿里的模式有些类似，所不同的是google所使用的验证码模式是点击，而阿里是滑动。
简单分析下google，对于第一步的点击验证，google更多的是通过其基于虚拟机的强混淆器对整个数据采集过程进行了加密，并综合了环境信息（如设备指纹、cookie、点击频率等信息）来进行判断，而第二步的知识验证也包括以下几种（部分在之前的图中没有出现）：
- 1.扭曲的图形
- 2.图形的分类
- 3.高级图形分类(会不断的出图，点完一张又一张)
那这样是否就是验证码问题的银弹呢？
之前已经提到过，无论是google的norecaptcha还是我们的滑动验证，其核心都在于其本身的风控引擎和相应的规则，对于攻击者来说也有两条路：
- 正面强行突破，破解前端的密文、然后模拟正常用户行为，达到直接通过的目的
- 退而求其次，通过触发二次验证过程，然后通过ocr或者打码等其他方法通过
rsa上针对googlenorecaptcha的破解
4月8日，BlackHat上公布了一篇来自哥伦比亚大学的论文，大致上讲了他们是如何突破google的norecaptcha验证码的。
简单说明下他们的破解过程：
1.攻击者通过大量的模拟器及代理IP来伪造Browsing History及Browser Environment来Fuzz测试Google的风险分析系统。测试过程中发现包括Useragent、Canvas Fingerprint、屏幕分辨率、鼠标行为动作众多因素均为风险判断的因子，风险判断决策返回结果随机且有严格的次数限制；
比如，攻击者发现，修改user agent、使用firefox而声称chrome等会导致norecaptcha出现回退，即出现普通的验证码。
2.在得出了这些参数与最终结果的关系后，也没有正面突破，走到了第二个思路，经过fuzz尝试后，发现google的容错性较高，即即使图中只有2个正确答案，你如果点击了3个图，包含两个正确答案，也算正确。并且，根据基于次数的统计发现，norecaptcha中出现答案的比例较多的为2个答案（74%），因此，攻击者很聪明的选择了每次选择3个图像的方法，因为这样做可以使得每次成功的概率提高（毕竟多选了一个可能正确的答案，即使选错了也可以对）。
3.同时，在大量的fuzz面前，攻击者们发现有些图片会时不时的出现。出现次数最多的一个图片出现了12次。他们开始意识到这些图片并不是实时生成的，而是从一个已经生成好的池子中生成的。重复的利用，也就意味着大规模的可能性。
尽管google生成的图每张的hash值不同，但是利用感知hash算法(Perceptual hash algorithm)，攻击者可以对每次稍微变换了hash的图进行相似度比较，如果相似度较高，即可完成对已打标完成的图的重定位。
重定位完成后，既可以对已经完成的答案进行重复利用，而这种重复利用在大规模的攻击中是非常重要的，无限弹药在游戏中的作用你懂的。
4.完成了以上动作以后通过用图片搜索相应关键字（利用google自己的功能搞google）、其他图片搜索引擎（Alchemy、GRIS、Clarifai、NeuralTalk）等对图进行搜索，并利用这些数据得到了大量的图片相关的子类标信息，越来越多的标签信息意味着对图片有了更多更高维度的刻画。通过在各个网站收集相关标签，即可得到一个对该图片较为全面的描述。
5.利用机器学习的算法，其实就是利用Word2Vec，将两个图的对应关键字放在一个向量空间中，然后利用余弦相似性原理，找出相似度最高的几张图片。（与我们传统的找两个相似的文献或同作者的思路类似）。
6.将之前的五步进行组装。
- 看见未曾见过的图，感知hash计算，如果是已有答案，直接给答案。
- 看见见过的图，直接给答案。
- 如果是未曾见过的，也不在数据库内，开启图形引擎获得标签信息，再扔进模型里面得到答案，将答案存入库里。
- 循环以上步骤比如：同时出现红酒、酒杯、酒这几个标签，那么对所有获得的标签进行相似性比对后，会取出带有酒这个标签的前几个图
阿里在实际的对抗中，我们也发现有攻击者无法攻破第一层防御，即他们无法正常通过，但是却知道如何触发第二级验证，并尝试通过破解第二级验证的问题通过。
如果想要真的做好在安全和体验间的良好平衡，需要同时在两个方面都下功夫，才能保证整体的安全水位。
前端可信端体系的建立、强大认知问题系统的建立需要持续不断思考和提高。我们的每一次的变更，接入的客户都将实时享受到更高安全等级的防护。