FoxVerify —人机验证/验证码

type

status

date

slug

summary

评估云验证码服务：为何不是最优解？

在遭受短信轰炸后，我们自然想到了业界成熟的云验证码服务（如滑动拼图、点选等）。然而，实践下来发现：

效果有限： 云服务验证码确实减缓了短信被刷的速度，但并未根除问题。对于有决心、有资源的攻击者而言，它们并非无法逾越的障碍。

成本高昂：

云验证码自身调用费用：大约 ¥0.01/次。

加上我们的短信成本：¥0.03/次。

单次验证的总成本达到 ¥0.04/次。这个成本几乎是纯短信费用的 1/3，长期累积下来是一笔巨大的开销。

自研验证码的动因与设计哲学

基于以上背景，我们决定探索自研验证码的可能性。主要目标是：

提高攻击门槛： 设计一种让自动化脚本（机器人）难以通过，或者通过成本极高的验证机制。

控制成本： 摆脱按次付费的云服务模式。

社区协作与简化： 将其开源，利用社区力量共同完善机器人检测规则库，并提供极其简便的接入方式。

坚持免费： 这也是我们被攻击的原因之一，但我们打算坚持下去 😂。

我们的验证码思路：利用AI模型的“软肋”

现有的主流云验证码（如拼图）存在被破解的可能性：

图像识别破解： 使用如YOLO (You Only Look Once) 等目标检测模型，可以训练来识别拼图缺口的位置。

轨迹模拟： 虽然云服务通常包含轨迹分析，但模拟出变速、非线性的“人类”鼠标轨迹对于脚本来说并非难事。我们的“骚操作”（借鉴了Google reCAPTCHA等大厂的思路）是：利用AI（尤其是非超大模型）在同时进行空间理解和场景上下文解读方面的局限性。

核心机制： 要求用户将图像旋转至“正常”或“符合常理”的方向。

示例：

对于人类，辨认这些图像的正确朝向基于生活经验和对物体、场景的理解，非常直观。

对于AI模型，如果没有针对性的超大规模训练，同时理解空间方位和图像内容（如“建筑物应该竖直”、“人脸通常是正向的”）存在挑战。

提高攻击成本： 破解这种验证码需要更复杂的AI模型和训练数据，显著提高了攻击者的成本。用原文的话说，从攻击拼图的“杀敌1000自损100”变为“杀敌800自损1000”，使得攻击在经济上更加不划算。

动态难度： 系统可以根据用户行为的可疑程度，动态调整验证码的难度（类似早期百度的做法）。

小玩一下？

可以访问这里体验一下验证效果。

如何对接？ (Integration Guide)

我们的目标是极致简化对接流程。

1. HTML 部分

在您需要显示验证码的地方，添加一个简单的 div 容器即可。无需预先引入任何 <script> 标签。

2. JavaScript 部分

在需要触发验证码显示的时候，执行以下JavaScript代码。请确保在执行前，上述的HTML容器 (<div class="__Fox__captcha__">) 已经存在于DOM中。

3. 后端验证部分

您的服务器需要接收前端通过 complete 回调发送过来的 okey 和 rand 参数，并调用我们的验证API来确认验证是否有效。

请求方式：GET

请求URL：

请将 <前端发送的rand值> 和 <前端发送的okey值> 替换为实际从前端接收到的参数。

响应结果：

API将返回一个JSON字符串。

💡

您的后端逻辑应主要关注 success 字段的值。如果 success 为 1，则表示用户通过了验证码校验。