手机验证码业务,如何知道输入的验证码是本次的?

Question

手机验证码业务,发送验证码后,验证逻辑该为哪种?

1. 服务端是否需要返回给客户端一个验证码的id,这样客户端在拿到验证码id 和 验证码后,post提交, 后端通过post来的id、验证码 和 数据库的比对
2. 服务端不返给客户端id,客户端只提交验证码,服务端直接表中查询时间为最新的验证码进行比对?

Answer 1

都行。但验证码肯定是得分场景（Scene）的，你不能拿着新用户注册时的验证码去访问老用户忘记密码的接口，这是两个场景。

不过一般上而言的话是第一种，但并不是返回给前端验证码的 ID，而是类似票据 Ticket 之类的东西。因为发短信这个东西还有一个很重要的非业务需求，那就是防盗刷 —— 所以还需要一个“前置”的玩意儿，通常而言就是那种 Captcha 人机验证码（看图输入随机字符、拖拽滑块、字符点选、拼图 balabala 等等）。

所以一次短信验证的流程应该是：

1. 客户端发起请求，服务端返回一个令牌（Token）+ 对应的 Captcha 信息，该令牌标识本次会话。
2. 客户端携带第一步返回的 Token + 用户填写的内容（这里的填写不一定是字面意思上的填写，比如滑块式的填写实际就是滑动轨迹等信息了）发送请求，如果验证通过，服务端返回一个票据（Ticket）、并通过短信网关给用户发短信。
3. 客户端携带第二步返回的 Ticket + 收到的短信内容发送请求，如果验证通过，完成本轮会话。

这里提到的 Token、Ticket 均具有唯一性要素（不一定非得是永久全局唯一，一段时间内是唯一的就可以了，因为你的短信验证码也不会是永久有效的嘛），可以唯一地标识本次会话。

在此基础之上你还可以扩展一些其他的安全策略，比如同一个 Token/Ticket 可以尝试验证的最大次数不得超过一定次数之类的，超过了就必须从第一步从头来，以防暴力破解。