0

I use .net membership but everything what i work i want to be custom.

What i want to do is:

  1. Create custom data table [Users] with custom fields
  2. Import current data into new table
  3. Create custom classes and functions about everything what i need for [Users]

I`m not sure how .net membership works, but maybe it send encrypted cookie then when i use

var user = Membership.GetUser();

.Net decrypt user cookie and know which user is.

Here is a screenshot how .net create user AUTH cookie http://prntscr.com/97043

But everytime user logout-login, this value is different.

So what i want to know is:

  1. Lets say i want to make 100% custom website, how i can make custom login?
  2. Can you tell me all security issues about going for custom membership?
Novkovski Stevo Bato
  • 1,013
  • 1
  • 23
  • 56
  • did you ever saw my answer on the same subject? http://stackoverflow.com/questions/5701673/custom-membershipprovider-in-net-4-0/5702000#5702000 – balexandre May 13 '12 at 15:44

2 Answers2

1

None of this is necessary. You can create your own users table without the need to alter anything related to Membership or authentication. You just make sure that your users table has a column called AspNetUserID or similar of type uniqueidentifier (a guid) . You put the ProviderUserKey from the MembershipUser in this table and lookup any user in your Users table simply by getting the ProviderUserKey from Membership.

So, for example, you might do this:

var userid = Membership.GetUser().ProviderUserKey;

// lookup your record in users based on userid above
Erik Funkenbusch
  • 92,674
  • 28
  • 195
  • 291
0

Implementing a custom backend isn't difficult. You simply implement a custom MembershipProvider that stores and retrieves the data from your users table as you see fit. see MSDN. Also, you don't have to entirely rewrite SqlMembershipProvider, you can subclass it and add the functionality you're looking for.

If you really want to start from scratch on the backend, here are some issues to note:

  • Don't store passwords in plaintext anywhere; hash them.
  • Salt your passwords
  • Log & monitor password resets

Also, you don't have to entirely rewrite SqlMembershipProvider, you can subclass it and add the functionality you're looking for, and most of the issues you might run into will be covered by the default implementation. You'd probably just have slightly modify the data access calls or stored procedures to map to your table structure. You can also subclass the SqlRoleProvider to provide role-based authorization for your site with little additional effort.

As for the front-end component, MSDN also describes how forms authentication works, but personally, I wouldn't mess with your own cookie scheme. Even big custom implementations like Oauth for asp.net still use forms. Check out http://msdn.microsoft.com/en-us/library/system.web.security.sqlroleprovider.aspx

Rob Rodi
  • 3,476
  • 20
  • 19