Membership is not the same as Forms Authentication

Using Forms Authentication in an ASP.NET application is comprised of two steps:

1) Verify the user’s identity.

2) Authenticate subsequent requests from the user.

For #1: To verify a user’s identity we need to determine what database to consult. This can be done with a custom database or this can be done with Membership API and the MembershipProvider model.

For #2: To authenticate subsequent requests from the user we need a way to correlate requests from the same user and typically we use a cookie-based scheme. Forms authentication provides a framework for this and it implements it in a secure manner. Using Session to track the user is also a cookie-based scheme but it was not designed for security and should be avoided (in addition to all the other reasons).

Forms Authentication issues a cookie and embeds the username inside the cookie. Upon subsequent requests to the server Forms reads the cookie, validates it, extracts the username and assigns the username to User.Identity.Name (as well as Thread.CurrentPrincipal.Identity.Name).

To implement the cookie-based scheme securely Forms Authentication does several things:

1) Protects the cookie by encrypting and MACing it. This provides protection against people reading the cookie (including the user) and tampering with the value (including the user).

2) Provides a secure timeout on the cookie. Forms does not rely upon the normal cookie timeout — the user could easily change this. Instead Forms embeds the cookie timeout in the encrypted/MAC’d cookie value.

3) Sets the cookie as HTTP-only. This prevents client-side JavaScript from accessing the cookie (Session, to its credit, does this as well).

4) Allows the cookie to be marked as SSL-only. This, unfortunately, is not the default nor required (but I think it should for both… well, at least the default). The way this is configured is to set in web.config:

<system.web>
  <authentication mode="Forms">
    <forms requireSSL="true" />
  </authentication>
</system.web>

This will configure Forms to only allow the cookie to be issued if the login request is using SSL. It also configures the browser to only send the cookie back to the server if the request is SSL.

Protecting the request that contains the login information is obvious, but protecting the cookie on subsequent requests is equally important. We don’t want the cookie intercepted on the network and then replayed by an attacker. This is often overlooked or dismissed as not important, but think about it — if the page being requested needed authentication in the first place (presumably because it contained sensitive data like banking or healthcare information) then would we want the contents intercepted by an eavesdropper? I don’t think so, so we need to protect both the cookie and the contents of the page. It’s imperative that SSL be used for any request that uses authentication.

So, the important aspects of security really revolve around Forms Authentication and not Membership. And in fact you don’t need to use Membership to use Forms Authentication. Membership is just an abstraction around a database look-up. It’s important to distinguish and understand what each does so that you can understand how your security is really working and evaluate which pieces you really need and want.