Develop Reference

C# ASP.NET Identity

I have a scenario here whereby when a user wants to reset a password, the system will have to send a temporary random generated password to the user by email. I tried storing the temporary password into a new column in the database but I am not really sure about whether this approach works well. Some people recommend using token such as below:
string code = await UserManager.GeneratePasswordResetTokenAsync(user.Id);
However, I am really new to ASP.NET and I am not familiar with token. How do I compare the temporary generated token with the token in the database?
Another method that I found to implement this is to have a Membership.GeneratePassword function that generates a random string of characters:
model.temppwd = Membership.GeneratePassword(10, 1);
Can anybody provide me an ideal way to implement this functionality with some example? Thank you!

In our project we used
Guid.NewGuid();
and sent the email containing the link to the recover password action (MVC) as a query string: https://yoursite.com/account/reset/?code=your_guid_code
Example:
ResetPassword resetPassword = new resetPassword();
resetPassword.Code = Guid.NewGuid();
string strLink = string.Format("{0}", actionUrl + "?code="+ resetPassword.Code);`
And now you can use the strLink to send with your e-mail. You'll need to store the Guid in a database table alongside with the userId, so that you can implement the resetting procedure. When the user clicks the link from your email he'll get in a form / view that asks for a new password. Also you'll want to add an extra column to that table in order to provide an expiration limit for that code. If the user clicks the link in the e-mail and the code expired you'll have to inform the user and send another e-mail with another code.

How to get UserId from a PasswordReset token in ASP.NET Identity 2.0?

To reset a password we need to know a UserId and pass it to the UserManager.ResetPasswordAsync method. In the Identity 1.0 it was possible to obtain UserId from the UserManager.PasswordResetTokens.Validate method ((UserManager.PasswordResetTokens.Validate(token)).UserId). Now it's gone and all existing examples telling me that I need to ask an user for username or email. This is not user friendly, I don't want my users enter username again if token is valid.
This is already established tradition in ASP.NET Identity - something that worked before is broken in the new release. Of course I can create my own combined token with embedded UserId, but why I need to do extra work? New releases should improve things, not make them worse.

Asp.Net Identity 2.x do not provide a way to find a user by a token created from GeneratePasswordResetTokenAsync method.
You have two options:
1) Add the user id at the url you will send to the user. Ex:
var token = await _userManager.GeneratePasswordResetTokenAsync(applicationUser);
var callbackUrl = $"/reset-password/?user={WebUtility.UrlEncode(applicationUser.Id)}&code={WebUtility.UrlEncode(token)}";
This approach is more user friendly. But I know people that says this is a security issue because anyone with the link could reset the user password.
2) Ask for the user name at the reset password page, as you did. Ex:
public async Task<YourResultModel> ResetPassword(ResetPasswordViewModel vm)
{
// Your password validations...
var user = await _userManager.FindByNameAsync(vm.UserName);
// could be FindByEmailAsync if your app uses the user e-mail to login.
IdentityResult result = await _userManager.ResetPasswordAsync(user, vm.Token, vm.NewPassword);
return YourResultModelFromIdentityResult(result);
}
Before choose between this two approaches you need to think about your specific scenario. For example: If your app uses the user e-mail as username and to intercept the token the "interceptor" needs to access the user e-mail box, remove the user id from reset password link will not improve the security of your app. Because who has the link already knows the e-mail of the user.

Verify newly entered password of logged in user

User is logged in and wants to do something major and I want them to re-enter their password so I can make sure that they are the user that is logged in.
How can I confirm that this password is for the account holder?
Would be happy to know how to do it via ASP.NET Identity or how to set up a stored proc to go against the AspNetUsers table or how to do it via Entity Framework.

How can I confirm that this password is for the account holder?
how to do it via ASP.NET Identity
To reverify the password of currently logged in user, provide the user VerifyView to enter password and use the following method to check if the user exists.
var user = await UserManager.FindAsync(User.Identity.Name,VerifyViewModel.Password)
If the user is found, the current request is the same from the account holder.
Membership.ValidateUser is from earlier version of Membership framework, not from ASP.NET Identity.

You can also use UserManager.CheckPassword() extension function:
UserManagerExtensions.CheckPassword Method
string id = User.Identity.GetUserId();
var user = UserManager.FindById(id);
if(!UserManager.CheckPassword(user, model.Password))
{
ModelState.AddModelError("Password", "Incorrect password.");
}

With Identity framework you never want to hit the database directly. Always use the API provided. The database structure has changed several times in the past few years, so introducing dependencies (e.g. on a data context) is adding work for no reason.
For async usage, see the answer already provided by jd4u.
For synchronously identifying that the password matches the current user, you need to first include:
using Microsoft.AspNet.Identity;
as this brings in a number of synchronous extension methods for identity framework.
You can then check with Find on the UserManager like this:
var user = UserManager.Find(User.Identity.Name, password);
if (user != null)
{
// It is them!
}
If the user is not null, then you have a match of password and current username.

You can use UserManager to do that:
if(UserManager.PasswordHasher.VerifyHashedPassword("hashedPassword", "password")
!= PasswordVerificationResult.Failed)
{
// password is correct
}
For more information see the link:
How to check password manually in Asp.Net identity 2?

Log In User with Parameters when Changing Password

I have an ASP.NET App in which want to send an email to a user that presses a Recover Password button that resets the user's password and then sends a link to the user that when followed will log the user in with a new password and bring them to the Change Password page where they must resent their password.
I'm able to reset the password and get the new randomly generated password that I send back to the user in an email. However, when the user follows the link back with the UserName and pw parameters, the system does not seem to log them in,
Here's the code I am using on the load event that does not seem to work:
try
{
string sUserName = Request.QueryString["UserName"].ToString();
string sPw = Request.QueryString["pw"].ToString();
if (Membership.ValidateUser(sUserName, sPw))
{
//Log the user in???
FormsAuthentication.Authenticate(sUserName, sPw);
}
}
catch (Exception r)
{
string sMessage = r.Message;
}
Any help in logging the user in with username and password parameters would be greatly appreciated.

You can use FormsAuthentication.SetAuthCookie() :
if (Membership.ValidateUser(sUserName, sPw))
{
FormsAuthentication.SetAuthCookie(sUserName, true);
}
In your sample code you are retrieving the user name and password from the query string - this is very bad practice as any observer will see it in plain text. At least use a POST for these values and put them in the body (i.e with a form POST) and always use HTTPS at least for your login page.

use the following code.
if (Membership.ValidateUser(sUserName, sPw))
{
FormsAuthentication.SetAuthCookie(sUserName, true);
Response.Redirect("ChangePassword.aspx");
}
FormsAuthentication.Authenticate is almost same as FormsAuthentication.ValidateUser. They just validate user authentication. SetAuthCookie creates the authentication ticket(login).

This is how (IMO) reset password functionality should work:
User clicks button saying "Forgot Password".
In your code store a random GUID in the DB.
Send the user an email, with the GUID as a link in the email, as well as their userid, e.g:
http://yoursite.com/user/reset?guid=a21312738&userid=213123
On the incoming page, read the userid from the QS, and fetch the user from the DB by this value.
Compare the stored GUID from the GUID in the QS. If success, render a form that allows the user to change the password via an HTTPS POST.
In the POST action, change the user's password and sign them in.
You could also go one step further and store an expiration date for the GUID (e.g user must change their password in 24 hours).

How to log off multiple MembershipUsers that are not the current user?

I'm using the MembershipProvider that is part of the MVC2 default project.
I'd like to be able to take a list of user names, and log the users off, and destroy their session if needed. The closest I can seem to come is this:
foreach(string userName in UserNames)
{
MembershipProvider MembershipProvider = new MembershipProvider();
MembershipUser membershipUser = MembershipProvider.GetUser(userName, true);
Session.Abandon();
FormsAuthentication.SignOut();
}
I think I need to use a session and/or signout method related the user I want to log out, but I am unsure where those would be.
What is the proper way to do this?

That won't work...
Session.Abandon() will be for the Current HttpContext. Not for each user like you are trying to do.
Same for FormsAuthentication.SignOut().
Your best bet is check the current user against that array in the Application_AuthenticateRequest Event and sign them out there:
protected void Application_AuthenticateRequest(Object sender, EventArgs e)
{
if (User.Identity.IsAuthenticated)
{
//add your ckeck here
if (Usernames.Contains(User.Identity.Name))
{
Session.Abandon();
FormsAuthentication.SignOut();
}
}
}

I Didn't use the Membership provider when i did this but basically i saved the SessionId, Username and lastPage visited in a database when the user logged on. Each page then used the current SessionID to get the username and do related username stuff, like display balance for current user etc. if there isn't a valid user for the session then return to log-on page.
This allowed me the see the users progress through the website and manually disconnect whoever i wanted and gave me Single Signon per user . There was also a bunch of clean-up code in the global.asx page

This turned out to not be related so much to the MembershipProvider, but to the FormsService. My final solution turned out to be a sort of hybrid of the two other answers posted here.
I ended up creating my own FormsAuthenticationTicket in the Account controller in the LogOn action. I generate a unique identifier for the user's authenticated session, and save that identifier to the database. I also added the user's ID to the UserData part of the auth ticket for reliable lookup. By default the auth ticket only contained their user name. The FormsAuthenticationTicket is then stored in a cookie upon successful user log on.
Basically all of that replaced the FormsService.SignIn(model.UserName, model.RememberMe);
I also added public void Application_ReleaseRequestState(object sender, EventArgs args) in the Global.asax. I'm not sure if this is considered expanding a function or what, as it does not appear to be an override. Inside of Application_ReleaseRequestState it gets the user's FormsAuthenticationTicket from a cookie. It then decrypts the auth ticket, and gets the user's UserID from the UserData portion of the ticket. Then it asks the database if the auth ticket is still valid. If the ticket is not valid, it sets the user's cookie to expire.
To force users to log off, I can either change their auth ticket expiration dates in the database, or toggle the disable bit for their auth tickets in the database. Either way when Application_ReleaseRequestState asks the database if their auth tickets are valid, they won't be. Thus their cookies will get set to expire upon the next page the user hits after this check was made.