[!info] related notes

• 所属 MOC: 安全 MOC
• Reset Token: Password Reset Token
• Password Policy: Password Policy
• Password Storage: Password Storage & Verification
• MFA Recovery: MFA Recovery Codes
• Session Revocation: Credential Change & Session Revocation
• Email: Email Verification & Email Change Security

Password Reset & Account Recovery

一句话模型

Password Reset 不是：

知道 email → 改密码

而是：

request recovery → prove control through approved recovery channel/authenticator → enter restricted recovery state → set new credential → revoke affected sessions/authenticators → require normal reauthentication

它是一个独立 authentication protocol。

为什么 Recovery 是高风险路径

如果主登录很强：

password

• MFA
• rate limit

但恢复流程只是：

email → weak link → disable MFA → set new password

那么整个账户真实安全强度由 recovery flow 决定。

所以：

Account Recovery 的 assurance 不能低到让攻击者轻易绕过主认证。

Step 1：Request

用户提交：

email / username

服务端必须返回统一公共响应：

If the account exists, recovery instructions will be sent.

不能区分：

• account exists；
• account missing；
• disabled；
• locked。

还要尽量避免显著 timing difference。

防 Recovery Bombing

攻击者可以不断提交 victim email：

forgot password → thousands of emails

造成：

• inbox flooding；
• user confusion；
• social-engineering cover；
• email provider reputation issues。

所以 request endpoint 应有：

• per-account rate limit；
• per-source rate limit；
• global abuse detection；
• CAPTCHA/risk challenge when needed。

但不要因为 reset request 就直接锁 victim account。

Step 2：Issue Recovery Credential

最常见是 URL token。

要求：

• cryptographically random；
• enough entropy；
• bound to one account/purpose；
• short lifetime；
• single use；
• securely stored server-side；
• rate-limited verification。

详见 Password Reset Token。

Step 3：Restricted Recovery State

用户点击合法 token 后，不一定要立刻直接执行任意账户操作。

更安全的模型：

valid reset token → restricted recovery session → only allowed: set new password maybe bind recovery factor

不能让该 token 获得：

• account export；
• payment；
• API key creation；
• arbitrary profile change。

Recovery token 是 purpose-bound credential。

Step 4：New Password

新 password 必须执行正常：

Password Policy

包括：

• length；
• blocklist；
• no silent truncation；
• normal password verifier storage。

不能因为是 reset flow 就降低 policy。

Step 5：Credential / Session Consequences

Password reset 往往意味着旧 credential 可能已失去可信性。

可以考虑：

• revoke current refresh families；
• revoke server-side sessions；
• rotate credential version/security stamp；
• invalidate remembered-device trust；
• require MFA rebind only when justified；
• notify user。

具体见 Credential Change & Session Revocation。

不要自动登录

OWASP 建议 password reset 后：

set password → success notification → normal login

而不是：

set password → silently issue long-lived authenticated session

这样能减少 recovery-specific code 与 session issuance 耦合。

User Notification

成功 reset 后应向已登记 channel 发送通知：

• password changed；
• time；
• device/IP context if appropriate；
• what to do if not initiated by user。

通知里不发送 password。

Security Questions

Security questions 不能作为 sole recovery mechanism。

问题包括：

• public/social information；
• low entropy；
• reused answers；
• guessable；
• hard to normalize securely。

NIST 已不接受 KBA/security-question model 作为数字认证核心 secret。

Recovery Channel 不是绝对可信

Email/SMS recovery 的真实 assurance 受以下因素限制：

• mailbox compromise；
• SIM swap；
• email forwarding；
• stale address；
• shared inbox；
• helpdesk social engineering。

高风险系统应根据 assurance 要求设计多因素 recovery 或人工 proofing。

Recovery 与 MFA

如果账号启用 MFA：

password reset ≠ automatically disable MFA

MFA reset/recovery 是另一条高风险流程。

详见 MFA Recovery Codes 与 Password 与 MFA 的安全边界。

Recovery 与 Session

完成 recovery 后：

old session → 是否还能继续高权限操作？

必须明确。

对高安全系统，通常应撤销或降级旧 session assurance，避免攻击者手里的既有 session 绕过 credential reset。

常见错误

Request reset 时直接说“邮箱不存在”

→ account enumeration。

reset request 就锁账号

→ attacker 可制造 DoS。

token 永久有效

→ mailbox history 中旧 token 变长期后门。

token 可重复使用

→ replay。

reset 完直接高权限登录

→ recovery token 被升级成长期 session credential。

reset password 自动关闭 MFA

→ 把恢复流程变成 MFA bypass。

学习检查

1. Password Reset 为什么是独立 authentication protocol？
2. request 阶段为什么必须使用统一响应？
3. Recovery bombing 与 password brute force 有什么不同？
4. recovery token 为什么必须 purpose-bound / single-use / short-lived？
5. 为什么 reset 完不推荐自动生成长期登录态？
6. password reset 与 MFA reset 为什么不应绑成同一个动作？
7. recovery 成功后为什么要重新评估 session / refresh token？
8. 设计一个“邮箱恢复 + 已开启 WebAuthn”的账户恢复流程。