密码重置与邮件验证：The Copenhagen Book安全流程实现教程

密码重置与邮件验证：The Copenhagen Book安全流程实现教程

【免费下载链接】copenhagenA basic guideline on implementing auth for the web项目地址: https://gitcode.com/gh_mirrors/co/copenhagen

在当今数字化时代，用户账户安全至关重要。密码重置与邮件验证是保障用户账户安全的核心环节，The Copenhagen Book作为Web认证实现的基础指南，提供了一套完整的安全流程解决方案。本文将详细介绍如何基于The Copenhagen Book实现安全可靠的密码重置与邮件验证功能，帮助开发者构建更安全的Web应用。

密码重置：安全便捷的账户恢复机制

密码重置是用户忘记密码时恢复账户访问的关键功能，一个设计良好的密码重置流程能够在保障安全的同时提供良好的用户体验。

密码重置基本流程概述

密码重置最常见的方法是通过用户的电子邮件地址。用户输入其注册邮箱，系统验证邮箱有效性后，会向该邮箱发送一个密码重置链接。这种方法要求每个用户拥有唯一的电子邮件地址，这一点可以通过邮件验证来确保。

值得注意的是，在发送重置链接之前不需要验证邮箱是否已验证。实际上，当用户重置密码时，你甚至应该将用户的电子邮件地址标记为已验证。此外，当用户重置密码时，应使所有与该用户关联的现有会话失效，以防止未授权访问。

密码重置链接的设计与实现

密码重置流程需要两个页面协作完成：

1. 邮箱输入页面：用户在此页面输入他们的注册邮箱

   https://example.com/reset-password

2. 密码重置表单：用户在此页面输入新密码，这是发送到用户邮箱的链接。URL路径中包含一个密码重置令牌

   https://example.com/reset-password/<TOKEN>

令牌安全最佳实践

• 有效期设置：令牌的有效期应设置为大约一小时，最多不超过24小时
• 存储安全：建议在存储令牌之前使用SHA-256对其进行哈希处理
• 单用途原则：令牌必须是一次性使用的，当用户通过表单发送有效密码后，应立即删除该令牌
• 防重复发送：发送新令牌时使现有令牌失效，或者如果已存在有效令牌则重用该令牌
• Referrer策略：对于包含令牌的任何路径，确保将Referrer Policy标签设置为strict-origin（或等效值），以防止令牌从referer中泄露

如果用户已实现多因素身份验证（例如通过身份验证器应用或WebAuthn），则应在输入新密码之前提示他们使用第二个因素进行身份验证。

密码重置的错误处理策略

当邮箱无效时，你可以选择两种处理方式：

• 明确告知用户邮箱无效
• 保持消息模糊（例如："如果账户存在，我们将发送重置邮件"）

选择哪种方式取决于你是否希望公开邮箱的有效性。有关更多信息，请参见密码认证指南中的错误处理部分。

密码重置的速率限制

任何可以发送电子邮件的端点都应实施严格的速率限制。必要时可以使用验证码（Captchas）来防止滥用。

邮件验证：确保账户归属的关键步骤

如果你的应用程序要求用户电子邮件地址是唯一的，那么邮件验证是必不可少的环节。它可以防止用户输入随机电子邮件地址，并且在实现密码重置功能时，允许用户取回使用其电子邮件地址创建的账户。你甚至可能希望阻止用户访问应用程序内容，直到他们验证其电子邮件地址。

⚠️重要提示：电子邮件地址不区分大小写。建议将用户提供的电子邮件地址规范化为小写。

电子邮件输入验证规则

电子邮件验证复杂且无法使用正则表达式完全验证。尝试使用正则表达式还可能引入ReDoS漏洞。不要过度复杂化，只需遵循以下基本规则：

• 至少包含1个@字符
• @之前至少有1个字符
• 域名部分至少包含1个.，且.之前至少有1个字符
• 不能以空格开头或结尾
• 最大长度为255个字符

子地址处理

一些电子邮件提供商（包括Google）允许用户指定服务器将忽略的标签。例如，拥有user@example.com的用户可以使用user+foo@example.com和user+bar@example.com。你可以阻止包含+的电子邮件，以防止用户使用相同的电子邮件地址创建多个账户，但用户仍然可以使用临时电子邮件地址或创建新的电子邮件地址。切勿从用户输入中静默删除标签部分，因为包含+的电子邮件地址可能只是一个常规的有效电子邮件地址。

邮件验证的两种实现方式

1. 邮件验证码方式

验证电子邮件的一种方法是将服务器中存储的密码发送到用户的邮箱。这种方法相比使用链接有一些优势：

• 用户越来越不愿意点击链接
• 某些过滤器可能会自动将包含链接的电子邮件分类为垃圾邮件或网络钓鱼
• 如果用户希望在无法访问验证消息的设备上或无法打开链接的设备上完成验证过程，使用验证链接可能会带来麻烦

验证码安全要求：

• 如果是数字验证码，至少8位；如果是字母数字验证码，至少6位
• 对于安全流程（如创建新账户或更改联系信息），应使用更强的验证码
• 避免同时使用小写和大写字母
• 可以考虑移除容易误读的数字和字母（0、O、1、I等）
• 必须使用加密安全的随机生成器生成

验证码使用规则：

• 单个验证码应绑定到单个用户和电子邮件
• 每个验证码的有效期至少为15分钟（建议在1-24小时之间）
• 验证码必须是一次性的，验证后立即失效
• 每次用户请求另一封邮件/验证码时，应生成新的验证码
• 必须基于用户ID实施节流或速率限制，一个合理的限制是每小时约10次尝试
• 用户验证电子邮件后，所有会话都应失效

2. 邮件验证链接方式

另一种验证电子邮件的方法是使用包含长随机单用途令牌的验证链接：

https://example.com/verify-email/<TOKEN>

验证链接安全要求：

• 单个令牌应绑定到单个用户和电子邮件
• 令牌应该是一次性的，验证后立即从存储中删除
• 令牌的有效期至少为15分钟（建议在1-24小时之间）
• 当用户请求另一封验证电子邮件时，如果该令牌仍在有效期内，你可以重新发送之前的令牌，而不是生成新令牌
• 对于包含令牌的任何路径，确保将Referrer Policy标签设置为strict-origin（或等效值），以防止令牌从referer中泄露
• 电子邮件验证后，所有会话都应失效（并为当前用户创建一个新会话，以便他们保持登录状态）

电子邮件地址更改流程

当用户更改电子邮件地址时，应要求他们输入密码；如果启用了多因素身份验证，则使用其第二个因素之一进行身份验证。新电子邮件应与当前电子邮件分开存储，直到它被验证。例如，可以将新电子邮件与验证令牌/代码一起存储。

当用户更改电子邮件时，应向之前的电子邮件地址发送通知，以确保账户安全。

邮件发送的速率限制

任何可以发送电子邮件的端点都应实施严格的速率限制，以防止滥用和垃圾邮件发送。

总结：构建安全的用户认证系统

密码重置和邮件验证是用户认证系统的重要组成部分，The Copenhagen Book提供的指南为开发者提供了清晰的实现路径。通过遵循这些安全最佳实践，你可以构建既安全又用户友好的密码重置和邮件验证流程，从而提升整体应用的安全性和用户体验。

要开始使用这些安全实践，可以克隆Copenhagen项目仓库：

git clone https://gitcode.com/gh_mirrors/co/copenhagen

通过实施本文介绍的安全流程，你可以有效保护用户账户，防止未授权访问，并建立用户对您应用程序的信任。

【免费下载链接】copenhagenA basic guideline on implementing auth for the web项目地址: https://gitcode.com/gh_mirrors/co/copenhagen