Is it generally a really bad idea to not use the built-in asp.net membership provider?
I’ve always rolled my own for my asp.net apps (public facing), and really have not had any problems in doing so. It works, and seems to avoid a layer of complexity. My needs are pretty basic: once setup, the user must use email address and password to login, if they forget it, it will be emailed back to them (a new one). After setup there is little that needs to be done to each user account, but I do need to store several extra fields with each user (full name, telephone and a few other fields etc). The number of users that required login credentials are small (usually just the administrator and a few backups), and everyone else uses the site unauthenticated.
What are the big advantages that I might be missing out on by skipping the asp.net membership provider functionality?
Rolling your own authentication system is never a good idea. There are so many ways to get it wrong that still seem to work in testing, until a year later when you find out your site was cracked six months ago.
Always lean as much as possible on the security code provided for you by your platform, be it asp.net or anything else. Do this, and the system is supported by a vendor with many more deployments so that bugs can be found and fixed more easily, and even if you do have a problem you can place the blame on the vendor when your boss comes asking about it. Not to mention that once you get past the first time using your vendor’s solution, additional deployments will be faster. This is just the right way to do it.
The ASP.Net Membership provider is far from perfect, but I promise you that it’s preferable to building it from scratch.