I have an application which uses ASP.net Identity as for its user authentication.

I do not wish for users to reset their own password (for reasons which are not relevant here), so I have developed the following back end system to allow system administrators to reset the users password.

I have the following implementation:

@using (Html.BeginForm())
{
@Html.AntiForgeryToken()

<div class="form-horizontal">
<hr />
@Html.ValidationSummary(true, "", new { @class = "text-danger" })
@Html.HiddenFor(model => model.Id)

<div class="form-group">
@Html.LabelFor(model => model.NewPassword, htmlAttributes: new { @class = "control-label col-md-2" })
<div class="col-md-10">
@Html.EditorFor(model => model.NewPassword, new { htmlAttributes = new { @class = "form-control" } })
@Html.ValidationMessageFor(model => model.NewPassword, "", new { @class = "text-danger" })
</div>
</div>

<div class="form-group">
@Html.LabelFor(model => model.ConfirmPassword, htmlAttributes: new { @class = "control-label col-md-2" })
<div class="col-md-10">
@Html.EditorFor(model => model.ConfirmPassword, new { htmlAttributes = new { @class = "form-control" } })
@Html.ValidationMessageFor(model => model.ConfirmPassword, "", new { @class = "text-danger" })
</div>
</div>

<div class="form-group">
<div class="col-md-offset-2 col-md-10">
<input type="submit" value="Reset Password" class="btn btn-default" />
</div>
</div>
</div>
}


    // GET: /AccountAdmin/ResetPassword
{
if (id == null)
{
}
return View(model);
}

//
[HttpPost]
[ValidateAntiForgeryToken]
{
if (!ModelState.IsValid)
{
return View(model);
}

{
{
}
}

}


public class ResetPasswordViewModel
{
public string Id { get; set; }

[Required]
[StringLength(100, ErrorMessage = "The {0} must be at least {2} characters long.", MinimumLength = 6)]
public string NewPassword { get; set; }

public string ConfirmPassword { get; set; }
}

• Although, as you say, "not relevant" I would love to know why you aren't going to let people reset their own passwords. – RobH Jun 5 '15 at 11:25
• @RobH: One of the main reasons is a large portion of our users will not have email addresses to follow down the usual password reset email route, additionally, our Email Policy's prevent the use of external email servers yet make it very difficult to use the approved one(For such things as SMTP Email sending) All of this coupled with the amount of potential users Vs Time it will take to implement a self service password reset makes it not high on the agenda to implement. – tornup Jun 5 '15 at 11:36
• Fair enough - unfortunate, but understandable. – RobH Jun 5 '15 at 11:45
• Anyone Reviewing the code should also note the Unfortunate missing functionality in the Identity Framework that does not let you simply reset a password, the only work around i found was to remove the users password and then add a new one.... I would be interested in your views of how I handle this, and if the methods i am using is considered secure and free of any potential failure. – tornup Jun 5 '15 at 12:00

One thing you should keep in mind is that when the Add fails, your user is left without a password as it's already been removed. When will this fail? Usually when your password does not pass the validation.

Of course, seeing how an admin is doing it, there's probably not so much of a problem as they can simply add a different one - as long as the message is clear enough to show there actually is a problem with adding the new password.

The way Microsoft wants you to tackle this is by using a PasswordResetToken.

var code = await _userManager.GeneratePasswordResetTokenAsync(user);

For this you'll have to fiddle around a bit with the token generators that Identity provides.