ChangePassword Method for Entity Framework MVC3 Razor Custom Member Provider C# Using LINQ

From my C# MVC3 Razor Custom Membership Provider article and source code, here is the code for the ChangePassword method. I welcome any suggestions for improvement.
public override bool ChangePassword(string username, 
    string oldPassword, string newPassword)
{
    try
    {
        byte[] hashedNewPassword = HashPassword(newPassword.Trim());
        byte[] hashedOldPassword = HashPassword(oldPassword.Trim());
        using (var context = new SSSEntities())
        {
            UserProfile u = context.UserProfiles
            .SingleOrDefault(up => up.UserName == username && 
                up.UserPassword == hashedOldPassword);
            if (u != null)
            {
                u.UserPassword = hashedNewPassword;
                context.SaveChanges();
                return true;
            }
            else
                return false;
        }
    }
    catch (InvalidOperationException ex)
    {
        throw ex;
    }
    catch (ArgumentException)
    {
        throw;
    }
}

[SIGNATURE]

5 Comments

  • Trimming a password field seems as though it could be eliminating desired padding (read complexity). It seems like that could reduce security. If you're going to trim, should you trim before hitting the change method? Now you need to remember to trim before checking the password too. Also, if my password is all spaces, it could pass through your length requirement check, to only be trimmed down to a zero length string.

    Also, the default implementation of the membership provider provisions for a per user password salt. It looks like your custom provider has reduced that protection to one salt for all passwords. That also seems to be reducing security.

    If you'd like a small performance boost (they add up), consider only hashing the new password after confirming you have a valid user and old password combination.

    I probably wouldn't catch any exceptions that I wasn't planning to handle either.

    http://stackoverflow.com/questions/4673860/what-does-only-catch-exceptions-you-can-handle-really-mean

    Thanks for the posts :-)

  • MuteThis,

    Thanks for the suggestions. Yes, it is very important to take in consideration the design requirements for your project. I didn't intend this project to be a comprehensive study; just a starting point to help people figure out how to implement the custom membership provider. From there, I would most certainly recommend they implement security measures and the detailed requirements of their system.

    To salt a password per user, there should be an additional field in the user table to use as a salt value; that is beyond the scope of this project; but I definitely appreciate you pointing that out to users. Typically you look up the unique email address log in, find the salt value of that record, and then generate the encrypted password, and look it up under that email address.

    As far as trimming passwords, I would recommend that be considered in the registration process: do you allow users to have spaces in their passwords? If so, remove trims, if not, definitely use trims. A lot of times users will paste in their password from a document of passwords and they end up with a space on the end, then it never works. I always recommend not allowing spaces at all.

    Thanks again for the suggestions!

    Nannette

  • Thanks so much for your custom membership provider. I looked everywhere for one using LINQ and MVC and yours is the only one I found. Thanks for taking the time to put it together dude! It's really appreciated!

  • There was nothing wrong with your post because:
    You should always post as if the reader has no knowledge of the topic. If there’s one thing I’ve learned is that you should Dummy proof everything. Assume your readers are all novices.

    You were correct in trimming the passwords because there should never be leading or ending spaces in a password. Again that dummy proofing. It’s just clean work to anticipate the end users mistakes or you could reject the user input(which will just annoy the end user).

  • MuteThis,

    I would certainly have the allowed characters handled client side and inform the user what is required, ie: alpha numeric, no spaces, etc. Then handle it in the validations.

    But if perchance their browser skipped the validation, I'd handle it server side as well. You could go back to the page and make them do it again.

    Thanks for the info!

    Nannette

Comments have been disabled for this content.