【腾讯Bugly干货分享】腾讯验证码的十二年

本文来自于腾讯bugly开发者社区,未经作者同意,请勿转载,原文地址:http://dev.qq.com/topic/581301b146dfb1456904df8d

Dev Club 是一个交流移动开发技术,结交朋友,扩展人脉的社群,成员都是经过审核的移动开发工程师。每周都会举行嘉宾分享,话题讨论等活动。

本期,我们邀请了 腾讯 TEG 安全平台部的张彦玲、陈秋滢、华珊珊三位嘉宾,为大家分享《腾讯验证码的十二年》。

内容简介:

验证码的诞生就是用来对抗自动机,但随着OCR技术的发展,腾讯验证码怎么发展让它能够有效持续对抗自动机。


以下为本期分享实录:

大家好,我是张彦玲,来自腾讯TEG安全平台部,现在负责验证码研发工作。今天还有我们两位同事:陈秋滢和华珊珊,大家有什么验证码产品和未来的问题也可以和两位同学一起探讨。

现在先由珊珊给大家分享腾讯验证码的十二年。

一、腾讯验证码的诞生

当然,鹅厂也经历过没有验证码的时代。这就得从十二年前那股疯狂的“挂太阳”热潮说起。如果是QQ老用户,那你一定记得那些年我们挂过的星星、月亮和太阳。伴随着这股热潮,网络上开始出现一种特殊服务——代挂QQ,也就是代挂团伙为有需要的用户长时间登录QQ以提升等级,这就需要用户把帐号密码给到他们。

然而,这种黑产服务导致大量密码遭到泄漏,坏人手里掌握的密码资源哗啦啦多了起来,开始不断尝试盗号以获利。因此,QQ帐号开始频繁遭到坏人自动化程序的暴力破解。

面对来势汹汹的敌人,鹅厂急需新的对抗手法来拦住坏人疯狂进攻的步伐!于是,正如大家所见,QQ登录场景中的验证码应运而生,并有效打断了坏人自动机暴破的疯狂节奏。从那时起,验证码正式登上我们的历史舞台。

二、免验证码时代

同学们应该还记得,在2008年之前,凡是在网页上登录QQ都得输入验证码。没错,当时的策略是“一视同仁”,给全员下发验证码。经过一段时间的摸索,团队开始意识到一个问题:验证码只是一种手段,不是目的。设立验证码这道防线的初衷,是为了拦住“坏人”,而不是拦住“所有人”。

举个例子,你在一处别墅开了个盛大的公众派对。为了防止不怀好意的人趁机混进来,你请了保安在门口进行安检。可是,有没有必要对所有来客都进行安检呢?如果是认识多年的好友,或是常来你家串门的邻居呢?如果你全都同等对待,友谊的小船肯定说翻就翻。

因此,安全平台部联合即通登录团队,开始尝试对那些明显是正常用户的行为免去下发验证码。也就是通过安全大数据的能力,自动区分机器与正常用户,向机器下发验证码拦截,对好人则免验证码直接登录,以此提升用户体验。在腾讯,我们把这项平衡安全和体验的策略工作称之为“免验”。

【腾讯Bugly干货分享】腾讯验证码的十二年

如图,对可疑行为下发验证码。

在下发“免验”策略初期,只能免掉10%的验证码。随着数据积累和能力的提高,时至今日免验比例已达到90%以上,大大免去了正常用户辨别验证码的苦恼。直到现在,免验策略还在持续优化。

三、策略为王

1、大魔术师

当大部分的好人都不会遇到验证码时,另一头,给坏人下发验证码的战场还在继续。进入2010年后,随着微博和团购的横空出世和快速发展,黑产从业者的可图之利增多,互联网黑产市场不断扩张。作为绝大多数互联网业务的第一道安全防线,验证码的战场正式进入了一段破解与抗破解的持久博弈。

【腾讯Bugly干货分享】腾讯验证码的十二年

如图,这是早期的密码暴力破解软件。

在很长一段时间内,为了避免被坏人的自动化程序识别,业界普遍把验证码设计得越来越复杂。长久下来,就形成了机器人和用户都看不懂的尴尬局面。

显然,把验证码“复杂化”这条道路走不通,那怎么办?在长期研究坏人的作恶模式及利益链条后,我们发现坏人在破解验证码时存在一大死穴——时间。从一套新的验证码出现,到坏人成功破解,再集成到自动化软件流入黑市,整个过程需要一个周期。那么,如果我们更新验证码的速度快于坏人的工作周期,问题不就迎刃而解了?

做个假设,第一天,网站上了验证码A,这套验证码简单朴实、清晰可辨,简直就是那么多反人类验证码中的一股清流!坏人一瞅,这不是在藐视我的智商吗?于是废寝忘食连日研究,很快在第三天时就研究出了破解方案。正当坏人得意洋洋准备投入使用时,殊不知在第二天时网站已换上了验证码B。这里面的制胜点就一个字,快!

基于这种对抗理念,在2011年7月,“魔术师”验证码诞生了。如同魔术师快得让人看不清的手法,魔术师验证码采用了高频的切换策略,使对抗形成了“敌方未破我先变”的局面。果然,敌人自动机大军的步伐被成功遏制,铩羽而归。

【腾讯Bugly干货分享】腾讯验证码的十二年

如图,原有验证码 vs 魔术师验证码

2、猜你喜欢

如同超级英雄电影里一波又一波打不尽的反派一样,为了巨大的潜在利润,敌人永远不会消停。在“魔术师”换来了近一年的风平浪静后,我们遭遇了有史以来最为疯狂的一波进攻。

由于魔术师的字体库在现网已跑了一年,再加上图像识别技术的发展,坏人几乎已遍历研究。以前,只要验证码的字体一切换,破解率立马就会刷刷地往下掉。而现在,破解率仅小掉一下马上又反弹了。换字体策略已失效!曾经立下无数汗马功劳的魔术师验证码,如今成了一道马其诺防线。

敌人已经兵临城下,怎么办?经过研究我们发现,任何一种自动机,对验证码的识别率都不可能达到100%,有验证成功的图片,肯定也有验证失败的图片。做个假设,某种自动机的破解率是10%,也就是指在100张图片里,有90张无法识别。那么我们把这90张图片收集起来,每次都给它下发这些图片,10%的破解率会瞬间掉到0%。因为此时,自动机已陷入了绕不开的死结。

根据这个思路,2013年元旦前,“猜你喜欢”验证码诞生了。“猜你喜欢”通过分析自动机行为特征,自动寻找、收集自动机的弱点,反复攻敌之弱。这可以说是对自动化破解的“致命一击”。

【腾讯Bugly干货分享】腾讯验证码的十二年

如图,原有验证码 vs 猜你喜欢验证码

在体验上,“猜你喜欢”摆脱了对图片复杂性的依赖,做到了“高清无码”,正常用户的识别率提高到了90%以上。在安全性上,防破解效果立竿见影,据团队监测,气急败坏的敌人连最后的IM登录验证码都不来尝试破解了。“猜你喜欢”验证码以其强大的杀伤力,终于又换来了暂时的息战。

四、验证码的挑战

前面我们介绍的都是对抗自动机,然而随着验证码对抗战场越发激烈,黑产也推出验证码的杀手锏--打码平台,利用廉价的人工智能, 从设计原理上突破验证码。验证码(CAPTCHA)的英文全称就是全自动区分计算机和人类的图灵测试,对方是人,验证码就失效了。

【腾讯Bugly干货分享】腾讯验证码的十二年

如图,打码平台的原理。

而让这个情况更糟糕的是打码和深度学习结合,打码平台和使用打码平台的开发者给自动机破解程序提供样本,通过神经网络学习,破解程序可以很快做到非常高的破解率。

正如外国学者Elie Bursztein等人所编著的论文(The End is Nigh: Generic Solving of Text-based CAPTCHAs),字符验证码终结将至。

五、新验证码时代

字符输入是我们最熟悉最常遇到的验证码,然而在打码平台和深度学习的结合下,字符验证码最终将会退出舞台。

【腾讯Bugly干货分享】腾讯验证码的十二年

如图,12306识图验证码 vs 知乎倒立验证码

【腾讯Bugly干货分享】腾讯验证码的十二年

如上图,Google的nocaptcha vs 极验、阿里滑动验证码

鹅厂从2013年开始尝试新型验证码,2013年的识图验证码。和12306验证码很像,当时的图片是设计师画的,最终因为图片资源难以满足自动机对抗要求的海量数量需求而暂时没推广。还有2014年第一版拼图验证码尝试。

【腾讯Bugly干货分享】腾讯验证码的十二年

新时代验证码需要更大的舞台和更快的反应:摒弃了过去多年对字符的依赖,它可以快速支持和推广新型交互验证码。另外,用户在完成操作同时,前端会收集用户行为数据,通过机器学习,为线上策略输出更准确有效的策略。

【腾讯Bugly干货分享】腾讯验证码的十二年

如图,几种新型验证码。

六、最后的话

在上世纪五十年代,人工智能之父阿兰•图灵设计出了图灵测试。在约半个世纪后,图灵测试的理念被做成最简单粗暴的形式——验证码,渗透到人们互联网生活的方方面面。然而,验证码是一个时代的产物,是一种治标不治本的速效手段。战术和战略的改变,才是终极解决方法。

可以预想,终有一天验证码会退出互联网的历史舞台。但现阶段,由于巨额潜在利润的驱动,不法之徒必定不会放弃对验证码的虎视眈眈。无论是过去、现在,亦或是不远的将来,这都注定是一场没有硝烟的血战。未来,我们拭目以待。

好的,今天的分享就到这里。非常谢谢大家。也欢迎同学们一起来探讨。

最后打个广告:新一代验证码依赖前端收集数据,我们非常需要前端大牛加入我们团队,有意向的同学可以请发简历到我邮箱:80000768@qq.com

互动问答

Q1:字符验证码为什么不好,不适应时代了?听了你们这么说,我也在想字符验证码是不是要换

随着OCR的发展,字符验证码对抗非常艰难。字符验证码的舞台太小,继续发展下去,会出现自动机容易破解而人很难通过的状况。不过腾讯有很多业务还在用字符验证码,字符验证码完全退出舞台还需要一段时间,我们也在向业务推广新型验证码。

Q2:不明白那个滑动验证码有什么不一样的地方,感觉自动化破解应该很容易,不像其他的,需要语意识别

从字符验证码到多样化验证码的转变,最主要的变化,其实是验证码不再单纯的依赖图像去对抗,而是加入了更多元化更全面的元素,比如用户行为识别、后台策略对抗等,只依赖图像原因不够,但图像加上大数据和AI的强力支撑是可以对抗坏人的。也是因为这样,用户反而能用上体验更好的验证码

Q3:拼图验证码的拼图块是怎么生成的?又是怎么校验的呢?

从图库拉取一张图片,随机在图片抠取一张小拼图块。服务器生成时会记录小接图块的位置。用户在将小拼图块拖动到目标位置时,提交座标给服务器进行答案校验。

Q4:就上面提到的各种验证码来讲,现在哪种验证码的效果最好呢?

不同产品面临的战场不一样,比较难下定论说哪一种验证码效果最好。各大公司的安全团队在验证码方面也下了很多功夫,但从目前坏人的手段和技术来看,大家拼的更多的是后台策略,而不是单纯的验证码本身了。适合自己的才是最好的。

Q5:模拟用户操作为什么打码平台无法破解呢?本质上应该也是识别图片信息并上传相应的数据吧?

首先,新验证码也有打码,比如像下图这种打码软件,所以只靠图像没办法对抗码工。这种软件提交的答案也有其特征,座标答案由码工标注,恶意程序合成行为数据,新验证码对这种情况是可以区分的。

【腾讯Bugly干货分享】腾讯验证码的十二年

Q6:现在日益的发展下.指纹验证的频率也越来越高.有没有对这方面的考虑?

指纹验证本质是身份验证,验证码是对抗自动机,不过随着移动设备指纹的普及,用指纹做身份验证,免去验证码是有可能的。

Q7:现在经常Q群里喊着坐家就能赚钱的那种软件,好像就是把验证码下发出去,让社会闲散人员帮你识别,这种怎么破?

对于人工打码,5的问题有提到一些解决思路。但还是基于现在打码平台,如果打码平台升级,确实这里的识别非常困难,大家有什么好的思路也可以发邮箱给我:80000768@qq.com

Q8:是不是可以根据用户职业和身份来给用户出些相关专业的常识作为验证码?或者是有哪些用户认识的QQ好友让他选择也行啊?

这个方法是可行的,实际上facebook也有采用这个方式来对用户进行验证。这个手段来对抗码工是一种比较好的方式,但他的局限性也很明显,使用门槛比较高,一来是有可能泄漏用户隐私信息,二来他使用场景很有限,在注册、活动、拉新等没有用户信息的场景无法派上用场

Q9:用户要记住使用密码和要识别验证码,感觉都属于反人类设计,验证码未来什么情况下可能退出历史?

验证码的用户体验需要不断地优化完善,但其实验证码的设立很大程度上是为了对抗高频的暴力破解,阻挡坏人的自动机进攻的步伐。所以在现阶段还是非常必要的。验证码彻底退出历史舞台,预计还需要比较长的一段时间。

Q10:将来有没有可能用到语音验证?

关于语音验证码,大家用微信也知道,语音识别技术很成熟,识别率已经很高了,因此用来做验证码效果也不见得会好

Q11:手机端app验证码大多都比较简单,为什么pc端的特别复杂?

这个其实有历史原因在里头。在前些年,4G没普及,上网速度慢,验证码的图片不可能做得太大,会影响页面打开速度;而且那个时候也没很多大屏手机,屏幕小,留给验证码发挥的地方也小。从那个时候就延续下来了。但现在其实很多手机验证码都和PC一致了

Q12:大量用户去请求验证码,怎么确定每个人验证码对应的就是相应的用户?

验证码的架构设计之初,已经是按照亿万级访问的场景来设计的,能支撑起大量用户访问的

Q13:前端会收集用户行为数据,通过机器学习,为线上策略输出更准确有效的策略。 同样的道理,可以通过机器学习模拟用户的行为轨迹从而来破解滑动拼图验证码. 这个怎么破?

这个问题问得十分漂亮。目前验证码主要的战场和矛盾点也是这个,随着机器学习的不断发展,我们遇到的挑战也越来越多,但即使这样,我们还是会不断朝这个方向努力,不断尝试和跟坏人斗智斗勇。

Q14:怎么评价阿里云的这种验证码,基于当前登录账号的历史数据提问,微信好像也有采用这种形式,比如选择好友。

【腾讯Bugly干货分享】腾讯验证码的十二年

基于当前登录帐号的历史数据提问,跟上面的一个问题类似的,这种更多是身份验证,用在登录场景比较合适,但其他场景,比如注册,就无法发挥用途。另外,用户个人信息是有限的,经过多次尝试不断比对和过滤,也能获得正确答案。在无登录态下暴露用户信息也是很一个很大的隐患,因此鹅厂在这类验证码上的应用比较慎重,并没有大规模的用


更多精彩内容欢迎关注bugly的微信公众账号:

【腾讯Bugly干货分享】腾讯验证码的十二年

腾讯 Bugly是一款专为移动开发者打造的质量监控工具,帮助开发者快速,便捷的定位线上应用崩溃的情况以及解决方案。智能合并功能帮助开发同学把每天上报的数千条 Crash 根据根因合并分类,每日日报会列出影响用户数最多的崩溃,精准定位功能帮助开发同学定位到出问题的代码行,实时上报可以在发布后快速的了解应用的质量情况,适配最新的 iOS, Android 官方操作系统,鹅厂的工程师都在使用,快来加入我们吧!

上一篇:洛谷[LnOI2019]长脖子鹿省选模拟赛 简要题解


下一篇:转:LR的响应时间与使用IE所感受时间不一致的讨论