重置 ASP.NET 密码 - 安全问题？
我看到了有关此问题的各种问题，但有几个问题尚未被提出。如果用户忘记了密码，我希望他们能够仅使用他们的电子邮件地址重置密码（即没有安全问题/答案）。密码存储为加盐哈希，因此无法恢复。相反，我只是希望用户在确认他们已请求重置后输入新密码。
提到的一种常见方法是简单地：
1) 创建一个随机 Guid/加密强度强的随机数
2) 将包含随机数的唯一 URL 发送到用户的电子邮件 地址
3) 确认后，系统会要求用户更改密码
但是，这是否容易受到 MITM 攻击？如果通过互联网向电子邮件发送临时密码是不安全的，那么这样做与仅发送攻击者可以导航到的唯一 URL 之间有什么区别？ 我是否错过了某个使该系统更安全的关键步骤（或者是否有更好的重置密码的方法）？
谢谢
I've seen various questions regarding this issue, but there are a couple of questions that haven't been asked. If the user forgets their password, I would like them to be able to reset it with only their email address (i.e. there's no security question/answer). The password is stored as a salted hash, so there's no recovery possible. Instead, I'd just like the user to enter a new password after confirming that they have requested a reset.
A common method that's been mentioned is to simply:
1) Create a random Guid/Cryptographically strong random number
2) Send a unique URL containing the random number to the user's email
address3) When confirmed, the user is asked to change password
However, isn't this open to a MITM attack? If sending a temporary passwords over the internet to an email is insecure, what's the difference between doing that and simply sending a unique URL which the attacker can navigate to?
Have I missed a key step somewhere that will make this system more secure (Or is there a better way of resetting the password)?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您正确构造哈希，则 URL 点击必须来自请求重置的 IP 地址。这需要 MITM 欺骗 IP 和/或伪造标头。虽然这是可能的，但您可以识别相关系统的哈希值越独特，“结束”哈希值就越困难。
还建议该 guid 是特定标准的单向散列。还可以使用私钥解锁的公钥对请求中的系统数据进行加密，这样当单击 url 时，相同的公共加密系统数据必须伴随哈希值，并且唯一可以解密这些值的系统是服务器上保存的私钥。基本上是散列的伪 PKI 附件。
If you construct your hash correctly, the url click will have to come from the IP address that requested the reset. This would require the MITM to spoof the IP and/or falsify headers. While this is possible, the more unique you can identify the hash to the system in question, the more difficult it becomes to "end-around" the hash.
It is also recommended that the guid be a one-way hash of certain criteria. It is also possible to encrypt system data in the request using a public key that a private key unlocks so that when the url is clicked, this same public encrypted system data must accompany the hash, and the only system that could unencrypt these values would be the private key held at the server. Basically a psuedo-PKI attachment to the hash.
您验证用户身份的方法是共享秘密（密码）。
如果用户忘记了该秘密，您需要一种建立新共享秘密的方法。无论您采取什么方式，您仍然会遇到验证用户身份以共享新秘密的问题。
如果您唯一了解的可用于对用户进行身份验证的用户信息是他们的电子邮件地址，那么您将需要某种方法来确认请求重置的用户控制该电子邮件地址。
到目前为止，唯一的方法是将机密通过电子邮件发送到该电子邮件地址并检查他们是否收到。
这总是容易受到足够偷偷摸摸的 MitM 攻击。
您不发送临时密码的原因是为了避免“用户不愿意更改，因此继续使用不安全的临时密码而不是自己的安全密码”的问题。
Your means of authenticating the user is a shared secret (the password).
If the user forgets that secret, you need a way of establishing a new shared secret. No matter what way you go about it, you'll still have the problem of authenticating the user in order to share that new secret.
If the only thing you know about the user that could be used to authenticate them is their email address, then you'll need some way to confirm that the user requesting a reset is in control of that email address.
And the only way so far to do that is to email a secret to that email address and check if they received it.
Which is always going to be open to a sufficiently sneaky MitM attack.
The reason you don't send a temporary password is to avoid the issue of "the user can't be bothered changing and so keeps using the insecure temporary password instead of their own secure one."
为了降低中间人攻击的风险，我使用了以下措施：
To mitigate the risk of a man in the middle attack I use the following measures: