当咱们谈论验证码时，咱们到底在谈论什么？

前言：

现现在登陆用手机验证码登陆是愈来愈常见了。虽然会增长成本，不过对用户体验的提高仍是颇有帮助的。那么，当产品经理对开发说，来按照这个原型给我搞个短信验证码登陆的时候。咱们做为研发，应该想些什么？

短信登陆要作的事情

这里的图只展现了一次成功的流程。还有不少细节值得展开讲下。除了短信验证的流程之外，登陆的安全性也必需要考虑到。尤为是比较重要的后台项目。
下面我就想图中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