Passport

Microsoft’s Passport technology is a single sign-on implementation that eases user interaction among authentication-based applications. Theories of world domination aside, the goal of Passport is to provide a uniform, distributed network that performs a few simple functions. One of the most important of these functions is authentication. A user can carry a single Passport credential among several Web applications that support the Passport scheme. In this manner, the user need only manage a single login name and password in order to access disparate applications. In other words, a user authenticates to Passport, Passport provides a cookie, and the user presents this cookie to the Web application. Thus, it functions much like Kerberos tickets.

Prelude to the Login Process

For a third-party application to use Passport, it is imperative that the application server and the Passport server exchange a secret key. This key is used to encrypt sensitive data that must be transmitted between the two servers. For example, a user authenticates to a Passport server and receives a cookie that contains her login name and home mailing address. This cookie is encrypted with a specific secret key. Figure 10-2 shows a high-level description of the key exchange process between the Passport server and the partner application server. Next, the application server must be able to decrypt this cookie value in order to be able to access the user’s login name and home mailing address. If the application server and the Passport server did not share a secret key, the application server would not be able to validate the Passport MSPAuth cookie.

Figure 10-2: Secret key exchange occurs out of band

On the other hand, if the secret key were based on information supplied by the user, then the Passport server, the application server, and the user would be able to decrypt the MSPAuth cookie. Generally, users (that is, people) are a poor source of random data necessary for strong secret keys. Thus, the user could cause a poor secret key to be generated. This would expose the cookie to a successful dictionary attack, permitting malicious users to obtain confidential personal information. Even so, if the user knows the secret key, she can easily decrypt the cookie and modify values— values that could circumvent security of the application server.

The secret-key exchange between the Passport server and application server happens out of band via a secure e-mail attachment using public-key encryption. Obviously, the secret key must remain “secret,” so care is taken to protect the keys from interception. This can be physical exchange, or any trusted exchange ranging from RFC 1149 to couriers with notarized files.

SECURITY ALERT

There is no established key management program for Passport. Secret keys do not have a built-in expiry. However, simple key management for negating expired or compromised keys is accomplished by the kv, key value, parameter in Passport. If a compromised secret key belongs to key value 2 (kv=2), both Passport and the application server will “retire” that key and no longer accept it as valid.

The Login Process

When a user first visits an application server that supports Passport authentication, that user does not have any tokens to identify her account. The application server requires valid credentials, so it redirects the user to a Passport server for authentication. One parameter of the HTTP redirect includes a Return URL (ru) value that contains a URL to which the user will return once authentication succeeds. At the Passport server, the user provides a correct e-mail address (the login name) and password. Next, the Passport server takes the ru value and redirects the user back to the original application along with two or three new parameters in the URL. These new parameters are the Passport cookies that will be decrypted by the application server, inspected for validity, and set as session cookies in the user’s browser. Table 10-1 describes each cookie.

Table 10-1: Passport Cookie Description

Cookie	What It Contains
MSPAuth Ticket, encrypted	PUID, the user’s 64-bit unique identifier Two timestamps: last refresh, last manual sign-in. These timestamps are present to reduce the chances of a successful replay attack and to optionally force users to reauthenticate aftera designated period. Saved-password flag, key version verification, and any flags set by network servers. Key version (kv) value, used to select the appropriate decryption key. Note: The user’s e-mail address and password are not in this key and are not shared with the partner application.
MSPProf Profile, encrypted
MSPSec Ticket Granting cookie (TGT), encrypted	Sent over HTTPS only. Used for silent authentication to partner applications, or to correlate the validity of the MSPAuth cookie.

Programmatically, an application uses the IsAuthenticated method on the Passport.Manager object to verify a user’s MSPAuth cookie. This method returns a True or False value, depending on the validity of the cookie. Additionally, the application can enforce a strict policy to control the level of confidence for a user’s cookie. The IsAuthenticated method accepts TimeWindow, ForceLogin, and SecureLevel parameters. Regardless of the values for ForceLogin or SecureLevel, the TimeWindow value is always checked.

• TimeWindow A number between 100 and 1000000 that represents the number of seconds (over a minute to about 11 days) after which a user must reauthenticate. The method of reauthentication is controlled by the ForceLogin parameter.

• ForceLogin A Boolean value (True/False). A value of True requires users to have entered their password within the TimeWindow. A value of False permits users to continue as authenticated as long as they have received a ticket within the TimeWindow. Set this to True if you wish to set hard time limits on user access to an application. For example, an online banking application might require users to reenter their password every 30 minutes (TimeWindow = 1800, ForceLogin = True) regardless of activity. On the other hand, an e-commerce application might wish to permit users to browse its catalog for an entire day without interrupting the experience to request the password (TimeWindow = 86400, ForceLogin = False).

• SecureLevel A number that can be either 0, 10, or 100. This qualifies how the sign-in process must have occurred. An unspecified number or 0 indicates normal authentication; a user supplies an e-mail address and password. Specifying 10 requires that authentication take place over a secure channel; a user must access Passport over HTTPS and have a Return URL that uses HTTPS. Specifying 100 requires that authentication take place over a secure channel and that the user supply a 4-digit PIN. This is a form of two-factor authentication.

  SECURITY ALERT

  Short TimeWindow values reduce the chances of replay attacks by limiting the amount of time during which a cookie is valid. There is also a HasTicket property for the Passport Manager object, but it only checks for the presence of a ticket, not the ticket’s TimeWindow.

Notice that the user’s Web browser serves as an intermediary for all communication. The application server requires authentication, but sets the Return URL and instructs the user (via an HTTP redirect) to go to a Passport server. The Passport authenticates the user, provides the Passport cookies, then sends the user back to the application server via the Return URL. The application server and Passport server do not communicate directly. Figure 10-3 illustrates this process.

Figure 10-3: User authentication to a Passport partner server

The cookies used in this authentication process are similar to the tickets granted by the Kerberos DC. One of the most important pieces of the Passport cookie is the Passport User ID (PUID). The PUID is a 64-bit number that is unique to every user.

Often, the cookies are sent over HTTP. An astute question would be, Why is a cookie secure even if it is transmitted over HTTP? After all, anyone could intercept the HTTP request and view the cookie. The answer is that the Passport cookie, like a Kerberos ticket, cannot be decrypted by the client because the client does not know and has not supplied the encryption key. Each Passport cookie value (ticket) is encrypted with the 168-bit Triple DES algorithm based on a secret key shared by the Passport authentication server and the Web application server. This is the secret key exchanged out of band when the partner application server is first deployed.

Attacks Against Passport

When an application uses Passport to authenticate users, it does not need to provide methods for managing passwords. In fact, the login name (e-mail address) and password are not supplied by Passport to the partner application. This has a security byproduct beneficial to users. For example, consider two applications: Violet and Rose. If the Violet application server were compromised, only the data stored by Violet would be exposed. The user’s Passport credentials are still safe. A malicious user would not be able to use information from Violet to log in to the unrelated Rose application.

Of course, if a user’s login name and password are stolen, that account is compromised. In order to compromise these two pieces of data, a malicious user would have to accomplish a feat similar to one of these scenarios:

• Steal the username and password from the victim’s own computer.

• Sniff the username and password as they are submitted to the Passport server. Currently, all Passport authentication must be done over SSL, which mitigates the likelihood of success for this attack.

• Steal the username and password from the Passport server. Any authentication system faces this risk.

Because a cookie may be transmitted over HTTP, it is possible that it could be sniffed by a malicious user. This exposes the cookie to a replay attack. Fortunately, Passport provides the TimeWindow mechanism to reduce the potential success of such an attack.

Malicious Partner Applications

Theoretically, a malicious party could set up a rogue partner application that uses Passport for authentication. This would be an attack against users’ Passport credentials. Even though the malicious partner application would be able to decrypt the Passport ticket (MSPAuth) and Profile (MSPProf), it would not be able to harvest Passport accounts. In this scenario, only the user’s optionally supplied information and PUID would be exposed. Remember, the user’s password is never supplied to the partner application, only the user’s ticket upon successful authentication. Even so, if a user’s profile contains home mailing address, birth date, and gender, the malicious application would be able to gather that personal information. Passport can collect the following information:

• First name

• Last name

• Country/region

• State

• ZIP code

• Time zone

• Gender

• Birth date

• Occupation

• Accessibility

Even though all of this information can personally identify a user, Passport only requires two fields: a username (e-mail address) and password. There are further restrictions on how information is collected and used when the account is tied to a minor. So, users under 18 years of age (based on the birth date provided by the user) have additional privacy protections.

Privacy

In addition to the security risks of Passport, or any single sign-on system, users are concerned about the privacy of their information. Strong application security gives users a sense of comfort about their information, from credit card numbers to home mailing addresses. An application can use encryption to hide data from malicious eavesdroppers. Digital signatures can be used to validate the end user and the application to each other. The types of data collected, how those data are tracked, and to whom their access is granted lies more in the realm of policy than technical security measures; but it illustrates how important it is for the application developers to consider all of the users’ concerns.

Passport also requires that peer applications implement Platform for Privacy Preferences (P3P) for their users. The user’s browser must support P3P, which is the case for the most common browsers. Basically, P3P enables a user to specify the types of personal information a Web application may collect. This is to make it easier for users to understand the privacy stance of a Web application and have some ability to control how their personal information is disseminated.