Password Recovery without sending password via email

Question

So, I've been playing with asp:PasswordRecovery and discovered I really don't like it, for several reasons:

1) Alice's password can be reset even without having access to Alice's email. A security question for password resets mitigates this, but does not really satisfy me.

2) Alice's new password is sent back to her in cleartext. I would rather send her a special link to my page (e.g. a page like example.com/recovery.aspx?P=lfaj0831uefjc), which would let her change her password.

I imagine I could do this myself by creating some sort of table of expiring password recovery pages and sending those pages to users who asked for a reset. Somehow those pages could also change user passwords behind the scenes (e.g. by resetting them manually and then using the text of the new password to change the password, since a password cannot be changed without knowing the old one). I'm sure others have had this problem before and that kind of solution strikes me as a little hacky. Is there a better way to do this?

An ideal solution does not violate encapsulation by accessing the database directly but instead uses the existing stored procedures within the database...though that may not be possible.

Answer 1

Why would sending a plain-text link to a recovery page through email be any better than sending a plain-text password through email? Either way, somebody with access to the email address can gain access to the account, whether it's through knowing the new password or through following the link.

I think that if you force the user to change their password immediately after logging in after a password reset, that would reduce the amount of time that the temporary password is valid.

Answer 2

I recommend adding an additional level of checking, here are some options to choose from.

1. First you can save the requester's IP address in a database, then when they click the reset link compare that with the IP address of their current machine, if they match then reset the password. If the email is intercepted then the person attempting to reset the password must have a matching IP address.
2. Use a cookie and store a unique value, maybe a GUID, MD5 hash or something. So when the user makes a password reset request a cookie is stored on their machine and in the database, when the user clicks the link the local cookie must match the database value or they will not be able to reset their password.

In general I am totally against ever sending a password in Email, so I like the password reset link option more than a new plain-text password.

Answer 3

I'm currently implementing an open source user management system on top of Spring + SpringSecurity, and here's how I'm addressing the lost password problem.

1. The user's account must have a preregistered email address.
2. To request a reset, the user enters their account name into a form.
3. A temporary "reset code" is generated and attached to the account, and emailed to the user embedded in a hyperlink.
4. On receiving the email, the user clicks the link which takes them to a page to enter their new password.
5. Before accepting the new password, the reset code (from the link) is checked against the stored code, to make sure it is correct and that it hasn't expired.

This avoids sending a password (in clear) in an email message. And it also protects against one person resetting another person's password, because the password reset only takes place after the link has been used.

But it does rely on the user's email account being secure, and in the email not being snooped while in transit. For some applications, this maybe an unacceptable risk.

Another piece of the equation is that you need to be really careful about changing a user's registered email addresses. At the very least, the user must enter their current password with the request to change address ... to prevent against hacking via unattended login sessions.