Resetting ASP.NET password - security issues?

Question

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

Answer 1

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.

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

Answer 3

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.