One approach to this problem of reset password secure link, could work as follows: User opens the password reset page, which has a form with an email address field.
User POST the form with their email address Server send a one-time password to the email address entered by the user. The server reply to the POST request with a new form containing: Hidden field with a secret valueText field for entering one-time password Two password fields for entering the new password On submission of the second form the server verify that the secret value in the form and the one-time password being entered do in fact correspond to each other. Additionally it verifies that the values are no older than x hours (for some x between 1 and 24). If everything was entered correctly, the password is reset.
This is similar to using a session cookie, but the secret value in a form field is likely to be less persistent than a session cookie. It is possible to combine such that the first POST request creates three values one in the email and two in cookie and form field in the POST reply, and the second POST request must contain all three values to reset the password.
A variation of this approach, which I am also considering is as follows: User opens the password reset page, which informs them about a one-time email address on the same domain as the web page (or a subdomain). Additionally the page contains a form with a hidden field with a secret value and a one-time password field. User send an email to the address, which they were informed about.
At the end of DATA, the receiving mail server immediately starts sending a reply to the user's email address. This reply will contain a one-time password. The one-time password that was send to the user is now copied from the email into the form.
Server verifies that hidden field and one-time password correspond to each other (connected through the one time email address). If successful the user is presented with user accounts registered to the verified email address.
The second approach might not be completely thought through yet, but I imagine it has the following advantages over simply sending an email to the user: You have one more opportunity to validate that the user does in fact control the email address, as you can validate SPF records at this point. You are less likely to disturb users with illegitimate password reset emails, as an attacker would have to pass the SPF check before the reset mail will be sent.
The reset mail is less likely to be blocked by a spam filter, because it is an actual reply to an email sent by the user.
