The ASP.NET Forms Authentication replacement Microsoft doesn't want you to see

On August 3rd, we published a blog post on how to replace ASP.NET forms authentication with accompanying example source code. Both the code and the post were pulled down a few hours later, but we're happy to report that both are now back up. This post describes why we removed the blog post, why it's now back up and provides additional details on why we think having an alternative to ASP.NET authentication solution is a good idea.

We pulled down the post on Friday because we got a note from people at Microsoft who were worried that the solution we had published was unsafe. We were pretty confident in the implementation but given the gravity of the matter we felt that this was the best thing to do. In the end, Microsoft named no vulnerabilities and were primarily concerned that our motivation for replacing ASP.NET forms authentication (as outlined in a February blog post) was wrong*. To recap, our argument is that the forms authentication cookie payload format changes semi-frequently with .NET updates and that causes problems for application maintainers. By using your own authentication implementation (like the one we published), you control the cookie format and when it changes.

Invalid cookies is not only one reason why we think an alternative is relevant. ASP.NET is somewhat unique among major web application frameworks in that only one authentication solution is available. Having multiple alternative authentication solutions means that a weakness discovered in one of them won't let an attacker bring down all ASP.NET sites on the web. This decreases the incentive to try and break any one implementation and that makes everyone safer.

The way Forms Authentication is baked into the .NET Framework also poses some challenges:

1. Changing the mechanism is difficult because it requires publishing security advisories, conducting outreach and rolling out Windows and .NET Framework updates
2. Encryption keys (from the MachineKey configuration element) can potentially be used for multiple purposes. This increases the risk that a key is obtained by an attacker by analyzing other encrypted payloads
3. Forms Authentication is not very extensible and implementing something like revocable sessions is difficult

Lastly – and this is a nitpick compared to the points above – we think standard Forms Authentication tends to saddle unwary developers with poor application design. The most expedient way to get started with Forms Authentication is to use the aspnet_regsql to auto-generate tables required to store users, roles and membership info. Developers then end up with users records stored either in a database separate from the database that stores application records or in disjointed table systems that are hard to combine. Not exactly the Pit of Success. Our implementation may take a little more effort to add to an existing project, but we think it's much easier to integrate well.

We're excited to make this sample available again. We welcome and look forward to your scrutiny, comments and any pull requests the ASP.NET community might have. With this release, we want improve choice for ASP.NET developers and – with your involvement – help you create better and more secure applications running on the ASP.NET platform.

--

* To be fair, Microsoft did eventually allude to one potential weakness, namely that cookies were not HMAC signed. We had already identified this problem and the example code has been updated.