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

Mr_Q_คิดถึง
  • 51
山东

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

  1. 服务端是否需要返回给客户端一个验证码的id,这样客户端在拿到验证码id 和 验证码后,post提交, 后端通过post来的id、验证码 和 数据库的比对
  2. 服务端不返给客户端id,客户端只提交验证码,服务端直接表中查询时间为最新的验证码进行比对?
回复
阅读 660
1 个回答
然后去远足
  • 35.2k
香港
✓ 已被采纳

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

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

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

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

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

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

撰写回答
你尚未登录,登录后可以
  • 和开发者交流问题的细节
  • 关注并接收问题和回答的更新提醒
  • 参与内容的编辑和改进,让解决方法与时俱进
宣传栏