8

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

提到的一种常见方法是简单地：

1) 创建一个随机 Guid/加密强随机数

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

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

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

谢谢

4

3 回答 3

9

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

还建议该 guid 是某些标准的单向哈希。也可以使用私钥解锁的公钥加密请求中的系统数据，这样当点击 url 时，相同的公共加密系统数据必须伴随散列，并且唯一可以解密这些值的系统是保存在服务器上的私钥。基本上是散列的伪 PKI 附件。

于 2010-01-27T22:59:02.670 回答
7

您验证用户的方式是共享机密（密码）。

如果用户忘记了那个秘密，你需要一种方法来建立一个新的共享秘密。无论您采取何种方式，您仍然会遇到验证用户以共享该新秘密的问题。

如果您唯一了解的可用于对其进行身份验证的用户是他们的电子邮件地址，那么您将需要某种方式来确认请求重置的用户控制着该电子邮件地址。

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

这总是对足够偷偷摸摸的中间人攻击开放。

您不发送临时密码的原因是为了避免“用户不会被更改而继续使用不安全的临时密码而不是他们自己的安全密码”的问题。

于 2010-01-27T22:59:18.980 回答
1

为了降低中间人攻击的风险，我使用了以下措施：

  • 一个复位请求只能使用一次。
  • 如果未使用重置请求，它会在一小时后过期。
  • All reset requests are permanently logged whether it was ultimately completed or expired.
于 2010-01-28T01:02:33.683 回答