Failed to import legacy user Md5 passwords into ASP.NET membership provider

Yesterday I disconnected the registration on the main Aramco ExPats website so that I could transfer the user database. I ran into a bit of a problem as I had previously used an Md5 encryption to store the users passwords. The new code base (SiteWorks by Mindfly) uses the membership provider shipped with ASP.NET 2.0. I had read that the membership provider supports Md5 encryption (which is true) but neglected to play with the provider enough to realize that the passwords saved to the database on newly created users are stored with a randomly generated password salt dispite the fact that I had the membership provider configured for Md5 hash.

I have looked all over for a work around and even tried the hypothetical direct update of the aspnet_Membership table with the old Md5 encrypted value the password field and a String.Empty value in the passwordsalt field ... nada.

In the end, I was forced to bite the bullet and simply import the users and reset every password to a randomly generated string which will force the entire Aramco ExPats community to reset their password when the new site publishes next week (click here for a sneak preview). I suppose the upside is that this at least allowed me to use the preferred SHA1 encryption.

I have to admit I am extremely frustrated that I was unable to find a direct import solution for the legacy user Md5 saved passwords. If anyone has a solution, I would really appreciate some tutelage!

Posted on October 11, 2007 15:54 by Rusty Swayne
Tags: md5, membership provider, asp.net
Categories: Job related
Actions: E-mail | Permalink | Comments (4) | Trackback

Be the first to rate this post

Currently 0/5 Stars.
1
2
3
4
5

Comments

Wilfried Mack said...

Unfortunately Rusty has already committed the deed, but for future reference the answer lies with the actual users. To port the User's currently MD5 hashed password into the .Net Membership Provider, we have to modify the login control within the new site. This login control will, upon submit, check to see if the current UserName/Password exists in the Membership Provider using the Membership.ValidateUser(UserName, Password) function. If successful, log the user in, otherwise check the username/password against the old user table. This is done by converting the password into a MD5 Hashed string, and searching for the combination UserName/(hashed)Password in the old user table. If successful, we can then re-create that user in the .Net Membership Provider using the Membership.CreateUser(UserName, Password(In clear text)) function. I would then, for record keeping's sake, set a newly created column within the old user table to True for disabling that record or at least signifying the transfer of that User to the new Provider.

-October 12. 2007 09:04

rusty swayne said...

Nice, out witted by my own padwan. Nicely done Frieder!!!

-October 12. 2007 09:27

Wayne said...

What? MD5 is salted? Are you sure. Probably a case of Encoding. To MD5 Hash you need to encode from a string to a Byte array. SQL server does this for you when you do a HashByte function call -- however it is tough to tell what Encoding they used, ANSI, Unicode UTF??? To bad I didn't read this earlier.

-Wayne

-October 31. 2007 20:59

rusty swayne said...

I am pretty sure it is a correct that the md5 value is salted in when the membership provider creates a user. I thought this had to be wrong as well and looked all over for any configuration(s) settings to the membership provider I may have missed. All I did find was various people with the same issue (albeit many of them may not be credible).

I messed with it for a few hours and had to move on, but am very interested in getting this figured out as I am certain this issue will come up again if I have to port any other site's users with MD5 passwords to the membership provider.

-November 1. 2007 02:09