Web Application Authentication
Usernames and passwords are the de facto standard for authenticating to web applications, especially those exposed to the Internet. Under certain circumstances, a second factor such as a hardware or software security token may be used to increase the security of the authentication process, but those instances tend to be rare. The use of biometrics is almost unheard of for a web application.
Password-Based Authentication Systems
A number of different username and password systems exist for web applications. The HTTP specification provides two built-in authentication mechanisms, called Basic access authentication and Digest access authentication. There are also single sign-on solutions that you can integrate into your application with such as Windows Live ID and Facebook Connect. Then there are the custom-developed authentication mechanisms, which we describe later in the section “Custom Authentication Systems,” and these are what most web applications implement.
Built-In HTTP Authentication
The HTTP protocol specification provides two forms of built-in authentication:
Basic access authentication
Digest access authentication
Both of these authentication methods have significant weaknesses, and they are not recommended for use under any circumstances. You’ve probably encountered a dialog box similar to the one in Figure 3-5, which is an indicator that some form of HTTP authentication is being used.
Figure 3-5 HTTP authentication
We’ll cover them here for the sake of completeness, but no security-conscious developer should use either of these methods to protect their application.
Basic Access Authentication
Basic access authentication is a form of authentication that requires a user to enter a username and password before accessing a resource on the web server. Although this form of authentication is universally supported by web browsers, it’s inherently insecure. The process of Basic authentication is as follows:
1. Basic authentication begins when a user attempts to access a protected resource on a web server. When a request goes out for a file, such as http://www.website.cxx/secure/privatefile.html, the web server will respond with the 401 Authorization Required response code, shown here:
2. When the browser sees this response, it will pop up a dialog box requesting that the user enter their credentials.
3. After the credentials are entered and the user clicks the OK button, the browser will take those values and combine them in a known format where the username and password are concatenated with a colon “:” between them. This concatenated value is then base64-encoded and submitted via a GET request (shown next) to the web server under the Authorization header. For example, if we had the username of “stewie” and the password of “griffin,” then the concatenated plaintext would be “stewie:griffin,” and then after base64 encoding it would be “c3Rld2llOmdyaWZmaW4=”.
4. If the credentials are accepted by the server, then the protected resource is returned to the user. If it is rejected, then an error may be presented or another 401 response code may be returned.
Despite the fact that a username and password are required to access the resource, this method of authentication is insecure for several reasons.
Insecure Transmission Despite the fact that the username and password are base64-encoded, it’s a trivial exercise for an attacker to intercept these values and decode them. This is because encoding is not encryption, so it lacks the security provided by encryption. To secure these credentials in transit, they must be submitted over an SSL connection or other encrypted medium.
Repeated Exposure Compounding the issue of insecure transmission is the fact that the credentials themselves must be submitted with every single request for a protected resource. This is unlike the example (described in the section “Custom Authentication Systems”) where the web application responds with a session ID, which is used to identify an authenticated session. Instead, the browser caches the credentials and resubmits them whenever access to a protected resource takes place. The danger here is that the username and password (instead of a temporary session ID) are exposed over and over with each request to the web server.
Insecure Storage Because the username and password must be submitted to the web server with each request, the browser caches the authentication credentials. There is also no way to invalidate a session with the web server since no session is created. This means that there is no way to log out, and the only way to clear the stored credentials is to close the tab or clear the history.
To improve the security of an application already utilizing Basic access authentication, require that all communications occur over SSL. By using an encrypted channel such as SSL, you are able to mitigate the risk of plaintext transmission and the repeated exposure of the credentials. Although this doesn’t solve the issues related to insecure storage, it does mitigate the two most significant threats.
Digest Access Authentication
At a high level, the process of using Digest authentication is similar to the Basic authentication scheme except that the MD5 hashing algorithm is used to transform the password (along with some other information) before it is sent across the wire. This means that the plaintext password is not being transmitted as it was in the Basic model. In addition to this, the Digest approach uses a nonce value to make replay attacks more difficult. While we avoid a detailed discussion of the Digest authentication process here, a detailed breakdown of the hashing processes can be found in RFC2617 (http://tools.ietf.org/html/rfc2617). Despite avoiding the issue of plaintext transmission, the Digest method does expose its share of risks.
Man-in-the-Middle Attacks Digest access authentication is vulnerable to a man-in-the-middle attack because it’s possible to trick the client into downgrading the security back to Basic authentication or older Digest authentication mechanisms, which is not as secure.
At the end of the day, the use of Digest authentication should be viewed as a slightly “less bad” option when compared to Basic authentication.
IMHO
HTTP authentication is not secure. Both the built-in HTTP authentication mechanisms (Basic and Digest) are fraught with inherent insecurities. No one who takes their security seriously would want to use such poor and insecure methods to ensure the safety of their assets. The Apache web server documentation says it best: “Don’t use basic authentication for anything that requires real security.” The same goes for Digest.
Single Sign-on Authentication
Single sign-on (SSO) solutions allow a user to log in to a single interface and gain access to multiple, independently secured systems. With web applications, SSO allows a user to enter their credentials and access multiple web applications that may have been developed and secured independently but tie into or support the SSO system. SSO is most commonly found within corporate intranets, but it is also gaining popularity on the Internet.
Google Accounts (see Figure 3-6) is an example of an Internet SSO system for Google services. By logging in to your Google account once, you’re able to access multiple services provided by Google such as Gmail, Google Talk, YouTube, and Picasa. Unfortunately, third-party web applications cannot integrate with Google accounts at this time.
One service that does allow for third-party website integration is Microsoft’s Live ID service (see Figure 3-7). In addition to accessing Microsoft properties (for example, Hotmail, Xbox Live, and MSN), developers can use the Windows Live ID Web Authentication SDK to leverage the Live ID authentication system in their sites. Although adoption among third parties has been slow for Live ID, it still supports more than 300 million users and processes a staggering 22 billion authentications per month (http://msdn.microsoft.com/en-us/library/bb288408.aspx).
While Google is closed and Live ID is a minor player, one SSO service that has been experiencing rapid adoption is the Facebook Connect system (see Figure 3-8). Building on the popularity of the Facebook platform, the Connect API allows third-party developers to leverage the authentication system in addition to being able to connect with other users as they would on Facebook. Examples of sites using Facebook Connect include Digg, CNN, Vimeo, and the Huffington Post.
Figure 3-8 Facebook Connect login
As everyone continues to migrate more toward web-based applications, it will only become more and more difficult to manage credentials for the disparate systems. The adoption of SSO will help to solve this problem by reducing the number of credentials that must be remembered. Still, it’s important to keep in mind that the convenience of a single set of credentials comes at the risk of a single point of failure. Should your credentials be compromised, then it could mean more than just your Facebook or Live ID account being exposed, but also your profile on any sites that are connected through the same SSO system.
Custom Authentication Systems
Whenever a developer has coded their own application logic to process credentials, then a custom authentication system has been created. Since HTTP authentication mechanisms are deprecated and SSO solutions are not yet the standard, custom authentication is by far the most common authentication mechanism implemented in web applications.
Web Authentication Process
Because we understand the theoretical foundations of authentication, we can explore how the login process works for the majority of web applications. Specifically, we’re going to break down, step by step, how a username and password are used to authenticate to a web application, as seen in Figure 3-9.
Figure 3-9 Login with a username and password
1. Using the browser, a user requests the login page from the web application, such as http://www.website.cxx/login.html.
2. The web application returns the login page to the browser.
3. The user enters their username and password into the input fields and submits the form, which now contains the credentials, to the web application. When the form is submitted to the web application, the browser will include the form fields as part of the HTTP POST request that is submitted.
4. Upon receiving the request, the web application parses the information in the HTTP message and extracts the values of the username and password.
5. The application logic then queries a back-end data store (for example, a database or LDAP server) to determine whether or not the password entered is associated with the username entered.
a. If the matching is unsuccessful, then the web application will send the user an error message along with the login page again.
b. If the password is successfully matched to the associated username, then the application will establish a session with the user. Most applications establish a session with a user by generating a session ID value and returning it to the user. The session ID value is returned by setting a cookie in the HTTP response, shown here starting on the 6th line:
6. When the browser receives and parses the HTTP response, it will observe the Set-Cookie directive in the HTTP header and store the value of the session ID.
a. Because the session ID value was set in a cookie, the browser will now automatically submit the session ID value alongside all requests made to the web application. This acts as a form of persistent authentication because the user no longer needs to enter their username and password to authenticate every request going to the application.
b. Whenever the web application parses an HTTP request, it will see the session ID value and know that an existing session has already been established. It will use this session ID to authorize each request within the application logic.
Validating Credentials
The process of validating credentials is actually more complex than simply “determining whether or not the supplied password is associated with the supplied username.” There are several common ways to determine whether or not the correct password has been entered, and they depend on how the passwords are being stored in the back-end system.
In this segment we’ll cover the four most common ways of looking up a password that’s being stored in a back-end datastore such as a database or LDAP directory. Using this approach, there are generally two variables involved in the validation of credentials: the location of the comparison logic and how the password is stored. The first variable concerns the location of the comparison logic, and it is usually found either within the application or within the database. The second variable is how the password is stored, which usually is either plaintext or hashed (or encrypted). Taking the cross-product of these variables gives us the four approaches:
1. Comparison logic in the application with plaintext passwords
2. Comparison logic in the database with plaintext passwords
3. Comparison logic in the application with hashed passwords
4. Comparison logic in the database with hashed passwords
Comparison Logic in the Application with Plaintext Passwords
Using this approach, the application sends a request (for example, SQL query or LDAP query) to the back-end database to retrieve the record associated with the username. If the username does not exist, then the validation process fails. If a record is associated with the username, then the application-based logic compares the plaintext password provided by the user to the plaintext password from the retrieved record. If they match, then the credentials are valid.
Comparison Logic in the Database with Plaintext Passwords
This technique involves crafting a SQL query or an LDAP request to the back-end system with a conditional statement that asks the back end to return any records with matching fields that correspond to the supplied username and the supplied password. The database performs the username and password comparisons against the corresponding fields in this case. If any records are returned, then the application can safely assume that the user provided a legitimate set of credentials (unless SQL injection is used).
Comparison Logic in the Application with Hashed Passwords
With hashed passwords being compared within the application, a request is first made to the back-end datastore to retrieve the record associated with the user-supplied username. Because hashing is a one-way transformation, the user-supplied password must be hashed using the same algorithm that was used to hash the stored password in order for them to be compared. If the two hashed values are equal, then the user-supplied password was valid, and then authentication succeeds.
Comparison Logic in the Database with Hashed Passwords
Comparing hashed passwords on the back end also involves hashing the user-supplied password before it is sent to the datastore. The back-end system logic attempts to match the supplied username and the hashed form of the supplied password with a record in the system. If a match occurs, then the record is returned, and the application assumes that the credentials were valid (again, unless SQL injection is used).
Understanding the different forms of credential validation in an authentication system is important because it provides a baseline against which you can understand how the attacks work against systems like these. For example, SQL injection attacks (see Chapter 7) against authentication take advantage of how and where the credential comparisons are made. It also helps to understand where and how the plaintext passwords are compared against their hashed counterparts.