面经策

如何实现一个滑动验证码功能？如何防止被机器识别破解？ ​

  • 标签：后端、系统设计、场景题、安全、人机识别、验证码

🏛 业务架构师 ​

滑动验证码功能设计与防机器破解，我按前端交互 → 服务端判别 → 对抗升级三段讲，并重点讲通过率与拦截率的平衡——这是验证码产品真正的业务难题。

功能实现

前端（采集 + 渲染）

  • 缺口拼图滑块：随机背景图 + 缺口位置，用户拖动补齐
  • 同步采集行为数据：滑动轨迹（每 10ms 采样坐标）、速度曲线、加速度、抖动、按下/抬起事件、总耗时——这些行为数据才是判别的核心，拼图对齐只是表象

服务端（真伪判别）

  1. 先校验缺口位置是否对齐（容差 3~5px）
  2. 行为轨迹分析（核心）：
    • 机器轨迹：匀速直线、无加速度变化、轨迹过于完美或重复
    • 人类轨迹：起步慢-中间快-末端减速修正（Fitts 定律）、有微小抖动
    • 综合评分 + 风控数据（IP 信誉、设备指纹、历史通过率）联动判定
  3. 验证票据一次性：通过后签发短时效 token（一次性、绑定会话），业务接口校验票据——防止验证一次、刷一万次的"验证码复用"

防机器破解（对抗设计）

  1. 对抗轨迹伪造：行为特征随时间更新判别模型（简单规则 → 机器学习），特征集不公开；高级对抗中滑块位置、背景图每次随机
  2. 失败升级策略：滑块失败 N 次 → 升级短信/人脸验证——攻击者能过滑块，过不了短信实名
  3. 参数加密 + 环境检测：采集数据加密上传防伪造；检测自动化工具特征（无头浏览器、JS 环境异常）
  4. 与风控联动：验证码只是入口之一，通过后的行为仍持续评分

业务平衡点（架构师差异）

  • 通过率是产品指标：正常用户首次通过率应 > 95%，每次验证码都是转化漏斗的一次泄漏——灰度验证难度与攻击烈度挂钩：平时宽松、被攻击时动态收紧
  • 知名案例参考：谷歌 reCAPTCHA v3 干脆无感打分（不弹窗、只评分），体验与安全的极致平衡方向是无感验证

收尾：验证码的本质是给"证明我是人"定价——定价太贵（难）伤真实用户，太便宜（易）防不住机器，动态定价是运营出来的，不是上线时定死的。

🏗 系统架构师 ​

滑动验证码要两端看：功能实现 + 防破解对抗，我按交互流程、技术实现、攻防升级讲。

1. 功能实现（交互流程）

text
1) 服务端生成：底图 + 缺口图 + 缺口位置(x)
   - 缺口位置随机；下发"底图 + 打乱/加密的拼图"，缺口坐标只存服务端（Redis，token 关联）
2) 前端：canvas 渲染底图与滑块，监听 pointer 事件采集轨迹
3) 用户拖动滑块到缺口，前端提交：轨迹序列 + 最终偏移量 + token
4) 服务端校验：偏移误差 ≤ 容差(±3px) 且 轨迹像人 → 通过，发一次性票据
5) 业务接口凭票据放行（票据一次性、短时效，防重放）

2. 防机器破解（核心难点） 攻击手段与对应防御：

  • 轨迹模拟攻击（脚本生成贝塞尔曲线轨迹）：防御点在轨迹特征分析——人类轨迹有起始犹豫、中途抖动、末端减速修正（速度方差、加速度曲线、微回退），机器生成的轨迹统计特征过于"光滑"或过于"随机"；用轨迹熵、加速度分布建模判别
  • 图像识别攻击（OCR/CV 找缺口位置）：防御点是增加识别难度——底图加噪点、渐变、扭曲变形；缺口边缘做模糊化处理（传统边缘检测失效）；2026 年必须假设攻击者有强大的 CV 模型，单纯图像难度已不够，重心移到行为与设备信号
  • 打码平台人工过验证：防御靠频率与成本控制——同一 IP/设备/账号触发验证码次数限制，被打码的账号在后续业务层（见风控）再拦截；验证码只是过滤器不是终点
  • 重放与外挂：票据一次性 + TTL 60 秒 + 绑定会话指纹

3. 我的架构建议

  • 验证码服务无状态化 + Redis 存挑战状态，扛洪峰
  • 无感验证优先：先采集行为静默打分（鼠标移动、页面停留、环境特征），分数够直接放行（95% 用户无感），可疑才弹滑动——体验与安全平衡
  • 失败次数升级：滑动失败 3 次升级点选汉字/算力证明（PoW），成本阶梯化
  • 与设备指纹、IP 信誉联动，验证码是风控的一环而非孤立功能

💻 全栈开发专家 ​

滑动验证码的本质是**"人能做对缺口位置 + 人的轨迹像人"**两道判断，缺一不可。

实现流程

1. 服务端生成题目

  • 随机背景图 + 随机 x 位置抠出缺口，生成两张图（背景图带洞、滑块拼图），同时把正确位置、题目 ID、过期时间存 Redis（2 分钟过期，一次性）。
  • 下发图片 + 加密 token（题目 ID 签名防伪造），不下发正确答案。

2. 前端拖拽上报

json
{ "token": "题目ID签名", "x": 218,
  "track": [[0,0,3],[2,1,45],[5,0,80]...],   // x偏移,y偏移,时间戳ms
  "costMs": 1240 }

3. 服务端三重校验

java
// ① 位置容差（设备分辨率换算后）
if (Math.abs(x - answer) > 5) return fail();
// ② 时间合理性：0.5s < cost < 10s，太快是脚本、太慢是人工对答案
// ③ 轨迹行为分析（核心防破解）
double entropy = analyze(track); // 见下
if (!humanLike(track)) return fail();
// 通过：Redis 删除题目（一次性），签发一次性 ticket，业务接口凭 ticket 放行

防机器破解的关键：轨迹行为分析

人类轨迹特征：起步慢—加速—接近缺口减速微调、y 轴有自然抖动、速度曲线是平滑包络；机器常见破绽：匀速直线、三角形速度、y 恒为 0、逐像素等步长。用规则（加速度方差、停顿次数）+ 轻量模型（轨迹序列分类）双重判断。

工程要点与坑

  • ticket 一次性且短时效（30s），业务接口验证后立即失效，防拿到 ticket 重放。
  • 失败次数限制：同一指纹连错 5 次锁 10 分钟，防暴力枚举缺口位置（容差 5px 时暴力成本也要算清）。
  • 图片要防 OCR 对齐：随机噪声、随机旋转、背景图随机裁剪。
  • 生产建议接极验/阿里验证码自研成本高，但原理必须懂——风控联动：验证码通过率、轨迹熵异常量都要监控。