All geek questions in one place

ASP.NET Membership: To Be Or Not To Be?

I am thinking about how to implement authorization and authentication using ASP.NET and MVC2. Let's consider this as a user system.

I have seen three types of solutions in the wild:

I read your knowledgeable thoughts, and many say that trying to overturn your own “user system” can even be dangerous if you are not careful with security details. On the other hand, the solution is much simpler. Everything is probably stored in one database, and user material is in the same user table. The overhead for this solution seems rather low.

Using an ASP.NET Membership Solution allows you to use a lot of off-the-shelf functionality, but IMHO is really confusing. You probably need to save the membership material in your own database and somehow connect the user object with your specific database to the ASP.NET site.

If you are using ASP.NET Membership

  • What does your database schema look like? How do you create external relationships with ASP.NET membership users (i.e. Songs <=> FavoriteSongs (<=> SiteUsers) <=> aspnet_Users)?
  • Why didn’t you make your own?

If you made your own

  • What layer of user system abstraction, if any, did you use?
  • Why didn’t you use ASP.NET membership?

I am truly paralyzed by analyzing these possibilities. Please hit me in the right direction from this sticky web of membership paralysis! Thanks.

+4
source share
2 answers

The built-in membership provider is already secure and really REALLY easy to use. After a couple of hours, you can start with built-in membership. Alternatively (depending on what type of application you are creating) you can also check with OpenID , which uses StackOverflow.

In addition, with the built-in membership provider, creating links is as simple as using a "uniqueidentifier" to link the aspnet_User table (I can't remember the exact name from the top of my head) to the linked table.

I keep all my “elements” of my membership in the same database as the db system, and it never led me astray. Creating membership "stuff" is also easy. Just run aspnet_regsql.exe against the database in which you want to have asp.net membership

Here's another SO question on the same lines.

+1
source

Many people choose not to minimize their own authentication systems for a good reason! This is quite dangerous, and there are many small ways in which you can make a mistake and leave your site open to attack.

However, I am one of those risk participants and really give up my own. I double and triple checked every line of code for a lack of security, and so far I have not had any security fixes since I released 1.0 of my authentication system. Anyway, my authentication system is called FSCAuth and is licensed by BSD.

  • What layer of user system abstraction, if any, did you use?

I do not quite understand what you mean. I basically have one layer where user data is retrieved and written to / from the database. One layer where FSCAuth actually deals with cookies and HTTP authentication. And one layer where you tell FSCAuth that "hey, this page should only be displayed if the current user is in the Administrator group.

My UserData class is pretty simple, only 4 fields are required: Username, PasswordHash, UniqueID and Salt. FSCAuth depends on it. If you need more fields, you can inherit the form of the UserData class, and it will work the same way.

  • Why didn’t you use ASP.NET membership?

I found so many short events in ASP.Net authentication built

  • A lot of code needs to be written if you want to use anything other than the built-in membership provider.
  • Sometimes you have to deal with cookies, which, I would say, is dangerous.
  • Almost impossible to use Blowfish hash algorithm
  • Multiple database accesses for each page load
  • Session sessions (when the user logs in, the record goes to the database), which makes it difficult to expand to several servers and, as a rule, creates more unnecessary stress on your database server.
  • Clear authentication (can see the identity of a person, not a person) is more difficult than I would like
  • GUIDs

Many of these problems are by design, and I think this is a symptom of trying to make one software that satisfies everyone.

Well, in FSCAuth I left quite a few things on the design, and to be honest, this is not suitable for everyone, but it is much simpler than using ASP.Net in many common scenarios. It can use almost any hashing algorithm under the sun. The only remote authentication database. Entrance without taking into account the state. A unique identifier can be anything that fits on a string. Etc.

So, if you are stuck in a decision to use ASP.Net Integrated Authentication and collapse your own, give FSCAuth first. If nothing else, this is a great starting point for your own.

0
source

Source: https://habr.com/ru/post/1313334/

More articles:


All Articles