Analysing Forms Authentication
Introduction
If you've ever used ASP.NET to create a website that requires that users login to view certain pages or to have access to particular features, then you've no doubt examined ASP.NET's forms-based authentication scheme. ASP.NET's forms-based authentication allows you to quickly and easily build a website that authenticates users through a forms-based approach. Namely, to identify themselves, a user will enter their credentials in a Web Form. (Credentials could be anything, really, but for websites they are typically just a username and password. However, some websites require more involved credentials, such as a username, password, and PIN.) After a user enters their credentials, they are "logged in" to the site.
The Forms-Based Authentication Workflow
Before we begin our dissection of ASP.NET's forms-based authentication, let's take a brief moment to examine the forms-based authentication workflow from both the end user's perspective and the page developer's perspective. While reading the end user and page developer point of views be sure to keep in mind that authentication is the process of identifying a user, nothing more, nothing less. So forms-based authentication is simply identifying a visitor and doing so using a forms-based mechanism. (That is, the user enters their identifying credentials through a form on a web page.)
From the end user's point of view, when visiting a site they are typically allowed to login by entering their name and password. Alternatively, if they attempt to visit a page that they need to be authenticated in order to access, they'll automatically be sent to the login page. At the login page, our end user will enter her credentials - typically a username and password - and click a button. Assuming their credentials are valid, they'll then be "logged on" to the site. Once our end user is logged on, she can visit any number of pages on the site and be remembered - that is, she need not re-enter her credentials unless she's closed her browser or explicitly logged out. (Some financial sites or sites that are commonly visited through public terminals will automatically log out a user after a period of inactivity.)
This workflow is one both end users and most page developers are familiar with. What it fails to answer, however, is how, exactly, is a user "logged in?" As a user bumps from page to page in the site, how does the site remember that the user is, indeed, "logged in?".
Remembering That a User is Logged In
There are a variety of techniques for maintaining state on a website - querystring parameters, POST parameters, cookies, session variables, and the web server's cache are the most common techniques. With forms-based authentication we clearly need some state management in that the user's "logged on" status must be remembered across multiple page visits. We don't want to force the user to have to re-login every time she visits a new page on our site.
So how can we remember this data? One approach, and an approach used commonly in the days of classic ASP, would be to use a session variable that would indicate whether or not a user had successfully logged in. (See the article Simple Authentication for a look at using session variables in a classic ASP setting for more information.) While this approach definitely works, one downside is that this login data cannot be persisted across the length of a session. That is, with session variables the state is lost once a user's session expires, which happens when they close their browser or are inactive for a duration greater than the site's session timeout. But many sites that utilize forms-based authentication allow the end user to check a 'Remember Me' checkbox that allows the user to login just once at their home computer and not need to re-enter their login credentials, even days later after having shut down their computer. In fact, you can configure forms-based authentication to work in this manner. Both the SetAuthCookie() and RedirectFromLoginPage() have as their second parameter a Boolean that indicates whether or not the user's "logged in" state should persist even after the user's session has ended.
Clearly session variables are not at play with forms-based authentication; instead, cookies are used, which might have been obvious enough given the fact that the method to login a user (SetAuthCookie()) has the word 'Cookie' right in it! Cookies are small text files saved on the client's computer that are sent to the corresponding website with each request. Ok, so at this point we know we will be using cookies to store authentication information, but this still leaves us with two questions:
What state do we need to maintain in this cookie, and
How can this state be saved so that it can't be read by nefarious users and can't be spoofed (that is, we don't want to allow someone to fake us out and be able to simulate the state that indicates that they're logged in).
Conclusion
In this article we looked at ASP.NET's forms-based authentication in greater detail. Specifically, we saw how forms-authentication "remembers" that a user is logged in across visits to the website's pages - namely, it uses an authentication ticket stored in a cookie. Working with cookies in this manner can introduce a number of security concerns if not done correctly. To address these issues, the ASP.NET authentication ticket is, by default, both encrypted and digitally signed to ensure that the contents haven't been tampered with. Hopefully this article has provided a bit more information on the internals of forms-based authentication!
If you've ever used ASP.NET to create a website that requires that users login to view certain pages or to have access to particular features, then you've no doubt examined ASP.NET's forms-based authentication scheme. ASP.NET's forms-based authentication allows you to quickly and easily build a website that authenticates users through a forms-based approach. Namely, to identify themselves, a user will enter their credentials in a Web Form. (Credentials could be anything, really, but for websites they are typically just a username and password. However, some websites require more involved credentials, such as a username, password, and PIN.) After a user enters their credentials, they are "logged in" to the site.
The Forms-Based Authentication Workflow
Before we begin our dissection of ASP.NET's forms-based authentication, let's take a brief moment to examine the forms-based authentication workflow from both the end user's perspective and the page developer's perspective. While reading the end user and page developer point of views be sure to keep in mind that authentication is the process of identifying a user, nothing more, nothing less. So forms-based authentication is simply identifying a visitor and doing so using a forms-based mechanism. (That is, the user enters their identifying credentials through a form on a web page.)
From the end user's point of view, when visiting a site they are typically allowed to login by entering their name and password. Alternatively, if they attempt to visit a page that they need to be authenticated in order to access, they'll automatically be sent to the login page. At the login page, our end user will enter her credentials - typically a username and password - and click a button. Assuming their credentials are valid, they'll then be "logged on" to the site. Once our end user is logged on, she can visit any number of pages on the site and be remembered - that is, she need not re-enter her credentials unless she's closed her browser or explicitly logged out. (Some financial sites or sites that are commonly visited through public terminals will automatically log out a user after a period of inactivity.)
This workflow is one both end users and most page developers are familiar with. What it fails to answer, however, is how, exactly, is a user "logged in?" As a user bumps from page to page in the site, how does the site remember that the user is, indeed, "logged in?".
Remembering That a User is Logged In
There are a variety of techniques for maintaining state on a website - querystring parameters, POST parameters, cookies, session variables, and the web server's cache are the most common techniques. With forms-based authentication we clearly need some state management in that the user's "logged on" status must be remembered across multiple page visits. We don't want to force the user to have to re-login every time she visits a new page on our site.
So how can we remember this data? One approach, and an approach used commonly in the days of classic ASP, would be to use a session variable that would indicate whether or not a user had successfully logged in. (See the article Simple Authentication for a look at using session variables in a classic ASP setting for more information.) While this approach definitely works, one downside is that this login data cannot be persisted across the length of a session. That is, with session variables the state is lost once a user's session expires, which happens when they close their browser or are inactive for a duration greater than the site's session timeout. But many sites that utilize forms-based authentication allow the end user to check a 'Remember Me' checkbox that allows the user to login just once at their home computer and not need to re-enter their login credentials, even days later after having shut down their computer. In fact, you can configure forms-based authentication to work in this manner. Both the SetAuthCookie() and RedirectFromLoginPage() have as their second parameter a Boolean that indicates whether or not the user's "logged in" state should persist even after the user's session has ended.
Clearly session variables are not at play with forms-based authentication; instead, cookies are used, which might have been obvious enough given the fact that the method to login a user (SetAuthCookie()) has the word 'Cookie' right in it! Cookies are small text files saved on the client's computer that are sent to the corresponding website with each request. Ok, so at this point we know we will be using cookies to store authentication information, but this still leaves us with two questions:
What state do we need to maintain in this cookie, and
How can this state be saved so that it can't be read by nefarious users and can't be spoofed (that is, we don't want to allow someone to fake us out and be able to simulate the state that indicates that they're logged in).
Conclusion
In this article we looked at ASP.NET's forms-based authentication in greater detail. Specifically, we saw how forms-authentication "remembers" that a user is logged in across visits to the website's pages - namely, it uses an authentication ticket stored in a cookie. Working with cookies in this manner can introduce a number of security concerns if not done correctly. To address these issues, the ASP.NET authentication ticket is, by default, both encrypted and digitally signed to ensure that the contents haven't been tampered with. Hopefully this article has provided a bit more information on the internals of forms-based authentication!
Comments