当验证码遇上区块链——用 PoW 对抗机器流量

背景

我们团队接手了一个为电商业务服务的验证码系统。该系统原生支持滑块、3D 点选和图像旋转等多种验证方式。然而，在电商场景下，“用户体验”是不可逾越的红线。为了尽可能减少对正常用户的打扰，我们初期只启用了最简单、最直观的滑块验证——一个没有任何视觉干扰的、纯粹的凹槽拼图。

这种对用户体验的极致追求，却也为黑产打开了方便之门。几乎在上线初期，我们便监测到这种“裸奔”的滑块验证被轻易攻破。攻击者利用简单的模板匹配算法，就能精准定位缺口，自动化程序可以毫秒级完成验证。

为了应对，我们走上了一条经典但痛苦的防御之路：升级加密算法。前端对关键参数进行加密，后端进行校验。这在短期内确实有效，但很快，我们发现自己陷入了一个消耗战的泥潭：

我们升级算法 -> 黑产逆向 JS 破解 -> 我们再次升级，引入更复杂的混淆 -> 黑产再次破解…

这场攻防对抗变成了一场永无休止的“猫鼠游戏”。我们赢下的，仅仅是一个短暂的“时间窗口”。每一次攻防迭代，都消耗着团队大量的研发精力，而我们深知，只要防御逻辑仍在前端，就终有被逆向的一天。我们是在用宝贵的研发资源，去和黑产进行一场注定被动的、低效的消耗战。

此时，我们意识到，必须跳出这个“加密-破解”的循环。我们需要一种新的防御思想，一种能从根本上改变攻防不对等局面的武器。 这便是我们转向探索 PoW (Proof-of-Work) 验证码的契机。

什么是PoW

这里引入一个形象的比喻：

场景： 一座巨大的金山，黄金藏在无数普通的石头里。

• 淘金者（矿工/客户端）：
  你有一把锤子。你的工作就是不停地砸石头，希望能找到一块里面含有黄金的特殊石头。你可能砸了 1000 块石头才找到一块。这个过程非常辛苦，需要付出大量的劳动（工作量）。
• 鉴定师（服务器）：
  当你找到一块你认为含金的石头后，你把它交给鉴定师。鉴定师有专业的仪器（就像哈希函数），往石头上一扫，只需一秒钟就能确定这到底是不是金矿石。
• PoW 原理对应：
  • 工作量： 不停砸石头（尝试不同的 Nonce）。
  • 证明： 你拿出的那块金矿石（正确的 Nonce），本身就证明了你付出了大量的劳动（砸了很多石头），因为找到它没有捷径，只能靠运气和体力。
  • 难度： 如果金矿石越来越稀有（难度增加），你就得砸更多的石头才能找到一块。

PoW的两个关键特性

• 求解困难 (Difficult to Find): 找到正确答案需要大量的尝试（算力消耗）。

• 验证容易 (Easy to Verify): 服务端拿到答案后，可以瞬间验证是否正确。

技术原理

哈希函数

挖矿：

1. 服务端生成挑战字符串（Challenge String），例如prefix="hello_world"
2. 服务端设定一个难度目标（Difficulty Target），例如给定4，需要找到Nonce,使得SHA256(prefix+Nonce)的结果前4位都是0
3. 客户端规则，不断尝试Nonce=0,1,2,3,4,直到找到满足条件的Nonce

为什么PoW适合验证码场景？

• 对用户友好： 计算过程在后台由 JS 完成，用户几乎无感知，无需任何输入。
• 对机器不友好： 攻击者想发起 1000 RPS (请求/秒) 的并发攻击，他的服务器就需要完成 1000 次 PoW 计算，CPU 会被瞬间打满，攻击成本急剧上升。
• 无任何第三方依赖： 完全自部署，没有隐私泄露风险，不受 Google 等服务在特定区域不可用的影响。
• 动态难度调整： 可以根据 IP、用户行为等动态调整 PoW 的难度，对可疑用户“加码”。

实战：构建一个支持PoW的验证码系统

总结