前言
其实，做 hcaptcha challenge 的时候笔者就一直在想，到底下一代的验证码会是什么样子？验证码的发展历程究竟会是怎样？
Where is the Next Generation of Captcha？CAPTCHA 的历史？人机对抗？下一代验证码会是什么样子？
起源
在互联网早期，就有很多人为了躲避关键词屏蔽而使用 Leet Code。
在 2000 年 idrive.com 开始使用 CAPTCHA 保护注册页面，这也是第一代的验证码。
在最初机器学习，尤其是深度学习还没有得到广泛使用的时候，这种验证码最简单的方式，就是 “众包”。把图片传到服务端，有服务端分配任务到工作者，这也就是当初的 “打码平台”。读者有没有尝试过，但是笔者在初中的时候就接触过打码平台这是说法，甚至有可能是笔者的第一桶金(?)，因为我也忘记了。当初一个验证码大概价格因为时间久远，笔者也记不太清楚了，可能打上一小时的验证码，大概可以得到 1 元，单个验证码的价格可能只有几分，熟练的可以一天 20 以上，有些人全当练习打字了 hhh，当初笔者也是抱着这种心态去的。
到了后面，出现了光学字符识别（OCR）来对抗这种验证码，现在应该是很常见了，但在当初不成熟的时候，还是有很少的人去做这个。解决当时的 OCR 也是非常轻松，加点噪声，加条横线可能就通过不了了，因此又转回了 “众包” 的形式。
再后来出现了很多这种图片验证码的数字题，这就要求不仅要字符识别准确，还要进行一步的计算。
丰富多样的验证码
而如今，基于这种图片字符识别的验证码被 OCR 攻破后已经不太常见了，取而代之的更多种类丰富的验证码形式。
比如在图片中依次点击出现的问题，这个字还会有倾斜歪道的情况，颜色也会不一样，这就要求了 OCR 的鲁棒性要足够的高，并且传回的数据其实就是点击而已。
也有从文字变成图标、图形的形式的验证码，整体逻辑还是一样，不过已经不再是文字识别，变成了图像的匹配问题。
还有滑块验证码，将滑块从左划到右就完成了，这个的难度在于需要按住滑块，而不再是点击屏幕，并且滑动的速度也不应该是常数。
还有滑块验证码的改进版，也就是拼图验证码，比如 GeeTest 中使用的拼图验证码，在滑块的基础上加上了上方图片的拼图，可能会有干扰项，比如图片突然暗下去一块毫无相关的拼图。
图像识别
再者到了 reCAPTCHA 的高级验证码时代，要求变成了图像识别 或者 目标检测，然你选择包含公交车或者人行横道的图片。这样的验证码也引起了一堆人的吐槽，很多时候自己觉得自己选的全对，而未通过验证，有时候还会让你点按很多次，同时还会有响应时间的限制，引起很多人不满的同时，也让很多人开始怀疑自己到底是不是人类 hhhh
然而只要收集到一定数据集以后，YOLOv5 出现以后，以其高速轻量级的性能，很快便成为了这类验证码的克星。
hCAPTCHA 也加入了这场战斗，占有了不少的市场，最近 hCAPTCHA 的验证码升级确实让我眼前一亮（比如 vertical river, sky left airplant, elephant drawn with leaves），把生成式对抗网络放在验证码中提供了无限的数据，但当我用更简单的方法([1][2][3])解决的时候，不禁会怀疑其存在的意义。
下一代验证码
一个比较有趣的事实是，验证码保护的网站可以免受攻击，但是验证码提供的网站却是在裸奔。
想要爬到裸奔的验证码数据再简单不过，而对于这种 9 格的验证码，基本都会是一个二分类的任务，因为你只有两个选择（点 或者 不点）。并且，由于验证码自身的限制，无法使用高分辨率的图片，这就导致，不仅模型可以尽可能的小，而且图片的特征会是很明显。
当一个对抗者跟上了验证码更新的频率后，这是很可怕的，因为每出现一个新的任务，对抗者只需要不到 1 天就可以完成数据的标注和模型的训练。
这就会很让人怀疑，一个验证码的算法工程师，利用了大半个月的时间做了一个足够部署到生产环境的生成式对抗网络，对抗者用不到 1 天完成数据的标注和模型的训练，很难让人觉得这究竟值得吗？
而且做验证码终究是为了人来服务，如果让用户体验变差了，这会是个好结果吗？
关于下一代的验证码，我想从两个方面来讲起：
-
图片式
这种验证码机会不会有未来（毕竟现在做 DL 方向的 CV 有多卷大家都应该清楚吧），但是临时的使用会起到一定效果，比如你可以用一些三维渲染出的结果来考验模型的三维理解能力，目前三维的理解还是有些许难度，诸如此类。
-
化繁为简 - 无验证码
reCAPTCHA 已经在尝试了，这估计会是下一代验证码的主流方向，通过浏览器或者系统级别的环境监测来判断是恶意用户的概率，可以再结合用户行为建立一个多模态的模型，这种不仅可以优化用户体验（因为用户根本察觉不到验证码的出现），同时拦截恶意程序。
