图形验证码在携程的实践之路

作者简介：闵杰，携程信息安全部产品经理。2015年加入携程，主要负责黑产防刷，验证码，反爬以及UGC方面的产品设计，关注在低成本的前提下，解决以上场景的实际问题。本文由携程技术中心投稿，微信公号ID：ctriptech

从互联网行业出现自动化工具开始，验证码就作为对抗这些自动化尝试的主要手段登场了，在羊毛党，扫号情况层出不穷的今天，验证码服务的水平也直接决定一家互联网企业的安全系数。作为WEB看门人，它不仅仅要做到安全，也要兼顾体验。

本文将分享携程信息业务安全团队在这几年里，对图形验证码服务所做的一些大大小小的改变。各位可以将本文作为自身网站图形验证码搭建的小攻略，减少重复踩坑的情况。

1.0时代

过去携程曾经使用了一套基于.NET的图形验证码作为控制登录，注册，发送手机短信，点评，重置密码以及其他相关场景的主要手段，目的也很简单，就是防止非实人的请求。

在这个阶段，设计时仅仅是满足了防御异常请求，并没有考虑太多用户体验以及产品上线后，运营数据收集再分析改造的需求。

主要实现的功能点为：
 图片验证一次失效
 图片生成超时失效
 支持生成4位和6位验证码，字符以英文和数字组成
 支持简单的字符粘连，干扰线，干扰点，字体，字符大小，字体扭曲等配置。

验证码图示：

事后来看，这套验证码系统由于架构简单，接入简便，在很长一段时间内，担当了携程门户主要的看门人的角色，尽管各大BU并不是非常情愿地使用了这套服务，但是在防范撞库，恶意请求短信，批量获取优惠卷等场景下，还是体现出了一个验证码服务所应该起到的作用。

当时这套验证码服务上线后，遇到了不少的问题：

1、服务并没有对接入方做场景，事务等区别，整个携程的验证码难度都是统一的（除了部分BU自己开发了验证码），经常发生在A页面出现被扫号情况，需要增强验证码难度，但是B页面随之反馈，验证码太难，收到用户投诉，需要降低难度，无法兼顾。

2、服务记录的字段仅仅能支撑服务正常运行，业务数据没有进行记录。导致了验证码有时候调用和验证异常升高，完全无法知晓是谁在进行恶意尝试并进行拦截（比如封停恶意IP）。

3、只有英文数字，并且字体单一，设置的扭曲干扰线简单点，极易被OCR识别，假如设置的太难，就会造成连正常用户都无法识别的窘境，在很长的一段时间内，只能将难度设置在简单-中等这种难度，谈不上对于批量OCR有任何的防御。

而说到这类验证码的破解，业内目前通用的方案，我了解下来有这么几种

1、通过各种手段，绕过风控，或者绕过验证码，比如某些验证码是本地校验，有些验证码的关键参数会下发至前端，用户可以修改参数达到控制验证码的目的，有些业务方接入了验证码，但是没有把校验和业务接口绑在一起，导致人家可以直接请求业务接口，验证码形同虚设。也有业务方在接入验证码的时候，登录动作先于验证码校验，也导致了验证码毫无意义。这些在过往的接入过程中，都是实际发生过的情况。

2、ORC，从二值化，去除干扰线/点，确定字体区域，到最后识别，会根据验证码本身难度的不同，显著的影响其识别率。

3、人工打码平台。目前打码平台针对图片验证码已经很成熟了，针对数字，英文，汉字，智能问答都有不同的价格。

4、CNN神经网络识别。通过大量的样本进行机器学习，对于某些OCR比较难识别的粘连字符字体，可能会有一个较好的识别结果。

随着各类攻击越来越多，穿透性也日益增强，业务部门对于验证码难度需求不一致，以及自身对于验证码数据收集再改造的这些情况下，改造这个服务已经成为了摆在眼前的事情。

1.5时代

在总结了上述提到的这些问题以后，新需求就自然而然的产生了：

 英文和字母模型太过单一，极易破解，需要加入中文字库。
 业务数据保留，至少得知道威胁是哪些地方过来的。
 能够在面对大量的OCR或者暴力尝试场景下，自动变化难度，降低对方的识别率。
 区分接入的业务方，难度可以根据业务方做不同的调整。

在产品开发测试的一轮轮投入后，新的需求完成了，并且又花了将近一年的时间推广了各个BU接入了这个新的验证码。
（在这里说一个实际的情况，就是在第一版验证码开发的时候，并不重视保留接入方的信息，导致了在进行第二轮验证码重新接入的时候，发现老的接入方有3位数，但是要找谁，完全不清楚，以至于有些验证码到目前都没有进行更新，这个服务接入注册其实是一个很小的功能，但是在版本更迭，重大事务通知上，能起到非常重要的作用）。

新版本验证码比较好的解决了下面这几个实际场景面对的问题：

1、再也不会出现某个应用发现异常请求，刚刚调高难度没多久，就接到投诉电话，需要把难度降低这种场景，可以根据各自应用手动或者自动调节难度。（原先是整个公司都是统一的难度耦合在了一起）。

2、可以知道威胁是来自于哪个IP或者设备的，针对性的做出响应，比如封停请求。

3、在面对扫号配合OCR工具的情况下，这套验证码会自动不停的变换难度，干扰点/线，字体，背景色，粘连度等，经过实际对比观察，防御效果比老版本提高了2倍，这里我们的策略分为全局难度提高和针对纬度进行提高，比如假设只有一个IP或者设备的验证码请求发现异常，我们只会提高来自于这个IP或设备请求的验证码难度，对于其他正常请求是无感知的，但是在某些情况下，比如大规模的分布式扫号，可能你需要使用的就是全局难度提高。

4、支持了中文验证码，实际测试，英文数字在成熟的OCR工具面前，哪怕做了混淆，解析成功率也接近50%，假设换成中文配合一定的混淆，解析成功率一般不高于20%，这也是很多团队初期，假设没有风控和其他的辅助服务，最直接，成本最低的提高防御力度的方案。

这套方案，作为主流的验证码方案在携程应用了很久，但是在去年，团队也终于意识到，还有很多问题是这套验证码方案所无法解决的：

1、用户的体验问题，这个问题被公司内部诟病很久，并偶尔会收到来自于外部用户的投诉。其实也很好理解，一个四个字的随机中文验证码，手机输入一次大约耗时15-20秒，这个在活动营销拉新场景下，是一个致命的转化率杀手。在很多力度不是非常大的活动面前，这个验证码会直接打消一部分正常用户去尝试的念头（尽管中文验证码在防御恶意请求接口上有着巨大的安全优势），作为业务方产品不得不考虑，假设恶意用户的比例是5%，牺牲剩下95%用户的体验是否值得，即便也只有5%的正常用户放弃了尝试（比如一些年纪大的客户），和恶意用户的比例相仿，但是剩下的用户还是需要输入这些验证码，在用户体验成本上的让步是巨大的，这样就会让安全和业务陷入一种零和博弈的局面，这往往也是安全部门不受欢迎的主要原因。

2、接入繁琐，验证码和风控作为2个服务，需要业务方去耦合，分别接入，听起来就很繁琐，实际接入也确实很繁琐，大量的时间花费在接入服务上。

3、无法应对国际化，中文验证码国外用户不认识，英文数字过于简单压根没办法防御主流扫号攻击。实际发生过的案例就是携程海外站点被大规模扫号，但是束手无策的局面，分布式IP和设备，无法采用中文，几万个IP手动封不谈累不累，CFX都装不下，只能看着他扫。

4、丑，验证码图片由于需要防破解的关系，往往和整体页面UI的风格完全没有一个搭配感，让人很出戏。

和各大竞品比起来，我们的验证码确实就像是石器时代在和工业时代比较，也被公司内部一次次吐槽实在太影响体验了。在这种内忧外患的局面下，验证码服务更新又一次被放到了台面上。

2.0时代

需求又一次的被明确：
 接入要简便，不要让业务方再需要自己对风控结果和验证码来处理相关逻辑。
 体验要好，移动端时代，尤其要考虑移动端输入的习惯。
 安全性和国际化问题，至少不能让有些用户投诉自己无法输入中文字。
 美观，和页面UI尽量融合，也需要可以让业务方自行美化。

又是一轮一轮的测试开发，大约在半年前，完成了本次验证码重构的第一版，他主要实现了如下功能：

1、体验问题被解决了，在对比多种竞品以后，我们采取的方案为“滑块+选字”，在安全认为请求有风险的情况下，会出现滑块，假设在你滑动滑块期间采集的数据不足以认为请求是可信的情况下，会出现选字或者直接禁止请求访问，根据实际数据，用户滑动滑块的时间耗时一般平均在0.5秒一次，仅有很少的一部分用户会出现选字，选字一般的耗时在7秒左右，平均下来，整体耗时目前在携程实践下来，在1.7秒左右。

2、接入问题也得到了改进，业务方目前接入仅仅需要在页面上引入一个JS（APP为一个SDK），然后在监听到JS的一个事件提示，可以获取token后，获取token，由业务方服务端获取token以后到安全这里的校验服务校验，校验完成以后，整个流程就结束了，中间的判断风险，出现滑块，滑块校验，出现选字，选字校验这些步骤业务方都无需干涉以及传送数据，安全已经把后端的风控，风险仓库和验证码前端全部打通，业务方在无感知的情况下，相当于接入及使用了3个服务。

3、国际化问题，目前已经支持东南亚多国语言的选字和提示语服务，常用国家再也不会有无法看懂和无法输入的诟病。
新版验证码服务如图所示：