0

I was wondering if using the out of the box aspnet membership provider, account controler, database schema etc. (ootb login/register system as a whole) for a public facing website is ok?

  • I know that there are a lot of extra things on it that are unneeded, but would like to save time not having to create one from scratch
  • I definetly plan on extending it to fit custom needs

Are there any vulnerabilities or is it just the fact that there's a lot of unneeded stuff that defers users from it?

anthonypliu
  • 12,179
  • 28
  • 92
  • 154
  • I do not think that have anything extra and unneeded things. For the vulnerabilities you can read: http://stackoverflow.com/questions/2498599/can-some-hacker-steal-the-cookie-from-a-user-and-login-with-that-name-on-a-web-s – Aristos Jul 24 '12 at 18:53
  • What is the extra stuff? – Jupaol Jul 24 '12 at 18:53

1 Answers1

0

In my last project I have discarded Membership in favor of WIF based solution. On authenticate I write encripted session cookie, that contains user identity, and later use SessionAuthenticationModule to set principals from cookie. Works like a charm and I have full control of database and user storage. And also it allows some complex stuff like ActsAs, Federation etc.
If it is public site, maybe you will add some OAuth stuff with autoregistration. It will be much cleaner with your own storage schema. And also membership dictates RBAC type of authorization. Personaly, havent seen projects that were ok with just simple IsInRole.

This is just IMHO =) Also note, that .Net 4.5 will include WIF in core..

Aleksei Anufriev
  • 3,206
  • 1
  • 27
  • 31