Is there ever a reason to write your own authentication instead of using Forms Security

Question

In ASP.Net, is there ever a reason to flatly make your own authentication instead of using Forms Security(and writing a custom provider)?

What limitations exist to Forms Security and why would someone want to write their own authentication?

Answer 1

One of the limitations of the out-of-the-box providers is the ProfileProvider. It stores all of the profile information for a user in a single database field, making it difficult to query directly.

Luckily there is a good Table based provider described here in Scott Guthrie's blogg: http://weblogs.asp.net/scottgu/archive/2006/01/10/435038.aspx

But generally, i would use the standard Membership provider and controls. They are well tested and they save a lot of coding.

Apart from that, the use of Guids foir all of the Ids annoys me as I prefer ints. I know, Guids are not limited to a couple of billion users, but none of my sites have had that many people register yet.

Answer 2

I've used ASP.NET Membership extensively and have written several website security schemes in .NET.

I don't know of any gaping security holes in .NET Membership. There are some various concerns such as storing login credentials in a database, but for most purposes you can configure the Membership options so it's relatively safe. You can add password salt, minimum/max pass length, complexity options, pass attempts, etc. In some larger companies they prefer to use ActiveDirectory or Kerberos authentication because the accounts can be controlled by domain or zone admins. .NET Membership DOES support those authentication methods.

The biggest issues I have run into using it are:

1. The API itself isn't really abstracted to the level (and with the power) that it needs to be. If you need to programatically delete a user or reset a password, while completely possible, it's more work than you'd expect if you're not using the .NET login/account controls, which you probably won't be as they are geared towards the user and not toward account management.
2. There's no built in web services to access the accounts, which isn't always necessary, but it would have been nice.
3. Managing accounts is a bear as you have to write your own controls for it, and point #1 makes that a cumbersome task. There are several 3rd party controls you can purchase to make this more bearable.
4. Extending the capabilities with things like subgroups/subaccounts, tiered roles, etc can be very hackish and challenging.

In agreement with Daniel, though, for most purposes it works fine and will save you a lot of work. It's tested, it has a truckload of options, and it works well.

Answer 3

Writing your own login controls has long been a recipe for disaster. In fact, I think it was flagged as an OWASP Top 10 (security) problem for a couple of years running.