在nonce电子邮件中激活/注册/密码重置链接的最佳做法是什么?

应用程序发送电子邮件来validation用户帐户或重置密码。 我相信以下是应该的方式,我要求引用和实现。

如果一个应用程序必须发送一封邮件中的链接来validation用户的地址,根据我的观点,链接和应用程序对链接的处理应该具有以下特征:

  1. 该链接在请求URI( http://host/path?nonce )中包含一个随机 http://host/path?nonce
  2. 在跟随链接(GET)之后,用户被呈现一个表格,可选地具有随机数。
  3. 用户确认input(POST)。
  4. 服务器收到请求并
    • 检查input参数,
    • 执行更改,
    • 并使nonce失效。

这在安全和幂等方法的HTTP RFC上应该是正确的。

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

  • 有没有关于这个问题的参考文献可以更好地解释这个想法,甚至说服一个非技术人员(来自期刊,博客等的最佳实践)呢?
  • 是否有参考网站(最好是stream行的,并与许多用户)实施这种方法?
    • 如果没有,是否有文件logging的理由或等同的替代方法

谢谢,
Kariem


细节保留

我把主要部分缩短了,但是为了减less我有意忽略的细节的讨论,我将增加一些假设:

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

笔记

通过使用OpenID等,正常的Web应用程序可以免去执行标准的用户帐户pipe理(密码,电子邮件…),但仍有一些客户希望“ 自己的用户

奇怪的是,我还没有find一个令人满意的问题,也没有回答。 到目前为止我发现的是:

  • 唐在HTTP POST与URL查询参数 – 好主意或不?
  • 托马斯的问题 – 什么时候使用POST,什么时候使用GET?

这个问题与在ASP.NET(C#)中实现安全,唯一的“一次性”激活URL很相似。

我的回答接近你的scheme,有几个问题指出 – 如有效期短,处理双重注册等。
你使用encryption随机数也很重要,许多人往往会跳过 – 例如“让我们只使用一个GUID”…

你提出的一个新观点在这里很重要,就是GET的幂等性。
虽然我同意你的一般意图,但清楚的是幂等性与一次性联系是直接矛盾的,这在某些情况下是必要的。

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

如果你真的想要达到严格的RFC合规性,而不是进入非幂等(?)GET,你可以让GET页面自动提交POST – 围绕RFC的一个漏洞,但是合法的,你不要求用户双重select,而你不是在窃听他…

你不必担心预加载(你是在谈论CSRF,还是浏览器优化器?)…由于nonce,CSRF是无用的,优化器通常不会在预加载的页面上处理javascript(用于自动提交)。

关于密码重置:

通过向用户注册的电子邮件地址发送电子邮件来做到这一点的做法虽然在实践中很常见,但安全性不高。 这样做完全将您的应用程序安全性外包给用户的电子邮件提供商。 无论您需要多长时间的密码以及您使用的任何巧妙的密码哈希,都无关紧要。 我可以通过阅读向用户发送的电子邮件进入您的站点,因为我可以访问电子邮件帐户,或者能够在通往用户的任何地方读取未encryption的电子邮件(想想:evil sysadmins)。

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

我发现这个讨论这个话题的白皮书 。

如何以安全的方式做到这一点的简短版本:

  1. 需要关于帐户的重要事实

    1. 用户名。
    2. 电子邮件地址。
    3. 10位数字帐号或其他信息,如社会安全号码。
  2. 要求用户至less回答三个预先定义的问题(由您预先定义,不要让用户自己提出问题),这些问题都是无足轻重的。 像“你最喜欢的度假地点是什么”,而不是“你最喜欢的颜色是什么”。

  3. 可选:将确认代码发送到用户必须input的预定义电子邮件地址或单元号(SMS)。

  4. 允许用户input一个新的密码。

我通常会同意你在下面的一些修改。

  1. 用户在您的网站注册,提供电子邮件。
  2. validation电子邮件发送到两个链接的用户帐户:a)一个链接与GUIDvalidation注册b)一个链接与GUID拒绝validation
  3. 当他们从他们的电子邮件访问validationurl时,他们会被自动validation,并且validation指导在您的系统中被标记。
  4. 当他们从他们的电子邮件访问拒绝url时,他们会自动从可能的validation队列中删除,但更重要的是,您可以告诉用户您对电子邮件注册感到抱歉,并给他们进一步的select,例如从您的系统中删除他们的电子邮件。 这将停止任何自定义服务types的投诉有人在您的系统中input我的电子邮件…等等等等等等。

是的,你应该假设当他们点击validation链接时,他们被validation。 让他们点击页面中的第二个button是有点多,只需要在样式注册中双击select,你打算发送垃圾邮件注册的人。 标准的注册/validationscheme通常不需要这样做。