上联：这个要求很简单，下联：我不管怎么实现，恒彪：今晚上线。经ThoughtWorksInsights（ID：TW-Insights）授权公众号授权转载蛮力破解上午的站会后，小李收到一张新卡，想要升级登录功能。在原有只支持用户名和密码的登录方式基础上，增加手机号和短信验证码登录。业务分析师薇薇早就准备好了故事卡片，考虑到这个功能的特殊性，除了通常的在业务验收标准中，她还特意增加了一些与安全相关的项目。这个故事卡片是这样的：StoryCard-274：作为用户，我可以通过手机号和短信验证码进行登录，这样可以更方便的登录。安全验收标准：短信验证码5分钟有效。验证码为4位纯数字。每个手机号码60秒内只能发送一次短信验证码。小李在故事卡片中看到，验证码只有4位，纯数字。他隐约觉得力道不够。他担心万一黑客发起多线程并发请求，或者使用集群暴力登录，可能会被抓到。在有效期内破解有效验证码。小李向业务分析师魏伟分享了他的担忧，建议将验证码的长度增加到6位，或者在保持4位长度的情况下改为数字和字母的组合，以增加复杂度的验证码。性，提高暴力破解的门槛。听到这两个选项，薇薇摇头道：“我理解你的顾虑，但业务部有很明确的需求，就是优化用户登录体验，所以我决定用手机号和账号登录。”验证码。如果验证码这么复杂，用户体验也不会好多少，这不符合这个故事卡片的初衷。”“对于用户来说，4位验证码确实好记好填，但对于黑客来说，暴力枚举就可以轻而易举地完成。理论上，最多10000次请求就可以遍历所有验证码，更不用说黑客也没有那么倒霉，要试一万次才能猜对……”小李说道。为了满足用户体验而牺牲安全，对于这种事情，小李觉得自己说服不了自己，正要拿出纸笔向微微详细解释破解方法，这时技术负责人队伍的尽头，老罗听到了两人的议论声。他缓缓摘下帽子，摸了摸自己正在向“地中海”模式进化的黑发，说道：“嗯，当服务器验证登录请求时，无论验证码是否匹配，都会存入Redis，只要把验证码拿出来，马上就失效了，黑客根本没有暴力破解的机会。小李的团队搭建了Redis，用于存储登录过程中发送给用户的短信验证码，是手机号和验证码。,"服务端在将请求中的验证码与Redis中保存的用户手机号对应的验证码进行比对时，如果发现不匹配，还是直接InvalidateRedis中的验证码。这样，当黑客发出第二次登录请求时，就会因为在Redis中找不到对应的记录而导致登录失败。这样就避免了暴力枚举，不再需要加大验证码强度，导致用户体验下降。”小李建议把刚才讨论的结果写在故事卡片里，微微建议是不是应该作废马上：“万一用户在输入验证码的时候失误输入错误，那不是要等几十秒再发第二个验证码吗？”“输入3次错误验证码就可以作废吗？””薇薇问道。“是的，不难。”小李坚定的回答道。“好，那我们加一个安全验收标准吧。side最多可以使用3次（不管是否和请求中的验证码一致），后面立即作废，防止暴力。“对了，小李”，老罗接过一口咖啡。最近连续加班，让老罗感到非常疲惫，只能靠喝咖啡提神。“60秒内只能发一条短信，别忘了前后端都检查一下。”“我知道，前端做不做不重要，关键是限制后端。”小李连连点头。“好吧，那就这样吧，去忙吧”。老罗转身坐下，正要继续刚才被打断的工作，脑子里飞快地闪过一个念头。老罗在电脑上打开短信登录的故事卡片，从头到尾看了一遍，目光停留在“短信验证码5分钟有效”这个验收标准上。“每60秒发送一次短信，”老罗想，“但是有效期是5分钟，所以如果在第61秒再请求一次验证码，此时发送的验证码还没有过期，服务器应该怎么办？”这样请求是不是更安全一些？显然直接覆盖第二个验证码会更安全，即从头到尾只有一个有效验证码，但是这样会不会给用户造成混淆呢？毕竟偶尔还是有一个手机信号不好的情况，等了1分钟多才收到验证码，如果不是更换而是添加验证码怎么办？最极端的情况是一个有效验证码会有5个手机号，会增加黑客暴力破解的成功概率，但是由于一个验证码最多只能使用3次然后失效，所以黑客暴力破解其实还是很困难的ce开裂。总的来说，直接覆盖的方式用户体验不好但更安全，仍然有效的方式用户体验更好但相对来说安全性略低。”思前想后，老罗最终还是选择了保留验证码5分钟的有效期。变幻莫测短信验证码登录功能上线后，运营状态一直比较平稳，但是这平静的气氛却被一个电话打破了。“你好，是的，是我。”老罗办公桌上的电话响了，他正忙着写代码，歪着脖子把话筒夹在肩膀和脸之间，说道：“是客服部，请问有什么可以帮忙的吗？”“对啊，今天突然接到很多客户的电话，抱怨收不到短信验证码，无法登录账户，基本都是新用户，只有手机注册的账户，没有用户名和密码，所以不能用原来的用户名和密码登录账户，我们只好请客户稍后再试，可能是信号不好，但是后来客户反映还是收不到我们的短信，而且他们就是收不到我们的短信，所以，你们能帮忙看看是怎么回事吗？”电话里一口气聊了很多。“还有这种事，好吧，我知道了，我们马上调查分析。”老罗刚挂断电话，运维部的同事就来找老罗，说今天短信额度消耗太大，触发了2次告警。运维同事简单分析了一下，发现上午10:00和下午2:00左右分别有两批发送大量登录短信验证码的请求，但是没有观察到对应的后续登录请求.判断可能是被黑客盯上了，所以暂时封锁源IP地址的访问。“我来找你，是想和开发组一起调查一下这个问题，看看怎么处理比较好。”一位运维部的同事说。老罗觉得这件事和客服部刚刚接到的一样，就把刚刚在电话里听到的信息告诉了运维同事。“这更能证明黑客是有目标的，看来他们的目标应该不是暴力登录，而是故意消耗短信发送配额，一旦配额用完，用户将无法正常登录。”运维部的同事说完了。看看老罗。老罗若有所思地说：“没想到他们能这么玩，目前我们只限制一个手机号在60秒内发送验证码，还没有处理大量不同的手机号。”手机号码。”是不是比较好处理？虽然暂时禁用了黑客IP，但我们担心不小心伤害到真实用户，黑客可能会更改IP继续。”运维同事继续问道。“有办法求个图验证发送短信验证码前的代码。”“嗯，有道理，你什么时候可以上网？”“我现在就添加”，老罗话音未落就开始写了。一会搞定，赶紧上线。”“好，我回去安排一下，我们运维部会全力配合的。”“看来之前故事卡里的安全验收标准还是一分简而言之。”于说：“如果加上图形验证码的要求，恐怕就不会出现这种情况了。”在发送短信验证码之前，先验证一下图形验证码是否正确。权衡“哎，嘿，这到底是什么东西？”用户体验专家Jennyence设计师拉住路过的老罗说：“我刚休了两天假，回来怎么发现多了一个图形验证码？”老罗向Jenny解释了这个图形验证码的由来，是出于安全考虑才加的。“我知道安全很重要，但是这个图形验证码太伤用户体验了。现在客户必须在登录过程中进行另一次输入。App的风格明显不符，而且验证码图形太失真，我都看错好几次了……”珍妮显然不同意这个解决方案。“我们可以修改样式，但你仍然有它。”老罗尴尬地说：“之所以难度高，是因为现在的图像识别技术突飞猛进，简单的图片验证码很容易被破解。“没有别的办法了吗？”珍妮继续问。“其实是有的，就看公司愿意花钱了。”老罗接着说：“登录界面可以动态判断是否需要输入图形验证码。对于普通用户来说，不需要输入图形验证码。对于黑客或疑似黑客，则需要输入进入。”“听起来不错，再说了，这跟舍不得花钱有什么关系？”珍妮不太明白。的人是真正的客户或黑客。我们自己没有能力做出这种判断，但是有第三方API提供这种服务，但是不是免费的，需要购买。”老罗向Jenny解释道，阿云和腾云都提供这种服务，主要原理是服务器在处理登录请求时，首先尽可能多地收集请求的上下文信息，比如登录请求源IP地址、时间、手机号、User-Agent等数据，并将这些数据传递给第三方API，他们会进行分析判断，并将结果返回给服务器，告诉服务器当前请求者是credible用户仍然是可疑用户，是否允许成功登录的最终决定权还是在服务器端，只是借助第三方API提供的分析结果来判断。“我不懂技术，但我好像懂。”Jenny笑着说。“使用第三方API进行登录判断，我做不了决定。还得征求领导的同意，可能还得走采购流程。“但老罗觉得这条路的方向是对的。”走吧，问问领导的意见，现在的图形验证码我实在受不了。”Jenny拉着老罗直奔总经理办公室。最后，老罗和他的团队使用了某云的第三方API进行登录保护，并且去掉了让Jenny抓狂的图形验证码。在与业务部经过讨论，将验证码的有效期缩短为2分钟，期间发生了两个小插曲，运维部的同事无意中发现，应用日志文件居然保存了所有用户的短信验证码users，这个是小李，我在调试的时候加的，后来忘记关掉了，幸好没有造成泄露，后来团队修复了这个问题。还有一个小插曲就是团队做了微服务架构改造，将发送短信的功能拆分成一个独立的微服务，但是没有为这个新接口设置访问控制权限。这样任何人只要在不登录的情况下向这个接口发出请求就可以成功的给任何手机发送短信，而且短信的内容也可以自定义。这个问题是在安全团队做渗透测试的时候发现的，吓得老罗出了一身冷汗。所幸发现及时，并进行了抢修，没有造成安全事故。薇薇后来将短信登录的故事卡片保存为案例，并重新整理了安全验收标准，所以最终的故事卡片是这样的：故事卡片-274：作为用户，我可以用手机号和短信验证码来登录，方便我登录。安全验收标准：短信验证码2分钟有效。验证码为6位纯数字。每个手机号码在60秒内只能发送一次短信验证码，该规则的验证必须在服务器端进行。同一个手机号码可以同时拥有多个有效的短信验证码。服务器端保存的验证码最多可以使用3次（不管是否匹配请求中的验证码），之后立即作废，防止暴力。短信验证码不能直接记录在日志文件中。发送短信验证码前，先验证图形验证码是否正确（可选）。集成第三方API以实现登录保护（可选）。没想到一个短信登录API背后牵扯的东西那么多。
