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

Question

Is it generally a really bad idea to not use the built-in asp.net membership provider?

I've always rolled my own for my asp.net apps (public facing), and really have not had any problems in doing so. It works, and seems to avoid a layer of complexity. My needs are pretty basic: once setup, the user must use email address and password to login, if they forget it, it will be emailed back to them (a new one). After setup there is little that needs to be done to each user account, but I do need to store several extra fields with each user (full name, telephone and a few other fields etc). The number of users that required login credentials are small (usually just the administrator and a few backups), and everyone else uses the site unauthenticated.

What are the big advantages that I might be missing out on by skipping the asp.net membership provider functionality?

Answer 1

If you've got a solution that works well, stick with it. "If something works, don't fix it" and all that. Otherwise, consider that the Membership API has thousands of times the number of programmer-hours, QA-hours and user-hours behind it than anything you could come up with on your own.

Answer 2

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.

Answer 3

How do you save the users' passwords? If you're saving in plain text, that's a major risk. One advantage of the ASP.NET Membership system is that it encrypts passwords by hashing, out of the box.

Answer 4

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.

Answer 5

You might get some insight from these other popular questions:

Which authentication and authorization schemes are you using - and why?

Microsoft Membership Provider Vs Custom Provider Vs Complete Custom Login System

Anyone uses ASP .NET Membership?

Alternatives to .Net Membership

Answer 6

In your case, authenticated users are the exception, not the norm, so it probably doesn't hurt to roll your own.

One thing .net provides is a brute force attack prevention, in case someone tries to brute force the admin password, the admin account will be locked out.

Answer 7

There is more to membership then just membership (login, email, password, and functionality around it). Aspnet separates membership from profile, and they can be integrated. Profile is everything you call 'extra fields'. You can have an anonimous profile with some customization, even if you don't have a membership. For example, a user could setup preferences, return to site, and still have them, but still don't register. Then when you register, anonimous profile can be migrated and associated with your new membership.

That is what you basically miss when you skip it.

Also, if you choose to use build in or third party controls which make use of membership and profiles, you miss it too.

You could implement a provider, instead of dropping the provider model all at once.