Home/ Questions/Q 741855
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-14T08:40:51+00:00

I’ve been researching this intensely for the past few days. We’re developing an ASP.Net

  • 0

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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0