30

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?

E.J. Brennan
  • 45,870
  • 7
  • 88
  • 116

10 Answers10

24

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.

Joel Coehoorn
  • 399,467
  • 113
  • 570
  • 794
  • 5
    Although I mostly agree, the basic ASP.NET membership provider contains a whole lot of stuff one not necessarily would need. If I want a clean system, I'd probably roll my own, with just those few methods i need and not use the standard one. Thoughts on this? – Arve Systad Jun 03 '10 at 19:45
  • 6
    Generally with the provider model, you implement only the methods and properties you want to use. The classes are abstract so when you implement you must 'define' (override) the inherited abstract members, but common practice is to add a simple throw `NotImplementedException` in those members you don't want to use. By all means don't actually implement the code for every single method if you aren't going to use it. – KP. Jun 03 '10 at 19:51
  • 1
    Of course, but why not just make a custom class with only the needed methods if you implement all required stuff yourself anyways? Does the base class give you something you cannot easily get by doing it all yourself? – Arve Systad Jun 03 '10 at 19:55
  • 6
    @Arve - yes, it does. Just because it's an abstract class, it doesn't means there's no code in there anywhere. It just means is has some abstract methods that you must implement. There are other methods that are not abstract, and other places in the framework that know how to hook into the stock class in the correct way. **Rolling your own system is a bad idea.** – Joel Coehoorn Jun 03 '10 at 19:59
  • 3
    @Arve The point and advantage of the providers was well documented by `womp` in the answer above. There will be more code no doubt because of the unused members, however it's really a minor point in comparison to advantages gained. Having the least amount of code is not always the best solution. **Go your own way** doesn't trump built-in, pluggable functionality for the sake of a bit of code saved. – KP. Jun 03 '10 at 20:00
  • Asking => Learning. Thanks for the follow ups, Joel and KP! – Arve Systad Jun 03 '10 at 20:02
  • ++ yup. it's not perfect but it's peccadillo are a known quantity with a massive amount of collective experience available to deal with effectively. – Sky Sanders Jun 07 '10 at 06:33
  • What a great post. Thank you all. – Levi Botelho Nov 20 '12 at 07:13
  • Having recently had to review the depths of the ASP.Net Membership Provider, I'm not sure that it's preferable to rolling your own. They have a lot of bad mistakes, some of which simply don't hold up under modern standards, but others which were bad even at the time. They have an insufficient hash, no salt rotation and a poor entropy password generation function just to name the issues I've found so far (at least for the SQL Provider). – AJ Henderson Aug 31 '23 at 19:35
13

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.

Joel Coehoorn
  • 399,467
  • 113
  • 570
  • 794
womp
  • 115,835
  • 26
  • 236
  • 269
  • 1
    Most of these answers aren't reasons for not using your own membership provider. When properly implemented, you still get those things :) – Thorarin Jun 03 '10 at 19:41
  • 2
    That argument could be applied to just about anything. He did specifically ask for advantages. – womp Jun 03 '10 at 19:56
  • 1
    ++ what he said. Unless you have a really compelling reason for wasting your time now and in the future, leveraging existing framework code is typically the best route. – Sky Sanders Jun 07 '10 at 06:31
12

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.

Community
  • 1
  • 1
Ronnie Overby
  • 45,287
  • 73
  • 267
  • 346
4

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.

Bob Kaufman
  • 12,864
  • 16
  • 78
  • 107
4

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

Community
  • 1
  • 1
DOK
  • 32,337
  • 7
  • 60
  • 92
3

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.

George Polevoy
  • 7,450
  • 3
  • 36
  • 61
2

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.

Greg
  • 16,540
  • 9
  • 51
  • 97
2

I feel your pain with the complexities of the built-in ASP.Net authentication. I was tired of having to write code for features that I was never going to use. (as well as leaving a bunch of NotImplemented functions). I also was sick of the difficulties of using something other than a GUID and having multiple database roundtrips on each page load(just for authentication)... So, I rolled my own. It's named FSCAuth and it's BSD licensed.

I've made it a bit harder than ASP.Net's built in authentication to get wrong as well. All of the cookie handling and actual hashing is left to the core of FSCAuth, while all you have to worry about is storing users in the database and controlling what pages need to be authenticated on.

If you're facing the question of ASP.Net's built-in authentication and rolling your own, I suggest you give my authentication library a look first, if not just using it as a starting point.

Earlz
  • 62,085
  • 98
  • 303
  • 499
1

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.

John Rudy
  • 37,282
  • 14
  • 64
  • 100
Dani
  • 1,035
  • 1
  • 9
  • 16
0

I would recommend against using the ASP.Net Membership Provider, particular the SQL Server provider. It has several significant problems and does not hold up to modern standards well. They do not rotate the salt at all on password change, which opens up persistence of attack if there is an open DB compromise. They do not have a well done password generator which leads to lower than desirable entropy in generated passwords. They also do not have a sufficient password hashing algorithm out of the box for modern standards (though this can be overcome.)

AJ Henderson
  • 1,120
  • 1
  • 12
  • 32