Nannette Thacker ShiningStar.net

ASP.net Web Application Development

Sponsors

News

See all Blog Posts by Nannette.

Nannette Thacker, consultant and owner of Shining Star Services LLC, specializes in development of custom dynamic database driven web applications utilizing ASP.net technologies. Nannette has been developing ASP sites since 1997. Nannette has written numerous articles on web development techniques and tutorials.

Nannette is the owner and developer of ChristianSinglesDating.com.

 Subscribe in a reader





View Nannette Thacker's profile on LinkedIn

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;
    }
}

May your dreams be in ASP.NET!

Nannette Thacker


View Nannette Thacker's profile on LinkedIn
Posted: Jan 18 2012, 03:37 PM by nannette | with 7 comment(s)
Filed under: , , , , , ,

Comments

rx said:

Holy shit lady, stop posting!  wait a few days ffs.  enough with your little trivial discoveries that every 1st year student should already know.  

# January 18, 2012 6:08 PM

MuteThis said:

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.

stackoverflow.com/.../what-does-only-catch-exceptions-you-can-handle-really-mean

Thanks for the posts :-)

# January 19, 2012 12:33 AM

nannette said:

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

# January 29, 2012 1:10 PM

Nick Brower said:

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!

# February 3, 2012 11:13 AM

Gilber Velez said:

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).

# February 7, 2012 12:32 PM

MuteThis said:

Leaving the debate of whether or not to allow a space character in the password aside, I would recommend implementing logic prohibiting the use of forbidden characters.  I wouldn't just *magically* remove them.

Here is a link to an article describing the association between password length and overall password security.  Removing characters is diminishing security IMO.

www.grc.com/haystack.htm

# February 11, 2012 1:18 PM

nannette said:

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

# February 17, 2012 9:32 AM
Leave a Comment

(required) 

(required) 

(optional)

(required)