Drill Down on Authentication (Continued)

It's worth noting that forms authentication is merely a framework for building an authentication system, rather than an all-in-one system that's complete and ready to use. Fortunately, creating the login page for forms authentication doesn't require a lot of work.

The new Membership API, on the other hand, includes a prebuilt login control that you can use either on a separate login page or within any page of your application that provides a prebuilt login user interface. This user interface is customizable and communicates with the Membership API to log the user in automatically. The control does most of the work of creating custom login pages. In most cases, creating a custom login page requires nothing more than adding an ASPX page to your solution with a login control on it. You don't need to catch any events or write any code if you are fine with the default behavior of the control (which will usually be the case).

When you use forms authentication, you are responsible for maintaining the details of the users who access your system. The most important details are the credentials that the user needs in order to log into the system. Not only do you need to devise a way to store them, but you also need to ensure that they are stored securely. You also need to provide some sort of administration tools for managing the users stored in your custom store.

The Membership API framework ships with a prebuilt schema for storing credentials in a SQL Server database. So, you can save lots of time using this existing (and extensible) schema. Still, you are responsible for backing up the credentials store securely, so that you can restore it in case of a system failure.

Intercept Network Traffic
When a user enters credentials for forms authentication, the credentials are sent from the browser to the server in plain-text format. This means anyone intercepting them will be able to read them. This is obviously an insecure situation.

The usual solution to this problem is to use SSL. Now, a valid argument might be that you just need to use SSL for securing the login page, not the entire application. You can configure forms authentication to encrypt and sign the cookie, which makes it extremely difficult for an attacker to get any information from it. In addition, the cookie should not contain any sensitive information and therefore won't include the password that was used for authentication.

But what if the attacker intercepts the unencrypted traffic and picks only the (already encrypted) cookie and uses it for replay? The attacker doesn't need to decrypt it; she just needs to send the cookie with her own request across the wire. You can mitigate such a replay attack only if you run the entire website with SSL.

Other authentication mechanisms don't require this extra work. With Windows authentication, you can use a protocol that automatically enforces a secure login process (with the caveat that this is not supported by all browsers and all network environments). With Passport authentication, the login process is handled transparently by the Passport servers, which always use SSL.

Cookie authentication is a fairly straightforward system, on its surface. You might wonder why you shouldn't just implement it yourself using cookies or session variables. The answer is, for the same reason developers don't implement features in ASP.NET ranging from session state to the Web control framework. Not only does ASP.NET save you the trouble, but it also provides an implementation that's secure, well tested, and extensible. Some of the advantages provided by ASP.NET's implementation of forms authentication include the fact that cookie authentication is secure and forms authentication integrates with the .NET security classes.

Cookie authentication seems simple, but you can be left with a highly insecure system if you don't implement this properly. On their own, cookies aren't a safe place to store sensitive information because a malicious user can view and edit cookie data easily. Attackers can compromise your system easily if your authentication is based on unprotected cookies.

By default, the forms authentication module encrypts its authentication information before placing it in a cookie. It also attaches a hash code and validates the cookies when the cookies return to the server to verify that no changes have been made. The combination of these two processes makes these cookies secure. It also saves you from having to write your own security code. Most examples of homemade cookie authentication are far less secure.

Forms authentication is an integral part of ASP.NET. As long as you keep up-to-date with patches, you should have a high level of protection. On the other hand, if you create your own cookie authentication system, you don't have the advantage of this widespread testing. The first time you'll notice a vulnerability will probably be when your system is compromised.

Use Forms Authentication Classes
All types of ASP.NET authentication use a consistent framework. Forms authentication is fully integrated with this security framework. For example, it populates the security context (IPrincipal) object and user identity (IIdentity) object, as it should. This makes it easy to customize the behavior of forms authentication.The most important part of the forms authentication framework is the FormsAuthenticationModule, which is an HttpModule class that detects existing forms authentication tickets in the request. If the ticket isn't available and the user requests a protected resource, it automatically redirects the request to the login page configured in your web.config file before this protected resource is even touched by the runtime.