[!info] related notes

• 所属 MOC: 安全 MOC
• MFA: 多因素认证（MFA）
• MFA Methods: MFA 方式的安全边界
• Password Policy: Password Policy
• Attack Model: Credential Stuffing / Spraying / Brute Force
• Throttling: Authentication Throttling & Account Lockout
• WebAuthn: WebAuthn, Passkey

Password 与 MFA 的安全边界

一句话关系

Password：

something you know

MFA：

在 password 之外再要求一个独立 factor，例如：

• something you have；
• something you are。

因此 MFA 的主要价值是：

即使 password 已泄漏，攻击者仍不能只凭 password 完成认证。

两个知识因素不等于 MFA

例如：

password + security question

两者都是：

knowledge factor

所以不能因为“输入两次秘密”就叫 multi-factor。

同理：

password + PIN

如果两者都只是服务器验证的知识秘密，也不自动形成真正的独立 factor。

Password + TOTP

典型：

password → valid

TOTP → valid

→ authenticated session

它可以有效降低：

• credential stuffing；
• password reuse；
• 单独 password 泄漏；

带来的直接 account takeover。

但 TOTP code 可以被实时 phishing 转发。

因此：

MFA ≠ phishing resistance。

Password + WebAuthn

WebAuthn / security key 可以通过：

• origin binding；
• public-key challenge-response；
• authenticator possession；

显著提高 phishing resistance。

这和：

password + 6-digit OTP

不是同一安全能力层级。

详见 MFA 方式的安全边界。

Passkey

Passkey 可以作为：

• passwordless authentication；
• 或更强的 cryptographic authenticator。

它不一定意味着：

password + passkey

两个独立 UI 步骤。

现代认证系统可以直接从 shared-secret password model 转向 phishing-resistant public-key credential。

MFA 不会让弱 Password 变强

如果用户 password 是：

Password123!

即使 MFA 开启：

• 这个 password 仍然容易被 stuffing；
• 仍可能泄漏；
• 仍可能被用于 recovery/social engineering；
• MFA disable/reset 可能成为攻击点。

所以：

MFA ≠ 可以忽略 password policy

只是 password 的最低长度要求在 MFA 场景下可以与 single-factor 场景不同。

MFA 与 Rate Limiting

即使有 MFA，也需要限制：

• password guessing；
• OTP guessing；
• push notification spam；
• recovery-code attempts。

例如 6-digit OTP 只有 1,000,000 种可能。

如果没有 attempt limit：

OTP security → rapidly collapses under online guessing

所以 rate limiting 是 authenticator 的独立安全边界。

MFA Fatigue

Push MFA 如果设计成：

Approve? Approve? Approve?

攻击者可以连续轰炸用户。

防御：

• number matching；
• context display；
• push rate limiting；
• suspicious login detection；
• user reporting。

所以“Push = MFA”并不代表交互设计自动安全。

Recovery 是最常见薄弱点之一

如果：

password + WebAuthn → very strong

但：

forgot MFA → email link → disable all factors

那么真正系统强度可能由 recovery flow 决定。

必须审查：

• MFA reset；
• lost-device recovery；
• backup codes；
• helpdesk override；
• organization admin recovery。

Step-Up Authentication

不一定每次操作都需要最高级认证。

可以：

normal session → low-risk read

high-risk action → require recent WebAuthn / MFA

例如：

• 改密码；
• 改 MFA；
• 导出数据；
• 发起大额支付；
• 创建 API key。

这叫 step-up authentication。

Adaptive MFA

风险信号例如：

• new device；
• impossible travel；
• bad IP reputation；
• credential stuffing detection；
• unusual browser；
• high-value action；

可以触发额外 factor。

但 risk engine 不能成为唯一认证因素，因为：

• device fingerprint 可伪造；
• IP 可变；
• anomaly detection 会误判。

MFA 与 Session

MFA 通过后通常形成一个新的 session assurance state。

例如：

session: user authenticated mfa_verified_at authn_method assurance_level

高风险操作可以检查：

MFA 是否足够新鲜？

而不是只看：

user once used MFA months ago。

MFA 与 Passwordless

MFA 的长期方向并不一定是：

password → OTP → more OTP

更强设计可能是：

passkey/WebAuthn → phishing-resistant public-key authentication

从根本上减少 shared-secret password 风险。

常见误区

两个密码 = 2FA

错误。factor type 必须独立。

有 MFA 就不需要 password rate limit

错误。

TOTP = phishing resistant

错误，可被实时代理。

MFA reset 只是客服流程

错误，它属于核心 authentication security boundary。

Passkey 只是更方便的 OTP

错误。它是 public-key credential model。

学习检查

1. 为什么 password + security question 通常不算真正 MFA？
2. MFA 主要降低 password 哪一类单点风险？
3. 为什么 TOTP MFA 仍可能被实时 phishing？
4. WebAuthn 为什么更抗 phishing？
5. MFA 为什么不能替代 Password Policy 与 rate limiting？
6. recovery flow 为什么可能决定整个 MFA 系统的真实强度？
7. step-up authentication 与每次登录强制 MFA 有什么差异？
8. 一个高风险操作应如何利用 session 中的 MFA freshness？