密码尝试次数限制与无安全漏洞的账户禁用方案探讨

• 不要单独做禁用接口，直接在/login接口内处理锁定逻辑
  完全没必要搞无认证的/api/disable-account/{username}接口，所有失败次数统计和账户锁定操作都嵌在登录请求里：每次用户登录失败时，先查该用户当前的失败次数，不足4次就累加计数，第5次失败直接把isActive设为false，同时重置失败次数。这样攻击者想锁定账户必须发起真实的登录请求，没法批量遍历用户名直接调用禁用接口。

• 用用户+IP的复合限流，搭配时间窗口
  只靠IP限流确实容易被绕，但可以同时做两层限制：

  • 单用户维度：比如15分钟内最多允许5次登录失败，次数存在数据库的用户表字段（比如failed_attempts、last_failed_time）或者Redis缓存里；
  • 单IP维度：限制单个IP每分钟最多发起20次登录请求，防止攻击者用同一个IP批量扫用户名，或者用大量IP暴力破解单个用户。

• 给锁定加解锁机制，别搞永久锁定
  永久锁定等于给攻击者送了批量DoS的武器，必须加解锁逻辑：

  • 自动解锁：锁定1小时后自动把isActive改回true，同时清零失败次数；
  • 手动解锁：用户通过邮箱/短信验证码验证身份后，自主解锁账户，这个流程要复用已有的身份验证链路，确保只有本人能操作。

• 模糊登录失败的返回信息
  不管是用户名不存在、密码错了还是账户被锁，统一返回“用户名或密码错误”，别泄露任何账户状态细节。这样攻击者没法通过返回值判断哪个用户名是有效的，自然没法针对性地发起锁定攻击。

• 加日志监控和异常告警
  把所有登录失败请求的用户名、IP、时间都记下来，设置告警规则：比如某个IP10分钟内试了50个不同用户名，或者某个用户1分钟内失败5次，立刻告警，运维能及时介入处理异常。

内容的提问来源于stack exchange，提问作者Grahem Cuthbertson