[!info] related notes

• 所属 MOC: 安全 MOC
• Account Recovery: Password Reset & Account Recovery
• Reset Token: Password Reset Token
• Session Revocation: Credential Change & Session Revocation
• MFA: Password 与 MFA 的安全边界

Email Verification & Email Change Security

一句话关系

Email Verification：

证明用户当前控制某个邮箱地址。

它不自动证明：

• 现实世界身份；
• 账户高 assurance；
• 当前 session 一定可信。

Email Change：

修改账户的重要 recovery / communication / identity attribute。

所以风险远高于普通 profile field 更新。

Email Verification

典型流程：

signup → create account pending/unverified → issue verification token → send email → user clicks → mark email_verified_at

Verification token 应：

• random；
• short-lived；
• single-use；
• purpose-bound；
• bound to one account/email value。

不要复用 password reset token。

Verification 不等于 Authentication

用户能点开 verify-email link，只说明当前掌握该邮箱收件能力。

它不等于：

• 已验证 password；
• 已完成 MFA；
• 当前 session 为高 assurance；
• 邮箱拥有者就是某个现实身份。

因此 email verification 与 login authentication 是不同层。

Pending Email

如果用户正在变更邮箱，更稳的数据模型是：

current_email pending_email pending_email_token

流程：

request email change → authenticate/step-up → set pending_email → verify pending_email → atomically promote to current_email

不要在验证新邮箱前直接覆盖旧地址。

Email Change 是高风险操作

修改邮箱可能影响：

• password reset；
• MFA recovery；
• security notifications；
• account lookup；
• billing/contact；
• support verification。

所以通常应要求：

• recent reauthentication；
• current MFA / WebAuthn if enabled；
• confirm new email；
• notify old email；
• security logging。

高风险系统还可要求旧邮箱确认或 cooldown。

Old Email Notification

成功变更后向旧地址发送 security notification。

内容可包括：

• email changed；
• time；
• device/browser context；
• recovery/support instructions。

它提供 compromise detection，不等于旧邮箱必须批准所有变更。

Verification Token 与 Reset Token 分离

错误：

generic_action_token → action=email_verify/password_reset/mfa_reset

这容易造成 confused-deputy、token substitution 或 privilege escalation。

正确方向：

EMAIL_VERIFY EMAIL_CHANGE_CONFIRM PASSWORD_RESET MFA_RECOVERY

不同 action 使用 purpose-bound credential。

Enumeration

注册、忘记密码、邮箱变更的公共响应都要考虑 user enumeration。

例如 signup 可根据业务需要统一为：

如果地址可用于注册，我们会发送验证邮件。

真正是否完全隐藏“已注册”仍要结合产品 UX，但必须显式评估 enumeration trade-off。

Token Delivery

verification link 应：

• HTTPS；
• 使用 trusted configured origin；
• 不依赖不可信 Host header；
• 避免第三方资源导致 referrer leakage；
• 避免日志记录完整 token。

这些原则与 Password Reset Token 一致。

Email Bounces / Stale Addresses

数据库里存在 verified email 不等于用户今天仍控制该邮箱。

高风险 recovery 系统应考虑：

• 长期未使用邮箱；
• bounce；
• domain ownership change；
• shared mailbox；
• compromised mailbox。

Recovery assurance 不能只看历史 email_verified_at。

学习检查

1. Email Verification 能证明什么，不能证明什么？
2. 为什么 Email Change 比普通 profile field 修改风险高？
3. pending_email 模式为什么比直接覆盖 current_email 更安全？
4. old-email notification 提供什么安全价值？
5. 为什么 verification/reset/MFA recovery token 不能复用？
6. email_verified_at 为什么不等于邮箱永远可信？
7. 一个高风险邮箱变更流程应包含哪些 reauthentication / notification 步骤？