任何人都可以提供正确实施 Web 应用程序自我密码重置机制的参考吗?

信息安全 应用安全 Web应用程序 密码管理
2021-08-14 03:19:50

我们正在一个 Web 应用程序上实现自我密码重置,我知道我想怎么做(电子邮件限时密码重置 URL 到用户预先注册的电子邮件地址)。

我的问题是我找不到任何参考资料来指向开发人员使用该技术。谁能指出我对这项技术的一些好的参考的方向?

4个回答

一些建议:

在确认之前不要重置用户的密码。不要立即重置用户的密码。只有在用户点击发送到他们预先注册的电子邮件地址的确认链接后才能重置它。

需要验证码。当用户请求重置其密码时,请强制他们先解决验证码,然后再继续操作。这是为了防止自动化工具试图给许多用户带来痛苦,并迫使用户证明他们是人(而不是机器人)。

随机性。限时密码重置 URL 应包含一个随机的、不可猜测的部分。确保使用加密质量的随机性。的输出/dev/urandomorSystem.Security.Cryptography.RNGCryptoServiceProvider将是一个不错的选择。rand()or or random()or的输出System.Random不够随机,将是一个糟糕的选择。GUID 或时间戳不够随机,不是一个好的选择。

包括时间限制。重置确认链接应在一段合理的时间后过期:比如 24 小时。该链接应该只能使用一次,并且应该在使用后立即失效。

在电子邮件中包含解释性文字。您可能需要在电子邮件中添加一些解释性文本,以解释发送电子邮件的原因,以防有人要求重置不是您自己的帐户。您可以添加一些文本,例如“有人要求为您的帐户重置密码usernamesite如果您提出此请求,请单击此处更改您的密码。如果您未提出此请求,请单击此处取消该请求。”

重置密码后发送电子邮件。成功重置密码后,向用户发送电子邮件,让他们知道密码已更改。不要在该电子邮件中包含新密码。

监控取消。您可能会考虑包含一些逻辑来监控用户单击取消链接以表明他们没有请求重置的频率。如果超过某个阈值,则向系统操作员发送警报可能很有用。此外,如果某个请求的取消链接在之后访问访问了确认链接,这可能表明该用户受到攻击——您可能希望在此时采取措施,例如,使用户的密码无效并要求他们再次重置密码。(这是对以下攻击的防御:攻击者获得对用户邮箱的访问权限,然后请求重置他们在您网站上的密码,然后访问确认链接。如果攻击者没有从用户的收件箱中删除这些电子邮件,那么当真正的用户阅读他们的电子邮件时,他们可能会单击取消链接,从而提示您可能存在问题。)

使用 HTTPS。该链接应使用 https(不是 http:),以防止各种攻击(例如,Firesheep 攻击对从网吧上网的用户进行的攻击)。

记录这些操作。我建议记录所有此类请求。除了记录用户的用户名之外,您可能还需要记录请求将重置链接通过电子邮件发送给用户的客户端的 IP 地址,以及访问重置链接的客户端的 IP 地址。

附加阅读。您可能还想阅读 Troy Hunt 的优秀博客文章,关于构建安全密码重置功能的所有您想知道的内容感谢 @coryT 提供此资源的链接。

最后,考虑非密码身份验证。 密码作为身份验证机制存在许多问题,您可以考虑使用其他方法来验证用户身份,例如在他们的机器上存储一个安全的持久 cookie,并使用不可猜测的秘密来验证他们。这样,就不会忘记密码,也不会让用户被网络钓鱼,尽管您确实需要为用户提供一种授权从新机器或新浏览器访问的方法(可能通过电子邮件发送到用户的 pre-注册的电子邮件地址)。 这份调查报告对许多后备身份验证方法及其优缺点进行了出色的调查。

特洛伊亨特对这个确切的问题有一篇非常好的文章。 您想知道的有关构建安全密码重置功能的所有信息

好的,所以您的问题是,您应该如何构建密码/帐户恢复过程?这将取决于您要优化的内容:无忧的用户体验或良好的安全性。

如果您想要良好的安全性:

  • 在注册期间,用户必须输入他的电子邮件地址。
  • 在注册过程中,用户必须输入第二个认证渠道——手机号码或挑战问答(即“你妈妈的娘家姓是什么”或更好)。

  • 在恢复过程中,您的系统首先通过上述辅助通道——质询问题,或通过向手机发送代码或类似方式,获得粗略的身份验证。

  • 当上述第一次身份检查被清除后,系统将仅向之前输入的电子邮件地址发送密码重置电子邮件。这是防止 fx Sarah Palin 类型漏洞利用的额外重要措施

  • 电子邮件不得包含新密码或类似内容。它应该具有指向您网站上 HTTPS 加密网页的可点击链接,该链接a)通过 URL 中提供的不可猜测的秘密值链接到帐户,b)是有时间限制的,因此帐户恢复仅适用于x 小时后,c)为最终用户提供了一种创建密码的方法。

  • 对所有帐户重置交易进行良好的记录,并让一个人实际监控这些交易并在它们出现可疑情况时采取行动(查看服务器日志中的 IP 地址 fx,是否有许多请求来自同一个 IP 地址,是否有实例用户正在尝试从与注册帐户所有者不同的国家/地区重置密码等)。

您也可以完全避开这种复杂性:现在还处于早期阶段,但 OAuth / OpenID / 通过 Facebook、Google 等登录可以完全从您的系统中消除这种复杂性,但可能不太完善的可用性

任何可以向您发送密码的地方都意味着他们不会对密码进行哈希处理,而是将其存储在可以以某种方式解密为“明文”的地方。这本身就是不好的。

可能不是“最”安全​​的,但更安全的是:

根据密码请求,向具有嵌入式 GUID 的用户发送密码重置链接。GUID 中的会话将在 嗯、小时左右到期。