Disadvantages of building an Asp.net mvc 3 without

Question

Are there any fundamental drawbacks to not using the MembershipProvider for an asp.net mvc 3 application besides having to write everything yourself? I'm wondering if there is something bigger I'm missing that it makes much easier.

Would the authorize attribute work on controllers?

Thanks.

Answer 1

Implementing membership yourself is very tricky. You can build & debug it and it will seem to work, but you [may] not realize that your schema is hackable. And in most cases it's discovered when it's too late.

For example: The algorithm used to save the logged-in user's encrypted cookie. If it can be predicted or calculated, an hacker will easily enter your application on behalf of another user. Another potential security issue could be if you use the wrong algorithm to encrypt/salt users' passwords in the database (as far as I know, Sony had clear text passwords that were revealed once the hackers breached inside. But I'm not sure about that.)

Besides serious security issues, implementing MembershipProvider gives you out of the box a set of features like account lockout, password strength enforcement, password expiry enforcement, optional roles scheme etc.

Answer 2

You lose out on speed and security (like ofer mentioned), though you gain in flexibility/customization, and probably a good but hard learning experience

Answer 3

AuthorizeAttribute is in no way dependent on ASP.NET membership. It just looks at the HttpContext.User. Anything which sets that will work.

The biggest drawback to "doing it yourself" is that most people, even experts, make mistakes doing this. Authorization is hard, and it is, in the end, far less work to search far and wide for an off-the-shelf solution which works than to recover from making national news by trying to do it yourself.

If you think that doing this yourself makes things "much easier," then you are almost certainly underestimating the scope of the problem.