Experiencing Credential Stuffing

年初，亲身经历了一次撞库。在检查公司某个网站的后台日志时，发现圣诞节前夕的登录出错日志暴涨。检查了一下，绝大部分是Email错误，然后断定是黑客拿着一堆Email和密码在撞库。

简单统计了一下，网站的日志，超过200万条登录错误数据，一秒大概7～10个请求。第一反映是图形验证码被破解了，而且大概10秒就分析出来。

幸好Nginx有Access Log。请求的行为是，先访问网站主页，再访问登录页，最后调用登录按钮的请求，检查Email密码是否正确。随机挑选了几个相关IP，都是泰国的。由于没有记录User Agent，所以不知道黑客是用什么程序或者爬虫，不能进一步分析并排除相关访问来源。另外，再细心分析，相关的撞库访问记录，都没有访问获取图形验证码。那就是，黑客根本就没有破解验证码。检查了代码，网站登录时，同一Email输入三次密码错误后才要求输入验证码。而黑客是利用一堆IP，输入不用的Email，所以，算是绕过了验证码。

最后，目前的处理是同一IP，登录错误3次后，就需要输入验证码。其实图形验证码也不是想象中那么容易破解，就可以防一防。但是，这不是一劳永逸的。

在V2上跟网友沟通了一下，总结一些方案：

1）升级验证码，采用更强更复杂的验证码。但是复杂的验证码（例如扭曲的字符串），对用户不友好的，所以Google推出了reCAPTCHA v3。reCAPTCHA v3无需用户进行任何操作，Google会分析其行为并打分，让网站程序自己根据评分进行处理。比如评分为0.9则认为是人类，0.4分则要进一步验证之类。

2）登录限制规则。比如过滤掉某些有问题的IP（通过第三方接口判断或网站本身记录），过滤有问题的来源（通过User Agent识别），登录错误若干次后进行限制等等。

3）采用二步验证。包括但不限于手机短信验证码、Email验证链接、Google的身份验证器、WebAuthn标准的方案等等。