重置ASP.NET密码-安全问题？

我已经看到了关于这个问题的各种问题，但是有几个问题还没有被问到。如果用户忘记了密码，我希望他们能够只使用自己的电子邮件地址重置密码（即没有安全问题/答案）。密码被存储为咸哈希，因此无法恢复。相反，我只希望用户在确认请求重置后输入新密码

提到的一种常用方法是：

1） 创建随机Guid/加密强随机数

2） 向用户的电子邮件发送包含随机数的唯一URL 地址

3） 确认后，要求用户更改密码

然而，这难道不容易受到

MITM

攻击吗？如果通过internet向电子邮件发送临时密码是不安全的，那么这样做与发送攻击者可以导航到的唯一URL有什么区别？ 我是否错过了使系统更安全的关键步骤（或者是否有更好的方法重置密码）

---

谢谢

如果正确构建哈希，url单击必须来自请求重置的IP地址。这将要求MITM欺骗IP和/或伪造报头。虽然这是可能的，但您可以为相关系统标识的哈希越独特，就越难“结束”哈希

---

还建议guid是某些条件的单向散列。还可以使用私钥解锁的公钥对请求中的系统数据进行加密，以便在单击url时，该相同的公共加密系统数据必须伴随哈希，并且唯一可以对这些值进行解密的系统将是服务器上持有的私钥。基本上是散列的psuedo PKI附件。

验证用户的方法是共享秘密（密码）

如果用户忘记了该秘密，您需要一种建立新共享秘密的方法。不管你怎么做，为了分享这个新秘密，你仍然会遇到验证用户身份的问题

如果您对用户的唯一了解是他们的电子邮件地址，那么您需要某种方法来确认请求重置的用户控制着该电子邮件地址

到目前为止，唯一的方法是通过电子邮件将一个秘密发送到该电子邮件地址，并检查他们是否收到了它

它总是会被一个足够狡猾的MitM攻击

---

不发送临时口令的原因是为了避免“用户不能随意更改，因此使用不安全的临时密码代替自己的安全密码”。

< p>为了减轻中间人攻击的风险，我使用以下措施：

• 重置请求只能使用一次
• 如果未使用重置请求，则它将在一小时后过期
• 无论重置请求最终完成还是过期，都会永久记录所有重置请求

---

同意以上所有内容。我只想补充一点，临时密码应该是一次性使用的：一旦用于用户登录，就不能再次使用，用户必须更改它，否则用户将需要请求新密码。它没有任何手段绕过MITM攻击向量，但应该有一定程度的帮助。临时密码的讽刺之处在于，它可能比用户的实际密码更安全：D，但是，我正在沿着“确认链接”的路径，直到密码被改变为止，将它们锁定。如果您请求发送新密码时被要求提供一个秘密，则此消息将被拒绝。然后，当电子邮件中的链接发送给你，你点击链接时，你必须再次输入相同的秘密？我喜欢尝试确保确认链接点击与初始重置请求来自同一台计算机的想法。关于IP方面，这部分肯定是不相关的吗？作为攻击者，我会声称自己忘记了密码，因此密码重置请求来自我（攻击者）的PC。执行MITM攻击时，我会截获电子邮件，单击链接并更改密码，因为它一直看到我的IP地址。可能，但这假设攻击者也已经泄露了电子邮件帐户。IP将只是识别信息的一小部分。可能会应用其他指标来增加散列的复杂性。关键是不要依赖任何一个指标，因为每一个指标都必须妥协。要求越多，就越难通过。在某种程度上，它变成了一个努力与结果的问题。酷，这是有道理的。谢谢你的帮助，乔！看看这个网站，看看你可以用来识别浏览器的其他数据：我会让重置的过期时间比一个小时快得多。重置密码的目的是为了立即访问。期望一个“诚实”的用户等待一个小时使用重置是不合理的。