Resetting ASP.NET password - security issues?

问题:

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 address

3) 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

回答1:

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.

回答2:

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."

回答3:

To mitigate the risk of a man in the middle attack I use the following measures:

• A reset request can be used one time only.
• If a reset request is not used, it expires after one hour.
• All reset requests are permanently logged whether it was ultimately completed or expired.