Some issues related to the implementation of the forgotten password feature in asp.net mvc

Question

I want to implement the forgotten password function in asp.net mvc, which allows users to reset their password, and you have some questions in this regard:

• Suppose that before allowing users to reset their password, I want to check additional information, such as their name and surname. This information is not stored by default in the table created by aspnet_regsql. What is the recommended approach to address such issues? Should I store this information in a separate table and use the tables to check OR should I change the table schema generated by aspnet_regsql (how?), So I don’t need to use joins? Do I need to write a custom provider or is it not needed?

• I read in places, for example. in this post , which instead of sending a temporary password by email, an alternative is to send a URL by email, which when clicked allows users to change their password. How it's done? How to make sure the url expires in 1 hour?

Answer 1

I don't know if this is recommended, but you can create a separate table as you mentioned, and then implement your own membership provider. Thus, with the reset password, you can implement the required additional functionality.

For the second part: I would generate a token, read about the different ways of creating it here . You can save the token with the date / time, send a link to the user with the token as part of the URL, then you can check it for the elapsed time as soon as users click on it.

Answer 2

I could write some answers to your questions. Too much to go into the implementation details, but I will try to hit the points that I had in mind when designing sites. Basically, you can (and should) work with a membership provider rather than working around it. This works a little, but you can do all of the following using providers and ASP.NET MVC.

• Avoid access to membership tables or performing membership storage procedures directly.
  • Their structure and use may differ in older or newer versions.
  • Suppliers are already set up for most tasks.
  • LINQ other methods of working with the map and help do the rest.
• For additional information, such as names, use ASP.NET Profiles.
• User email addresses must be unique.
• Users must create their own accounts.
  • Administrators should not create new accounts directly.
  • Passwords and security responses should be known only to the user.
  • The generated key (in the form of a URL) must be sent to confirm ownership of this email address before activating the account.
• Implement a security question and answer that a membership provider already supports.
  • Provide good questions to choose from.
  • Do not force or trust users to come up with a good ad hoc question.
  • Question / answer can be changed, knowing the current password.
• Forgotten passwords
  • May be reset by correctly answering the security question.
  • May be reset by administrative action if the security response is also forgotten or the account is locked.
• Password reset should mean:
  • The generated temporary password is sent to the email address in the account. Temporary funds:
    • A flag (profile value) is set to indicate that the user should set a new password after the next login.
    • The password expires after a certain time.
  • The administrator can reset the password, but should never know the password.
    • Must be done using the second provider definition (see ASP.Net. User forgot the answer to the password question )
    • If necessary, unlock the account.
• Block an account after too many failed password attempts or security attempts.
  • Failed attempts are already counted and configured inside the provider.
  • Optionally unlock your account automatically after enough time has passed.

I will expand this if I think more.