验证码的前世今生(前世篇)

简介:


常在网上晃悠的人,对上面这张图都不会陌生。特别是在注册新账号、确认交易时,它们都会频繁出现,要求我们输入正确的验证码,那这些看上去跟我们要做的事情完全无关的验证码到底有何作用呢?

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,在此不做详述):

附上部分名词解释:

预处理:灰度值二值化、去噪点、连通性补全等

切割:通过滴水算法、统计方法等得到单个字符的所在位置

机器学习算法:将经过处理的每个字符进行训练,训练后得到识别答案(SVM、KNN、神经网络等)

字库:与机器学习算法类似,将处理后的字符人工导入,构造字库,对长期不变的验证码较为有效

如上图所示,原始的图像使用了字体旋转、背景色混淆等手段,在专业的验证码工具面前,也就是几个命令拼接即可完成识别

如上图所示,是一个验证码识别软件自建字库的过程,通过回车确认验证码识别正确,如有错误,稍带修改继续。当保存了上千个正确识别的字库后,该程序便可达到一个可用的可用的准确率。(其实若不不做其他限制,此时准确率在30%以上时,即可造成很大的危害,毕竟对于攻击者来说,发3个包与发1个包的成本差别不大)

看到这里,客户们大概可以回答这个问题了:

→ 为什么我用了验证码还是会被刷?

那普通验证码难道没用了吗?

那倒也不是,安全是一个博弈的过程。综合使用之前提到的验证码技术(特别是字体粘连等),并且保持关注和变化,攻击者的识别率也比较低。当攻击的成本大于可获得的利益时,自然就没人来攻击了。(普通用户在此应强烈要求存在感)

此时,虽然两方大小上略有差距,但是总体战斗力还算是勉强打个平手,互相出招而已。只是随着战火的升级,个人轮番上阵后,验证码已经违背了他最初设计时的初衷:对普通用户的友好性逐渐消失。而普通用户的体验也就成了这场战争中的牺牲品,这也就造就了一批有一批被用户吐槽的无法辨认的验证码。

正当普通用户们不断吐槽的时候,程序员表示这个锅不想背但是也得背。因为业务总是要做的,而攻击者们也是要吃饭的,升级了验证码的成本,也就限制了风险的等级,于是就变成了这样一个模式╮(╯_╰)╭:

程序员:熬一晚上升级

攻击者:熬一晚上破解

程序员:熬两晚上升级

攻击者:熬两晚上破解

....(心疼)...

大家就在这种你方唱罢我登台的情况下看似和睦的度过了一段时间。

0×4 图片验证码的没落

在日日夜夜的对抗中,攻击者想到了一个办法,可以一劳永逸的解决图片验证码的问题。在我对这些搞灰产的人们表示憧憬之前,先说点题外话。

2009年,google买下了CMU的一个项目:recaptcha。这个项目是CAPTCHA的进阶版本。它所基于的假设与CAPTCHA一致,但是它同时让用户识别两张图片,一张用于验证用户身份,而另一张用于帮助难以用机器识别的电子文档。

恩,如果读者有从事此类灰产相关工作的人,请注意recaptcha右下角的小字(stop spam.read books)看看这情怀。

而recaptcha的作者,当然又是:路易斯·冯·安。在recaptcha的基础上,路易斯进一步提出了一个概念:人类计算(Human Computation) 。

简单来说,他希望借由计算机和网络平台,发挥人类技能,去解决大规模、复杂的问题,具体到recaptcha项目来说,就是借助大家的力量去帮助数字化书籍。(该思想的具体应用还包括一个叫ESP GAME的游戏以及后面会提到的no recaptcha)

但是,在2004年(我能搜到这个新闻的最早时间),就有人已经完美的实现了这个概念:人工打码,并且起源地:中国(此处我应该感到自豪吗)。

所谓的人工打码就是,将验证码的请求转发给某平台,该平台会将这个信息发送给平台上的打码工,然后打码工人识别后,将答案反送回请求者。通过打码平台的api,攻击者可以写程序实现对目标的自动化操作,而验证码的部分只要交给打码平台就可以了。

打码平台在国内市场上的火爆,有几个原因:

  1. 从2006年开始,国内互联网的迅猛发展,使得流量变现成为了可能。各种邮件营销、SEO、IM工具等都迫切的需要稳定的可以绕过图形验证码的方法。而近些年兴起的基于数据的诈骗、账号盗取等更进一步加剧了这个趋势。
  2. 打码平台的爆发式发展也同时得益于中国经济蓬勃发展的原因之一:人口多并且人力成本低。网络上一种常见的网赚模式,就是打码工模式,一个只要会上网,能识别验证码的人就可以参与。PS:难道你没有看见过下面这些广告吗?大学生、大妈,无需学历,只要会上网、会打字,一天包赚XXXXX。当然其中除了打码平台,还有很多骗子。

可以打码的类型包括:

  • 普通字母验证码
  • 中文验证码
  • 鼠标类型类验证码
  • 选择题类型(比如某些网游中做任何会遇到的验证码)
  • 旋转类验证码
  • 知识常识问答型验证码

以上验证码的价格在平台上都是明码标价,普通的字母验证码1条在1分钱左右,而知识问答类在6分钱左右,相较于利用这些灰产所会产生的利益,真是件美物廉,重点是还非常稳定。

同时我注意到国外的价格现在与国内的价格已经相差不大,现在美国的价钱约为$1.5/1000,美国的打码工已经向东南亚扩展。打码平台一出现,2.2中提到的加强验证码的方法都无用了。因为不管你怎么变化,验证码总需要是人类能够通过的。

0×5 新的征程

打码平台的出现,虽然没有从理论上打破CAPTCHA的原则,但是也从事实上击破了防止程序自动提交的防御,因此我们需要新型的安全的验证方式。这些探索也带来了现在各种多样的验证码形式,这些我们将在下篇探讨。

最后用一个“富有情怀”的图片结束。

这张图不是来自改变世界的极客,也不是来自富有爱心的艺术家。它来自某知名打码平台的官网,是不是太有情怀了?(你们的确改变了我们的工作方式)

面对这样的情怀,我想我现在只能做一件事情。



作者:阿里聚安全

来源:51CTO

相关文章
|
存储 SQL 缓存
StarRocks常见面试问题(一)
StarRocks常见面试问题(一)
|
程序员 PHP UED
一直让 PHP 程序员懵逼的同步阻塞异步非阻塞,终于搞明白了
【9月更文挑战第8天】恭喜你掌握了同步阻塞和异步非阻塞的概念,这是许多 PHP 程序员容易困惑的地方。同步阻塞指代码按顺序执行,需等待操作完成;异步非阻塞则允许后台执行操作,不阻塞程序。理解这些概念能显著提升程序性能和用户体验,特别是在高并发场景和分布式系统中。随着技术发展,越来越多的 PHP 框架支持异步编程,掌握这些概念将让你在开发中更得心应手。
267 7
|
消息中间件 Kafka Python
Producer的错误处理与重试机制
【8月更文第29天】在分布式系统中,消息传递是核心组件之一,它通常通过消息队列(如 Kafka、RabbitMQ 或其他)来实现。当生产者尝试将消息发送到消息队列时,可能会遇到各种类型的故障,例如网络中断、服务器不可用等。为了确保消息的可靠传递,需要实现有效的错误处理和重试机制。
539 2
|
缓存 Java 关系型数据库
【超全详解】Maven工程配置与常见问题解决指南
检查Maven配置包括验证路径、设置pom.xml与Project Structure的Java版本。基本操作有`clean-compile`、`install`和`package`,其中`install`会将jar包放入本地仓库。获取他人工程后需修改配置、清除缓存、更新依赖等。配置文件应从Maven Repository找寻,选择稳定高版本。创建Maven工程可选archetype如`quickstart`或直接创建Java工程。基本目录结构遵循分层设计原则,常见问题包括假性导包、端口占用、时区问题等,对应解决方案包括删除本地仓库文件、调整系统设置或重新加载项目。
2448 6
【超全详解】Maven工程配置与常见问题解决指南
|
12月前
|
机器学习/深度学习 人工智能 自然语言处理
从平凡到非凡:借AI风口普通人如何起飞?
雷军曾说:“站在风口上,猪也能飞上天。”而AI无疑是当前最强劲的风口。本文介绍了如何抓住AI时代的机遇,包括理解AI基础概念、选择合适的AI工具、将AI融入工作提升效率,以及利用AI创造被动收入。通过这些步骤,你将能够在AI浪潮中获得成功。
594 0
从平凡到非凡:借AI风口普通人如何起飞?
|
传感器 监控 物联网
物联网与虚拟现实:未来科技的发展趋势与应用探索####
本文探讨了物联网(IoT)与虚拟现实(VR)这两大新兴技术的最新发展趋势及其广泛的应用场景。通过分析这些技术的核心原理、当前发展现状以及未来的潜在影响,揭示了它们如何独立演进又相互融合,共同推动社会进步。本文旨在为读者提供一个全面的了解,以把握未来科技的脉络,迎接技术革新带来的挑战与机遇。 ####
|
存储 开发工具 git
git工具使用教程全讲解
本文介绍了版本控制的概念及其重要性,详细对比了多种版本控制工具,如VSS、CVS、SVN和Git,重点讲解了Git的基本使用方法、工作原理及与SVN的区别。此外,文章还介绍了GitHub、GitLab和Gitee等流行的代码托管平台,以及如何在这些平台上注册账号、创建和管理仓库。最后,文章还提供了如何在IntelliJ IDEA中配置和使用Git的具体步骤。
449 1
|
存储 Android开发 Kotlin
开发安卓app OKhttp下载后使用MediaPlayer播放
在Android Jetpack Compose应用程序中,要使用OkHttp下载远程音频文件并在本地播放,你需要完成以下几个步骤: 1. **添加依赖**:确保`build.gradle`文件包含OkHttp和Jetpack Compose的相关依赖。 2. **下载逻辑**:创建一个`suspend`函数,使用OkHttp发起网络请求下载音频文件到本地。 3. **播放逻辑**:利用`MediaPlayer`管理音频播放状态。 4. **Compose UI**:构建用户界面,包含下载和播放音频的按钮。
|
计算机视觉 索引 Python
【Python】已解决:ERROR: Could not find a version that satisfies the requirement cv2 (from versions: none)
【Python】已解决:ERROR: Could not find a version that satisfies the requirement cv2 (from versions: none)
1534 0

热门文章

最新文章