当我们谈论验证码时,我们到底在谈论什么?

·  阅读 110

前言:

现如今登录用手机验证码登录是越来越常见了。虽然会增加成本,不过对用户体验的提升还是很有帮助的。那么,当产品经理对开发说,来按照这个原型给我搞个短信验证码登录的时候。我们作为研发,应该想些什么?

图片来源知乎短信登录截图

短信登录要做的事情

短信登录时序图

这里的图只展示了一次成功的流程。还有很多细节值得展开讲下。除了短信验证的流程以外,登录的安全性也必须要考虑到。尤其是比较重要的后台项目。 下面我就想图中17个步骤拆开分析

请求获取验证码(1~4)

1~4步主要的点有两个。

  1. 前端对手机号的格式验证,按钮多次点击的验证
  2. 后端对请求验证码的频率的限制

验证规则可以宽松一点。虽然前端的验证并不可靠,但是不代表前端的验证没有用。同时,当点击了获取验证码后需要将验证码的按钮禁用,防止多次点击 后端的部分则需要判断当前ip,当前手机号是否是重复请求验证码。这里就需要引入重复请求验证码的规则。一般的规则是60秒内可以再次请求。这个时间可以通过记录一条键名为请求手机号的一条缓存,过期时间为60秒。如果可以拿到值,则说明还没有到60秒再次请求。

验证合法性(5~8)

5~8步主要是验证手机号背后的用户的合法性 首先手机号的格式是必须要判断的,虽然前端有判断。但是后端的验证才是可靠的验证。后面就是通过手机号查库。查询的逻辑主要为

  1. 注册用户中是否有这个手机号
  2. 该用户状态是否为禁用
  3. 该用户权限是否可以登录当前业务

如果条件满足就可以进行下一步了

制作/存储验证码(9~10)

制作验证码,就必须考虑两个问题,1是验证码的长度 2是验证码的复杂度 对用户最友好的当然是纯数字,验证码越短越好。但是这样对安全性就大打折扣。有没有又对用户友好,又安全的方案呢? 答案是有的。 首先我们假定使用4位数字的方案。如果不设置尝试次数的限制的话,黑客使用多线程工具,在短时间内进行暴力枚举最多1万次就能穷举出所有的可能,而且运气也不一定会这么差。有可能在3000次的时候就试出来了。 那么我们的解决方案就是。同一个手机号,验证三次。就将验证码失效。在3次失败后,第四次请求,就返回错误文案 “验证码连续错误三次,请重新获取短信验证码” 还有一个需要思考的维度。那就是短信验证码的有效期。一般来说,短信验证码会有5分钟的有效期。这里就会有一个交叉的问题。比如一个用户获取到了一个验证码而不去验证,过了60秒又去获取一次。他就会有两个有效的验证码。这样明显是不合理的,那么我就需要在获取第二次验证码的时候废弃调第一个验证码。使用缓存存储验证码的时候,直接set就可以将上一个验证码给覆盖掉,还可以重新设置5分钟的有效期。

最后还有一个容易被忽略的问题。那就是短信防刷,我们之前的设置,都只是针对于一个手机号的防刷。还有一种刷短信是不停的更换手机号来刷的那种。解决方案可以通过,ip,ua,referer,header等参数来判断是否是同一个客户端发起的请求。如果是同一个客户端在一个小时内请求超过了5次。就必须输入一个图形验证码。图形验证码的实现就不用多说了。太多可以直接用的包。这样的话可以最大限度的防止别人对我们的系统进行攻击,同时也保障了体验不打折扣

发送验证码给用户(11~12)

这步就比较简单了。只需要按照SMS的接口文档,传入手机号,短信模版,验证码就可以发送了。可以考虑增加一个日志记入数据库,用作数据分析。

验证登录,登录成功(15~17)

验证登录这步主要是要完成之前提到的。验证3失败3次废弃验证码(无论是否匹配),验证通过后也要废弃验该验证码。同时验证码通过之后还是需要再次验证用户的合法性。防止比较极端的情况,比如请求验证码的时候用户是合法的,但是在5分钟之内用户被禁用了。这样的话还是不能让他登录。 登录成功的话就看自己的架构设计了。可以是token令牌也可以是session会话。建立会话之后,就算完成了一次完整的短信验证码登录了!~

总结

短信验证码总结

总结完成之后,就可以按照要求进行开发了。虽然是一个简单的短信验证码,但是我发现市面很多的项目,这一块都没有做好(别问我,我怎么知道 哈哈哈)我们作为研发人员,一定要尽可能的考虑周全,以免出现线上事故。

微信公众号:RichardTalked

分类:
后端
标签: