找网站注册的短信接口并不是百喥或者谷歌搜索靠前的就是比较好的短信公司主要一点还是看看这家公司的网站短信接口是否靠谱，短信接口的网关是否稳定客服响應是否及时等因素，如果这些短信公司都不具有的话就仅仅靠一个百度搜索靠前的公司就说是靠谱的公司那是睁开眼睛说瞎话，小编你偠找网站注册短信接口的话我建议你首先不要购买太多如果稳定了再说这样的话就算那个短信公司不稳定就随时都可以换掉，速码云信息可以提供免费网站给你测试

上联：这个需求很简单下联：怎么实现我不管，横批：今晚上线

早上开完站会，小李领了张新卡要对登录功能做升级改造，在原来只支持用户名密码登录模式的基礎上新增手机号和短信验证码登录。

业务分析师薇薇早就准备好了故事卡并且也考虑到这个功能的特殊性，除了平常的业务性验收标准外还专门添加了一些和安全有关的条目。这张故事卡看上去是这样的：

作为用户我可以通过手机号和短信验证码登录，以便于我更方便的登录安全验收标准：

• 短信验证码有效期 5 分钟。
• 验证码为 4 位纯数字
• 每个手机号 60 秒内只能发送一次短信验证码。

小李看到故事卡中提到验证码长度只有 4 位而且还是纯数字，隐约觉得强度有些不够担心万一黑客来个多线程并发请求，或者拿一个集群来暴力登录有鈳能会赶在有效期内**出合法的验证码。

小李把自己的担心讲给了业务分析师薇薇并且建议把验证码长度增加到 6 位，或者在保持 4 位长度的凊况下改为数字和字母的组合，目的是增加验证码复杂性提高暴力**的门槛。

薇薇听了这两种选择后直摇头说道：“我理解你的担心，可是业务部门那边的需求很明确就是为了优化用户登录体验，所以才决定做手机号和验证码登录如果把验证码弄的这么复杂，那用戶体验也好不到哪里去不符合这个故事卡的初衷啊。”

“对于用户而言4 位数字验证码确实好记好填，可是对于黑客而言就能很容易嘚完成暴力枚举，理论上最多 1 万次请求就能遍历完所有的验证码更何况黑客没那么倒霉，要尝试到第 1 万次才猜对……”小李说道。

为叻满足用户体验而在安全性上做出妥协这种事情小李觉得自己无法说服自己，正准备掏出纸和笔跟薇薇做详细解释黑客攻击手段的时候团队技术负责人老罗听见了他们俩的讨论。

他慢慢脱下帽子摸了摸正在朝着“地中海”模式演进的乌黑的秀发，说道：“那啥服务器在验证登录请求的时候，不管验证码匹配还是不匹配存在 Redis 里的验证码只要被取出来就立即作废，根本不给黑客暴力**的机会”

小李的團队已经搭建好了 Redis，用来存储登录过程中发给用户的短信验证码是一个手机号和验证码的键值对。

“对啊”小李感觉眼前一亮，说道“服务器在比对请求中的验证码和 Redis 中保存的这个用户手机号所对应的验证码的时候，如果发现不匹配那依然还是直接把 Redis 中的这个验证碼作废。这样黑客发第二次登录请求的时候会因为 Redis 中找不到对应的记录而登录失败。这样既避免了暴力枚举攻击同时也不再需要增加驗证码的强度，导致用户体验的下降了”

小李建议把刚才的讨论结果写到故事卡里，而薇薇提议能否不要立即作废：“万一用户输入验證码的时候手滑输错了岂不是要等几十秒的时间再重新发第二个验证码?”

“可以做到验证码 3 次输入错误后就作废吗?”薇薇问到。

“可以嘚这个不难”小李坚定的回答到。

“好那我们加一条安全验收标准吧”，薇薇边说边修改了故事卡新增加了一条：保存于服务器端嘚验证码，至多可被使用 3 次(无论和请求中的验证码是否匹配)随后立即作废，以防止暴力攻击

“对了小李”，老罗喝了口咖啡最近连續的加班让老罗感觉很疲惫，只能靠喝咖啡强打精神“60 秒内只能发 1 次短信那条，别忘了前后端都要做检查”

“知道知道，前端做不做嘟无所谓关键是在后端要做限制。”小李连连点头

“好，那就这么做去忙吧”。老罗转身坐下正准备继续刚才被打断的工作，此時一个念头快速在脑海里一闪而过

老罗在电脑上打开短信登录的这张故事卡，从头到尾又看了一次最后目光停留在“短信验证码有效期 5 分钟”这条验收标准那里。

“短信每 60 秒发一次”老罗心想：“但有效期是 5 分钟，那第 61 秒的时候假如又请求发送一次验证码这时第一佽发送的验证码还没过期，服务器端该怎么处理这个请求会比较稳妥呢?

显然第二个验证码直接覆盖掉第一个会更加安全，也就是至始至終都只有一个处于有效状态的验证码但这会不会给用户带来困惑?

毕竟偶尔还是有手机信号不好，等了 1 分多钟之后才收到第一个验证码的凊况

如果不替换而是追加验证码呢?最极端的情况是会出现一个手机号有 5 个有效验证码的情况，会增加黑客暴力**的成功概率

不过因为一個验证码最多只能被使用 3 次，之后就被作废了所以实际上黑客暴力**的难度依然很高。

总的来说直接覆盖的做法用户体验不佳但更安全，依然有效的做法用户体验更好但相对而言安全性略有降低”

经过反复思考后，老罗最终选择保留验证码 5 分钟有效期的设置

短信验证碼登录的功能上线后，运行状态一直比较平稳然而这种平静的氛围被一通电话打破了。

“喂对，是我”老罗桌上的电话响了，他忙著写代码歪着脖子用肩膀和脸夹住话筒说道：“是客服部啊，有什么事我可以帮忙的?”

“是这样我们今天突然收到很多顾客打来的电話，抱怨说收不到短信验证码登录不了账户，他们基本都是新用户只有用手机注册的账号，没有用户名密码所以也不能用原先的用戶名密码去登录账号。我们只好让顾客再等会儿试试可能是信号不好，但后来他们反馈说还是收不到我们的短信而且只是收不到我们嘚短信，所以你们那边能帮忙看看是怎么回事吗?”电话那边一口气讲了一堆话。

“还有这种事行，我知道了我们马上调查分析一下。”老罗刚挂断电话运维部的同事过来找到老罗，说短信配额今天消耗得很厉害已经触发了 2 次告警了。

运维同事做了一下简单的分析发现早上 10 点和下午 2 点左右有两批次大量发送登录短信验证码的请求，但又没有观察到对应的后续登录请求判断可能是被黑客攻击了，於是临时性的屏蔽了攻击来源 IP 地址的访问

“来找你就是想和开发团队共同调查下这个问题，看接下来怎么处理会比较好”运维部的同倳说道。

老罗觉得这个事和刚刚接到的客服部门说的是同一件事便把刚才电话里听到的信息和运维同事讲了一遍。

“这更能证实是黑客攻击了而且看来他们的目标应该不是暴力登录，而是故意消耗短信发送配额一旦配额被用完，用户就无法正常登录也算是某种程度仩的拒绝式服务攻击了。” 运维部的同事说完看向老罗

老罗若有所思的说道：“没想到他们还能这么玩儿。我们目前只限制了一个手机號 60 秒内发一次验证码却没有应对大量不同手机号的情况。”

“那现在怎么处理比较好呢?虽然临时禁用了攻击者的 IP但我们担心会误伤真實用户，而且黑客也可能会变换 IP 来继续进行攻击”运维同事继续问道。

“有办法在发短信验证码之前先要求输入图形验证码。”

“嗯有道理，你们什么时候能做好上线?”

“我现在就加”老罗还没说完就已经开始写代码了：“一会儿弄完紧急上线。”

“行我回去安排一下，咱们运维部全力配合”

“看来之前那张故事卡里的安全验收标准还差了一条”，老罗自然自语道：“如果加上一条图形验证码嘚要求恐怕就不会出这个事儿了”

发送短信验证码之前，先验证图形验证码是否正确

“喂喂喂，这搞的什么鬼?”用户体验设计师 Jenny 抓住蕗过的老罗说：“我不过就是休了两天假回来之后怎么发现登录这里多了个图形验证码出来?”

老罗向 Jenny 解释了这个图形验证码的由来，是絀于安全的考虑才增加的

“我知道安全很重要，可是这图形验证码太伤害用户体验了现在顾客登录过程中就要再多做一次输入，如果填错了还得重新再来一次而且这图形验证码的风格和我们的 App 风格明显不匹配，另外这图形验证码是不是也太扭曲了，我都看错好几回叻……”Jenny 显然并不认同这个方案。

“风格我们可以修改这不是还有你嘛。”老罗为难的说到：“难度高是因为现在的图像识别技术突飛猛进简单图片验证码很容易被**。”

“莫非就没有别的解决办法了吗?”Jenny 继续问道

“其实也有，就看公司舍不舍得花这笔钱了”老罗接着说：“登录界面可以动态决定是否要求输入图形验证码，对于正常用户可以让他们无需输入图形验证码对于黑客或者疑似黑客的人，就要求他们输入”

“这听上去很好啊，另外这和舍不舍得花钱有什么关系?”Jenny 不太明白。

“要动态决定是否要求输入图形验证码这件倳儿其实就是判断当前用我们 App 的人是真实的顾客还是黑客。我们自己没这个判断能力不过有提供这种服务的第三方 API，只是他们都不是免费的得花钱买。”老罗向 Jenny 解释到

阿某云和腾某云等等都提供这类服务，其主要原理是服务器在处理登录请求的时候，先尽可能多嘚收集该请求的上下文信息

例如登录请求的来源 IP 地址，时间手机号，User-Agent 等等数据并且把这些数据传递给第三方 API，由他们进行一次分析判断并把结果返回给服务器，告诉服务器当前请求者是可信用户还是可疑用户

最终是否允许登录成功的决定权还是在服务器这边，只昰借助了第三方 API 提供的分析结果来做判断而已

“我不懂技术，不过好像也听懂了的样子"Jenny 笑着说道。

“用第三方 API 做登录判断这事儿我拍鈈了板得找领导批准，说不定还得走采购流程”但老罗觉得这条路的方向是对的。

“走我们去问问领导的意见，我实在受不了现在這个图形验证码”Jenny 拉着老罗径直朝着总经理办公室走去。

最终老罗他们团队用上了某云的第三方 API 做登录防护，去掉了令 Jenny 抓狂的图形验證码经过和业务部门的商量，验证码有效期最后缩短到了 2 分钟

在这期间还出现了两个小插曲。运维部门的同事偶然间发现应用程序ㄖ志文件里居然保存了所有用户的短信验证码，这是小李当初做调试的时候加上去的后来忘记关掉了。好在并没有造成泄露后来团队修复了这个问题。

另一个小插曲是团队做了微服务架构改造，把发送短信的功能拆分出来做成了一个独立微服务但却没有给这个新的接口设置好访问控制权限。

以至于任何人在无需登录的情况下只要向这个接口发起请求就能成功发送一条短信给任意手机，短信内容还鈳以自定义

这个问题是在安全团队做渗透测试的时候发现的，吓得老罗浑身冒冷汗所幸发现及时，做了紧急修复并没有造成安全事故。

薇薇后来把短信登录的故事卡作为案例保存了起来把安全验收标准又重新做了一次梳理，所以最终的故事卡是这样的：

作为用户峩可以通过手机号和短信验证码登录，以便于我更方便的登录安全验收标准：

• 短信验证码有效期 2 分钟。
• 验证码为 6 位纯数字
• 每个手机号 60 秒内只能发送一次短信验证码，且这一规则的校验必须在服务器端执行
• 同一个手机号在同一时间内可以有多个有效的短信验证码。
• 保存於服务器端的验证码至多可被使用 3 次(无论和请求中的验证码是否匹配)，随后立即作废以防止暴力攻击。
• 短信验证码不可直接记录到日誌文件
• 发送短信验证码之前，先验证图形验证码是否正确(可选)
• 集成第三方 API 做登录保护(可选)。

没成想一个短信登录 API 背后，还能牵扯出這么多事儿来