什么是电子邮件中具有随机数的激活/注册/密码重置链接的最佳做法

Question

应用程序发送电子邮件来验证用户帐户或重置密码。我相信以下是它应该是的方式，我要求参考和实施。

如果应用程序发送一个链接的电子邮件，以验证用户的地址，根据我的看法，链路的链路和应用程序的处理应具有以下特点：

1. 链接在请求URI（http://host/path?nonce）中包含nonce。
2. 在链接（GET）之后，用户会被呈现一个表单，可选地包含nonce。
3. 用户确认输入（POST）。
4. 服务器接收该请求，并
   • 检查输入参数，
   • 进行变化，
   • 和无效的随机数。

这应该是每HTTP RFC on Safe and Idempotent Methods正确的。

问题是，这个过程涉及一个额外的页面或用户操作（项目3），这被认为是多余的（如果不是无用的）很多人。我在向同行和客户展示这种方法时遇到了问题，因此我要求从更广泛的技术小组就此提出意见。我反对跳过POST步骤的唯一理由是可能从浏览器预加载链接。

• 有没有关于这个问题的参考文献可以更好地解释这个想法，甚至说服一个非技术人员（来自期刊，博客等的最佳实践）？
• 是否有实现此方法的参考站点（最好是受欢迎并且拥有许多用户）？
  • 如果不是，是否有记录的原因或等效替代方法？

谢谢
Kariem

---

详细幸免

我一直主要部分短，而是减少围绕我的细节太多讨论故意排除，我会加几个假设：

• 电子邮件的内容不是本讨论的一部分。用户知道她必须点击链接才能执行操作。如果用户没有反应，什么都不会发生，这也是已知的。
• 我们不必指出我们为什么寄给用户，也不必说明沟通政策。我们假设用户期望收到电子邮件。
• 该随机数具有到期时间戳，并直接与收件人电子邮件地址关联以减少重复。

---

注意

使用OpenID之类的，正常的Web应用程序，从执行标准用户帐户管理（密码，电子邮件...）松了一口气，但仍然有一些客户希望'其自己的用户“

奇怪的是我还没有找到一个满意的问题，也尚未回答在这里。我迄今发现：

• Answer by Don in HTTP POST with URL query parameters — good idea or not?
• Question from Thomas -- When do you use POST and when do you use GET?

Answer 1

此问题与Implementing secure, unique “single-use” activation URLs in ASP.NET (C#)非常相似。

我的回答有接近你的方案，有几个问题指出 - 比如有效期短，处理双注册，等
你使用加密现时也很重要，很多倾向于跳过 - 例如“让刚刚使用GUID” ......

你做提高了，这是这里重要的一个新的起点，是WRT GET的幂等。
虽然我同意你的一般意图，但它清楚地表明幂等性与一次性链接直接相反，这在一些情况下是必要的。

我本来希望断定，这并不能真正违反GET的idempotentness，但不幸的是它...在另一方面，RFC说GET 应该幂等，它不是必须的。所以我会说在这种情况下放弃它，并坚持一次性自动失效链接。

如果你确实想要严格遵守RFC，而不是进入非幂等（？）GET，你可以让GET页面自动提交POST - 围绕那个位的漏洞种类RFC，但合法，你不需要用户双重选择，而且你不会窃听他...

你不必担心预加载（你在谈论CSRF，还是浏览器优化器？ ）...由于nonce，CSRF是无用的，优化器通常不会在预加载的页面上处理JavaScript（用于自动提交）。

Answer 2

我大体上同意你的一些修改以下建议。

1. 用户在你的网站提供的电子邮件注册。
2. 验证电子邮件被发送到用户的帐户中有两个环节： 一）与GUID的一个链接以验证登记b）一名链路与GUID拒绝核查
3. 当他们访问验证URL从他们的电子邮件它们会被自动验证，并且验证GUID在您的系统中被标记为这样。
4. 当他们访问他们的电子邮件拒绝的URL，它们会自动从可能验证的队列中删除，但更重要的是，你可以告诉你的电子邮件注册对不起用户，给他们更多的选项，例如从消除他们的电子邮件您系统。这将停止任何自定义服务类型的投诉有人在你的系统中输入我的电子邮件......等等等等等等等等

是的，你应该假设他们点击验证链接时，他们被验证。让他们点击页面中的第二个按钮有点多，只需要在样式注册中选择双重选择，因为您计划对已注册的人发送垃圾邮件。标准的注册/验证方案通常不需要这样做。

Answer 3

关于密码重置：

通过发送邮件到用户的注册邮箱是这样做的做法，而在实践中很常见，没有良好的安全性。这样做完全将您的应用程序安全性外包给用户的电子邮件提供商。无论您需要多长时间的密码以及您使用的任何巧妙的密码哈希，都无关紧要。我可以通过阅读发送给用户的电子邮件进入您的站点，因为我有权访问电子邮件帐户或能够在向用户发送未加密邮件的任何地方（想想：evil sysadmins）。

根据相关网站的安全要求，这可能也可能不重要，但作为网站的用户，我至少希望能够禁用这种密码重置功能，因为我认为它不安全的。

我发现this white paper讨论了这个话题。

如何做一个安全的方式简短的版本：

1. 需要有关帐户

   1. 用户名铁的事实。
   2. 电子邮件地址。
   3. 10位数帐号或其他信息 像社会安全号码。

2. 要求用户回答至少三个预定义的问题（由你预先定义， 不要让用户创建自己的问题），不能是微不足道的。像“什么是 你最喜欢的度假胜地”，而不是“你最喜欢的颜色是什么”。

3. 可选：将确认代码发送到用户必须输入的预定义电子邮件地址或单元号（SMS）。

4. 允许用户输入新密码。