2

I've been researching this intensely for the past few days.

We're developing an ASP.Net MVC site that needs to support 100,000+ users. We'd like to keep it fast, scalable, and simple. We have our own SQL database tables for user and user_role, etc. We are not using server controls.

Given that there are no server controls, and a custom membershipProvider would need to be created, where is there any benefit left to use ASP.Net Auth/Membership?

The other alternative would seem to be to create custom code to drop a UniqueID CustomerID in a cookie and authenticate with that. Or, if we're paranoid about sniffers, we could encrypt the cookie as well.

Is there any real benefit in this scenario (MVC and customer data is in our own tables) to using the ASP.Net auth/membership framework, or is the fully custom solution a viable route?

Update: I found one person (Matt Briggs) who seems to have come to some of the same conclusions I have: This comes from this link: http://webcache.googleusercontent.com/search?q=cache:Xm1-OrRCZXIJ:mattcode.net/posts/asp-net-membership-sucks+asp.net+membership+sucks&hl=en&gl=us&strip=1

ASP.net membership is a poorly engineered API that is insecure out of the box, is not well maintained, and gives developers a false sense of security. Authentication is a weekend project if you aren't building a framework, but still, most .net developers blindly follow the official APIs, assuming that a major corporation like MS can put out something decent.

alchemical
  • 13,559
  • 23
  • 83
  • 110
  • See also http://stackoverflow.com/questions/440568/why-should-i-use-asp-net-membership-security-model/2656896#2656896 – Ian Mercer Apr 17 '10 at 02:11

5 Answers5

7

One of the first rules of creating a secure authentication system is that you shouldn't try to build the framework yourself. There are many pitfalls that can be easily overlooked. So, I would say unless there is an overwhelming reason to do otherwise, you should use an existing framework like the MembershipProvider.

To list "the benefits" requires listing all security measures that were taken by the FormsAuthentication classes which is a long list. Off the top of my head, I can think a few:

  1. Hashes of passwords
  2. Protection against SQL injection
  3. Protection of the cookie that stores the authentication ticket
  4. Use of and storage of a ticket instead of say a username in the cookie.
  5. Checking on every page to ensure the user is authenticated
  6. Population of the IPrincipal and IIdentity for the current user
  7. Redirection after login (granted a feature)
  8. Handling of failed login attempts
  9. Locking and unlocking users
  10. ActiveDirectory integration
  11. Ability to easily set and change password length and complexity requirements.
  12. Salting (from Hightechrider) ....
Thomas
  • 63,911
  • 12
  • 95
  • 141
  • 1
    What specific pitfalls are you talking about? I'm looking for clear, specific benefits that the framework offers. – alchemical Apr 17 '10 at 01:28
  • @alchemical - I've updated my post. Microsoft has taken great pains to provide a feature rich, relatively simple library for doing authentication. Why try to reinvent the wheel? – Thomas Apr 17 '10 at 01:51
  • A good check list, but nothing hard. Add #12 - Salting. Of course it also offers #13 - "Ability to store unencrypted password in the database" which is just such a bad idea. – Ian Mercer Apr 17 '10 at 02:02
  • @Hightechrider - Out of the box, I believe the default setting is to use Hashes for passwords. I.e., you have to go out of your way to make it insecure. – Thomas Apr 17 '10 at 02:05
  • @alchemical - Your link at the top is broken. – Thomas Apr 17 '10 at 02:06
  • @alchemical - You claim that the Membership classes are insecure. Proof? What evidence do you have that they are insecure if properly configured? – Thomas Apr 17 '10 at 02:07
  • That wasn't my claim, that quote was from the blog page--I just fixed the link at the top. – alchemical Apr 17 '10 at 02:47
  • @alchemical - First, the article is mostly a rant and most of that rank is about lack of extensibility and the author's difficulty in implementing a custom provider. Second, he provides no support to the claim that the MP model is insecure. In fact, his arguments revolve around session security and not MP security and they are different and his information is dated. If there are specific features that you require that it does not provide and can not be built with a custom provider, then that would be different. I have a couple of other links that I'll add to my post. – Thomas Apr 17 '10 at 04:18
  • 1
    Its not that there are features it doesn't provide--its that the amount of code it takes to get what I need looks to be about the same amount needed to implement a custom provider. Only if I go completely custom, I end up with vastly simpler code organized in a way that makes sense for my particular project. – alchemical Apr 17 '10 at 04:49
  • @alchemical - Well, I cannot seem to find the links I was seeking however, I did find someone that implemented a MP for OpenID (http://openidmembership.codeplex.com/http://openidmembership.codeplex.com/). Yet another reason to use the MP architecture, contrary to Mr. Briggs, it is extensible and by because it is you have resources available to drop new MP in when desired. – Thomas Apr 17 '10 at 04:59
  • @alchemical - What specific feature(s) are you seeking that say the standard SQL MP does not provide? – Thomas Apr 17 '10 at 05:00
4

I wrote my own after reading through all the stored procedures in the ASP.NET Membership provider. It's not hard and you have much more control at the end of the day.

If you like XML configuration, weakly-typed strings for roles, insecure by default, random web.config files littered through your directories instead of a clean marker interface on your page classes to say 'no account required', multiple database hits for a single login, user objects that aren't loaded from your current ObjectContext/DataContext and the ability to change providers on the fly (woo hoo, who uses that?!) go for the built-in one.

If not, build your own, but if you do, make sure you add salt and encrypt your passwords, and do a proper encrypted cookie please.

Ian Mercer
  • 38,490
  • 8
  • 97
  • 133
2

Just to clear up a potential misconception, using the customer ID, encrypted or not is extremely vulnerable to sniffers. What you want to do instead is create a log in ticket at the time of successful authentication and store that ID in the cookie. This won't protect sniffers from stealing sessions, but at least the session (eventually) expires whereas the customer ID does not.

Spencer Ruport
  • 34,865
  • 12
  • 85
  • 147
  • I see, so you suggest one additional level of abstraction. I think that's reasonable and not too terribly bad to implement. Isn't Membership storing the UserID in the cookie? From MSDN: "You can store one value in a cookie, such as user name and last visit." – alchemical Apr 17 '10 at 01:33
  • It could be, and you can. It's just important that you don't use that for determining if a user is authenticated. If you want to say "Hello <%=Username%>" there's no danger if a hacker spoofs the value. On the other hand if you try `if(IsAdmin(Username))` you could get yourself in trouble. – Spencer Ruport Apr 17 '10 at 19:39
0

You can implement your own membership provider (as you mentioned) if you wish to have your own storage. One advantage is that you can administer memberships through IIS' .NET users configuration tool.

The biggest advantage is what the others stated already; why reinvent the wheel?

If you implement your own custom login UI using MVC you could reuse also when switching for a different membership provider.

  • We will not be using the user config tool as there will be a massive number of members, any member admin tools will have to be custom. Regarding wheels do you drive an ox Cart or a Camry to work? :) – alchemical Apr 17 '10 at 01:30
  • It could still be useful if you can swap out the membership provider, for instance for testing purposes. Of course it's not all the complicated to implement your own provider model. Just have to get the cookie thing right. Don't forget the cookieless authentication ASP.NET supports either.. –  Apr 17 '10 at 01:36
  • Can use the FormAuthentication bit and the cookie part without any form of Membership Provider: http://stackoverflow.com/questions/2077858/using-forms-authentication-without-net-providers –  Apr 17 '10 at 01:53
  • It's not all about "why reinvent the wheel". If that's how you architect your applications with cookie cutter approaches to everything you might as well say you can't code. If it's a GOOD implementation that you can grab and run with to reduce your time and code fine, but this membership provider is complete trash for large websites. – PositiveGuy Feb 04 '12 at 07:04
  • @CoffeeAddict thanks for the downvote, almost 2 years after. The question is, what is the value if any. I attempted to find some. I agree the membership provider is trash. Not so much the authentication mechanics, which is fine and which you can use without the membership provider. –  Feb 17 '12 at 01:54
0

You can customize to build your own provider. Behind the scenes the Membership provider uses the same FormsAuthentication implementation as you will write. Anyway, I have read that the main issues about the performance you will face will be related to the SQL SERVER stored procedures that retrieve the data. In one of the books about building a portal system by Omar Al Zabir he mentions some improvements to the stored procedure which can result in faster performance.

azamsharp
  • 19,710
  • 36
  • 144
  • 222