Password recovery without sending a password by email

So, I played with asp:PasswordRecovery and found that I really didn't like it, for several reasons:

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

2) Alice’s new password is sent back to her in clear text. I would prefer to send her a special link to my page (for example, a page, for example example.com/recovery.aspx?P=lfaj0831uefjc), which would allow her to change her password.

I guess I can do it myself by creating some sort of table of expiring password recovery pages and sending these pages to users who asked for a reset. Somehow, these pages can also change user passwords behind the scenes (for example, by manually resetting them and then using the text of the new password to change the password, because the password cannot be changed without knowing the old one). I am sure that others had this problem before, and this solution seems a bit hacked to me. Is there a better way to do this?

An ideal solution does not break encapsulation by directly accessing the database, but instead uses existing stored procedures in the database ... although this may not be possible.

+4
source share
2 answers

I am currently implementing an open system user management system on top of Spring + SpringSecurity, and this is how I handle the lost password problem.

  • The user account must have a pre-registered email address.
  • To request a reset, the user enters the name of his account in the form.
  • A temporary reset code is created and attached to the account and sent by e-mail to the user embedded in the hyperlink.
  • When receiving email, the user clicks on the link that displays them on the page to enter a new password.
  • Before accepting a new password, the reset code (via the link) is checked on the saved code to make sure that it is correct and that it has not expired.

This avoids sending the password (explicitly) in the email message. And it also protects against the fact that one person reloads the password of another person to be unpleasant, because the reset password is only executed after the link has been used.

But it relies on a secure email user account, and also that the email is not monitored during transit. For some applications, this may be an unacceptable risk.

Another part of the equation is that you need to be very careful in changing user registered email addresses. At the very least, the user must enter their current password with a request to change the address ... to prevent hacking through automatic login sessions.

+4
source

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

  • First you can save the requester’s IP address in the database, and then when they click the reset link, compare it with the IP address of your current computer if they match the reset password. If the email is intercepted, then the user trying to reset the password must have the appropriate IP address.
  • Use a cookie and save a unique value, perhaps a GUID, an MD5 hash, or something else. Therefore, when the user makes the password reset, the cookie request is stored on their machine and in the database, when the user clicks on the link, the local cookie must match the database value or they cannot reset their password.

In general, I am completely opposed to sending the password by email, so I like the reset link more than the new plaintext password.

+2
source

Source: https://habr.com/ru/post/1286720/


All Articles