应用程序发送电子邮件以验证用户帐户或重置密码.我相信以下是应该的方式,我要求参考和实现.
如果应用程序必须在电子邮件中发送链接以验证用户的地址,根据我的观点,链接和应用程序对链接的处理应具有以下特征:
该链接在请求URI()中包含一个noncehttp://host/path?nonce.
在链接(GET)之后,向用户呈现表单,可选地具有随机数.
用户确认输入(POST).
服务器接收请求和
检查输入参数,
执行更改,
并使nonce无效.
根据安全和幂等方法的HTTP RFC,这应该是正确的.
问题是这个过程涉及一个额外的页面或用户操作(第3项),这被很多人认为是多余的(如果不是无用的).我在向同行和客户介绍这种方法时遇到了问题,因此我要求更广泛的技术小组提供相关信息.我跳过POST步骤的唯一论点是可能从浏览器预加载链接.
是否有关于这个主题的参考资料可以更好地解释这个想法并说服一个非技术人员(来自期刊,博客......的最佳实践)？
是否有实施此方法的参考站点(最好是受欢迎且有许多用户)？
如果没有,是否有记录原因或等效替代方案？
谢谢你,
Kariem
细节幸免
我保持主要部分简短,但为了减少关于我故意遗漏的细节的太多讨论,我将添加一些假设:
电子邮件的内容不是此讨论的一部分.用户知道她必须单击链接才能执行操作.如果用户没有反应,则不会发生任何事情,这也是已知的.
我们不必说明我们邮寄用户的原因,也没有说明通信政策.我们假设用户希望收到电子邮件.
nonce具有到期时间戳,并且与收件人电子邮件地址直接关联以减少重复.
笔记
使用OpenID等,普通的Web应用程序可以免于实施标准的用户帐户管理(密码,电子邮件......),但仍有一些客户需要" 他们自己的用户 "
奇怪的是,我还没有找到令人满意的问题,也没有回答.到目前为止我发现了什么:
Don在HTTP POST中使用URL查询参数回答- 好主意与否？
托马斯的问题 - 你什么时候使用POST,什么时候使用GET？
AviD.. 24
此问题与在ASP.NET(C#)中实现安全,唯一的"一次性"激活URL非常相似.
我的答案与您的方案很接近,指出了一些问题 - 例如短期有效期,处理双重注册等.
您对加密随机数的使用也很重要,许多人倾向于跳过 - 例如"让我们只是使用GUID"......
你提出的一个新观点,这在这里很重要,是GET的幂等性.
虽然我同意你的一般意图,但很明显,幂等性与一次性联系直接矛盾,这在某些情况下是必要的.
我本来希望假设这并没有真正违反GET的幂等性,但遗憾的是它确实......另一方面,RFC说GET 应该是幂等的,它不是必须的.所以我会说在这种情况下放弃它,并坚持使用一次性自动失效的链接.
如果你真的想要达到严格的RFC合规性,而不是进入非幂等(？)GET,那么你可以让GET页面自动提交POST - 围绕RFC的那个漏洞,但是合法的,你不要求用户双重选择,你也不会惹他生气......
你真的不必担心预加载(你是在谈论CSRF,还是浏览器优化器？)... CSRF因为nonce而无用,优化器通常不会在预加载的页面上处理javascript(用于自动提交).
此问题与在ASP.NET(C#)中实现安全,唯一的"一次性"激活URL非常相似.
我的答案与您的方案很接近,指出了一些问题 - 例如短期有效期,处理双重注册等.
您对加密随机数的使用也很重要,许多人倾向于跳过 - 例如"让我们只是使用GUID"......
你提出的一个新观点,这在这里很重要,是GET的幂等性.
虽然我同意你的一般意图,但很明显,幂等性与一次性联系直接矛盾,这在某些情况下是必要的.
我本来希望假设这并没有真正违反GET的幂等性,但遗憾的是它确实......另一方面,RFC说GET 应该是幂等的,它不是必须的.所以我会说在这种情况下放弃它,并坚持使用一次性自动失效的链接.
如果你真的想要达到严格的RFC合规性,而不是进入非幂等(？)GET,那么你可以让GET页面自动提交POST - 围绕RFC的那个漏洞,但是合法的,你不要求用户双重选择,你也不会惹他生气......
你真的不必担心预加载(你是在谈论CSRF,还是浏览器优化器？)... CSRF因为nonce而无用,优化器通常不会在预加载的页面上处理javascript(用于自动提交).
关于密码重置:
通过向用户的注册电子邮件地址发送电子邮件来实现此目的的做法虽然在实践中非常普遍,但并不是很好的安全性.这样做会将您的应用程序安全性完全外包给用户的电子邮件提供商.无论您需要多长时间的密码以及您使用的任何聪明的密码哈希都无关紧要.我可以通过阅读发送给用户的电子邮件进入您的网站,因为我可以访问电子邮件帐户,或者能够在去往用户的任何地方读取未加密的电子邮件(想想:邪恶的系统管理员).
根据相关网站的安全要求,这可能会或可能不重要,但作为网站的用户,我至少希望能够禁用此类密码重置功能,因为我认为它不安全.
我发现这篇讨论该主题的白皮书.
如何以安全的方式进行的简短版本:
需要关于帐户的确凿事实
用户名.
电子邮件地址.
10位数帐号或其他信息,如社会安全号码.
要求用户至少回答三个预定义的问题(由您预定义,不要让用户创建自己的问题),这些问题不可能是微不足道的.比如"你最喜欢的度假胜地",而不是"你最喜欢的颜色".
可选:将确认代码发送到用户必须输入的预定义电子邮件地址或手机号码(SMS).
允许用户输入新密码.
京公网安备 11010802040832号 | 京ICP备19059560号-6 