[!info] related notes

• 所属 MOC: 安全 MOC
• Attack Model: Brute Force、Password Spraying 与 Credential Stuffing
• Password Policy: Password Policy
• MFA: Password 与 MFA 的安全边界
• Generic Rate Limiting: Go 限流
• BodySense Course: BodySense Redis Rate Limiting

Authentication Throttling & Account Lockout

一句话关系

Authentication Throttling：

限制攻击者单位时间能尝试多少次认证。

Account Lockout：

在达到某种风险/失败状态后，暂时或持续禁用某个 authenticator/account login path。

二者相关，但不是同一个机制。

为什么必须 Account-Level

如果只按 source IP：

attacker → thousands of proxy IPs → same account

就能绕过限制。

因此 NIST 要求 verifier 有效限制：

single subscriber account 上的 failed authentication attempts。

OWASP 也明确建议 failed-login counter 应关联 account，而不只是 source IP。

但也不能只看 Account

Password spraying：

one IP/device → hundreds of accounts → each account only 1-2 failures

可能完全避开 per-account threshold。

因此真实系统通常组合：

• per-account；
• per-IP；
• per-device；
• subnet/ASN；
• global；
• account × source pair。

Progressive Delay

与固定“第 5 次锁 30 分钟”相比，可以：

failure 1 → normal

failure 2 → 500 ms delay

failure 3 → 1 s

failure 4 → 2 s

failure 5 → additional challenge

这能：

• 提高自动化成本；
• 减少一次误输就产生强摩擦；
• 降低锁号 DoS 风险。

Exponential Lockout

另一种策略：

short lock → repeated failures → longer lock

例如逐步从秒级扩展到分钟级。

重点不是具体数字，而是：

攻击成本随失败累计增加，同时给真实用户保留恢复路径。

固定 Account Lockout 的 DoS 风险

如果：

5 bad attempts → lock victim account 24h

攻击者只需要知道 username，就能持续让受害者无法登录。

因此 lockout policy 必须考虑：

• threshold；
• observation window；
• duration；
• unlock/recovery；
• attacker-triggered DoS；
• notification。

NIST 100 Attempts 是上限，不是推荐值

NIST SP 800-63B-4 对通用 authenticator 给出的 100 consecutive failed attempts 是：

upper bound。

机构可以设置更低限制。

它不意味着：

每个应用都应该允许 99 次 password 尝试。

实际阈值仍要基于：

• authenticator strength；
• rate limiting；
• MFA；
• risk；
• usability/recovery。

Lock Authenticator vs Lock Entire Account

如果 password authenticator 达到限制，可以考虑：

password login disabled

但不要自动导致：

• 已建立 session 全部失效；
• Passkey 也不可用；
• recovery channel 不可用；

除非 threat model 明确需要。

更细粒度模型：

account ├─ password authenticator ├─ passkey ├─ TOTP └─ recovery

可以只限制被攻击的 authenticator。

CAPTCHA

CAPTCHA 可以在：

risk/failure increases → require CAPTCHA

提高 automation 成本。

但 CAPTCHA：

• 可被破解；
• 可 outsourced；
• 有 accessibility 成本。

所以它是辅助控制，不是主防线。

MFA Step-Up

如果检测到：

• new device；
• bad IP reputation；
• many-account scanning；
• impossible travel；
• scripted behavior；

可以：

password valid → require MFA / WebAuthn step-up

而不是直接永久锁账号。

429 vs Authentication Error

通用 API rate limit 常返回：

429 Too Many Requests

登录系统还要考虑：

响应是否泄露 account existence 或安全状态。

公共响应不一定需要把：

account locked username unknown password wrong

精细区分给未认证客户端。

内部日志和 metrics 仍应区分。

Counter Reset

成功登录是否完全清零失败风险状态，要谨慎。

攻击者可能：

• 先获得一次正常 session；
• 在已知 credential 下操控 reset。

可以区分：

• consecutive failed count；
• historical risk signal；
• device trust；
• fraud score。

不要把一个 counter 当作完整 risk engine。

分布式系统

多实例 Auth API：

instance A instance B instance C

如果每个实例只在本地内存计数，攻击者可以得到近似实例数倍的额度。

所以认证 throttling 通常需要：

• shared Redis/state；
• gateway；
• dedicated risk service。

Fail Open / Fail Closed

Rate-limit storage 故障时：

Redis unavailable

应该：

allow all？ deny all？ local fallback？

认证接口属于高安全敏感路径，但完全 fail closed 也可能造成全站登录事故。

应显式定义：

• degraded local limit；
• cached policy；
• circuit breaker；
• emergency policy。

学习检查

1. Authentication Throttling 与 Account Lockout 的差异是什么？
2. 为什么 login failure counter 必须至少包含 account 维度？
3. 为什么只做 account counter 仍挡不住 password spraying？
4. 固定强锁定为什么能被攻击者用来 DoS？
5. NIST 的 100 attempts 为什么不能理解成“推荐允许 100 次”？
6. progressive delay 与 fixed lockout 的主要 trade-off 是什么？
7. 为什么可以考虑锁某个 authenticator，而不是整个 account？
8. 多实例服务为什么通常需要共享 throttling state？