验证码的前世今生（前世篇）
发布时间:2018-05-23 | 发布者： 东东工作室 | 浏览次数： 次
常在网上晃悠的人，对上面这张图都不会陌生。特别是在注册新账号、确认交易时，它们都会频繁出现，要求我们输入正确的验证码，那这些看上去跟我们要做的事情完全无关的验证码到底有何作用呢？
0×1诞生首先，先介绍下验证码程序的提出者，路易斯·冯·安(Luis von Ahn)。2002年，路易斯和他的小伙伴在卡内基梅隆第一次提出了CAPTCHA(验证码)这样一个程序概念。该程序是指，向请求的发起方提出问题，能正确回答的即是人类，反之则为机器。这个程序基于这样一个重要假设：提出的问题要容易被人类解答，并且让机器无法解答。
在当时的条件下，识别扭曲的图形，对于机器来说还是一个很艰难的任务，而对于人来说，则相对可以接受。yahoo在当时第一个应用了图形化验证码这个产品，很快解决了yahoo邮箱上的垃圾邮件问题，因此图形类验证码开始了大发展时期。
0×2发展与问题图形化验证码在被证明有效后，在互联网上迅速得到了推广。国内外各大网站，在关键的业务点上都加入了这一类型的验证码。
首先，由于开发者水平的良莠不齐，导致验证码本身的实现存在问题，从而导致漏洞可以绕过，常见的有以下几种类型：
[1] 验证码的生成逻辑、答案用户可见如将验证码答案输出到页面中、写在cookie里。打比方就是说，在发卷的时候，把答案写在了卷子背面。(老师再也不用担心我的成绩)
[2] 验证码的生命周期未控制好如验证码可以重复使用、不设超时。验证一次，永久使用。
[3] 业务逻辑与验证码结合点存在问题如修改业务参数可导致不用校验验证码也可通过、甚至验证码就是摆设。结合到具体的业务点上有什么危害呢？
a. 验证码写在cookie中。此处可导致旅客信息泄露。
b. 验证码与图片存在对应关系，因此直接访问html即可得到答案。此处可导致撞库与暴力破解密码。
（上述两例转自乌云）
（上述两例转自乌云） 0×3图片验证码对抗与攻击升级
在开篇我们提到了一个重要的假设：
CAPTCHA提出的问题要容易被人类解答，并且让机器无法解答。
实际上，CAPTCHA所要处理的问题是：将普通人与恶意的用户（黑客、垃圾消息发送者）区分开来。那当时间点到达2016年时，黑客们与普通用户之间的差距已经很大了（想象下中国足球队对巴西足球队，而且此时留给中国队的时间已经不多了）。
因此，CAPTCHA在图片验证码这一应用点上已经无法满足这一假设了。在这段时间内，出现了很多的加强和识别图形验证码的方法（每一种方法的详细原理和解释，可以参见wooyun drops，在此不做详述）：
附上部分名词解释：
如上图所示，原始的图像使用了字体旋转、背景色混淆等手段，在专业的验证码工具面前，也就是几个命令拼接即可完成识别
如上图所示，是一个验证码识别软件自建字库的过程，通过回车确认验证码识别正确，如有错误，稍带修改继续。当保存了上千个正确识别的字库后，该程序便可达到一个可用的可用的准确率。（其实若不不做其他限制，此时准确率在30%以上时，即可造成很大的危害，毕竟对于攻击者来说，发3个包与发1个包的成本差别不大）
看到这里，客户们大概可以回答这个问题了：
为什么我用了验证码还是会被刷？
那普通验证码难道没用了吗？
那倒也不是，安全是一个博弈的过程。综合使用之前提到的验证码技术(特别是字体粘连等)，并且保持关注和变化，攻击者的识别率也比较低。当攻击的成本大于可获得的利益时，自然就没人来攻击了。（普通用户在此应强烈要求存在感）
此时，虽然两方大小上略有差距，但是总体战斗力还算是勉强打个平手，互相出招而已。只是随着战火的升级，个人轮番上阵后，验证码已经违背了他最初设计时的初衷：对普通用户的友好性逐渐消失。而普通用户的体验也就成了这场战争中的牺牲品，这也就造就了一批有一批被用户吐槽的无法辨认的验证码。
转载请标注：我爱技术网——验证码的前世今生（前世篇）