其他分享
首页 > 其他分享> > 不就是个短信登录API嘛,有这么复杂吗?

不就是个短信登录API嘛,有这么复杂吗?

作者:互联网

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


image.png

经ThoughtWorks洞见(ID:TW-Insights)公众号授权转载

暴力破解


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

image.png

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

故事卡-274:

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


小李看到故事卡中提到,验证码长度只有 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 抓住路过的老罗说:“我不过就是休了两天假,回来之后怎么发现登录这里多了个图形验证码出来?”

image.png

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


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


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


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


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


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


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


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


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


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

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


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


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


尾声


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


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


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


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


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


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

故事卡-274:

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


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



标签:短信,手机号,登录,验证码,用户,API,老罗
来源: https://blog.51cto.com/14410880/2550951