Is *not* using the asp.net membership provider a bad idea?

Rolling your own authentication system is never a good idea. There are so many ways to get it wrong that still seem to work in testing, until a year later when you find out your site was cracked six months ago.

Always lean as much as possible on the security code provided for you by your platform, be it asp.net or anything else. Do this, and the system is supported by a vendor with many more deployments so that bugs can be found and fixed more easily, and even if you do have a problem you can place the blame on the vendor when your boss comes asking about it. Not to mention that once you get past the first time using your vendor's solution, additional deployments will be faster. This is just the right way to do it.

The ASP.Net Membership provider is far from perfect, but I promise you that it's preferable to building it from scratch.

The advantages of the provider model are outlined here, but in brief:

1. Certain out-of-the-box webcontrols are built to use the membership provider model, such as the Login control/view and the Create User Wizard. So you miss out on a 1-step configuration for having a logged-in dashboard for all your pages without writing any code.

2. Providers can be swapped with a simple change in the web.config file. Not saying you can't write your own login stuff to do the same, but you can easily write a custom provider at some point down the road and switch it into your application without changing a thing in the application.

3. All the basics are provided. The default membership providers have password retrieval, account locking, multiple password encryption methods, valid password restriction rule configuration and user management, all out of the box. Just using that alone is a huge reduction in setup time for most people starting an ASP.Net application from scratch.

4. A large component of your application is already vetted. You don't need to worry about debugging all your own authentication code! This means that when there are bugs, you often get fixes before site breaks, and you have the ability to pass the blame if not.

I agree with Ayende's feelings about this:

It is a huge API, it makes a lot of assumptions and it is really not nice to work with in terms of what it gives you and what you have to implement

This is also my experience. Anytime that I've implemented my own membership provider (twice at the time of this writing) I left the vast majority of the overridden methods unimplemented, because I was never going to call them and I wasn't using any of the web-forms controls that make use of them.

The Sql and Active Directory providers are great if they meet all of your needs. But if they don't and you are thinking of implementing the providers, there may be a better way for you.

Don't confuse the MembershipProvider with FormsAuthentication, which I still rely on regularly for my applications. This is the mechanism that takes care of wrapping the user's authentication token in a cookie and passing between client and server. There's nothing wrong with FormsAuthentication as far as I know and I wouldn't suggest reinventing it.

If you don't want to implement dozens of MembershipProvider methods, RoleProviderMethods, and ProfileProvider methods then just implement IPrincipal and IIdentity and just do what you need to do. Here's an example of getting those 2 interfaces working with FormsAuthentication, which is trivial.

Also, be aware that you need to be smart about storing your users' credentials. The SqlMembershipProvider does can at least store hashed salted passwords. Be sure you at least do the same. Here's a nice piece of code to help out with this. Notice the slow hashing algorithm used. Don't do drugs.

update (2013-12-16)

Things have changed in ASP.net since I wrote this. ASP.NET Identity replaces the Membership features from before.

My recommendation is to use the new stuff because:

• You can implement various interfaces to compose a solution that meets your needs. This means you can implement that parts you want and ignore that parts you don't.
• You can completely change where/how you store the identity data, while retaining the default implementation controlling how passwords get hashed.
• OAuth and OpenID features.
• You can use the same system in any framework built on OWIN.

The API is slightly more complicated than before, but more flexible.