7.3 Basic passport authentication exchange

In the following sections we will first explain how a basic Passport authentication exchange works in a non-Windows XP or Windows Server 2003 environment. In the following scenario, the user is working from a Windows 2000 machine. The user already has a set of Passport credentials and is not logged on to Passport. The scenario starts when the user enters the http://www.moneycentral.com URL in his browser. Let’s look at what happens next from a Passport message exchange point of view (the exchanges are illustrated in Figure 7.2):

Figure 7.2: Passport authentication sequence.

• Step 1: In order to authenticate to Passport and the MoneyCentral Web site, the user clicks the Passport “Sign In” icon located in the upper right corner of the MoneyCentral homepage.

• Step 2: Clicking the “Sign In” icon causes an HTTP redirect to the Passport domain authority server’s login page.

• Step 3: The Passport domain authority server presents the user with a Passport login page.

• Step 4: The user enters his Passport credentials in the Passport login page. Javascript code embedded in the login page parses the user- name, extracts the domain portion of the name and uses it to determine which Passport domain authority to post the credentials to. As mentioned above there are three Passport domain authorities: MSN (for all msn.com users), Hotmail (for all hotmail.com users) and Passport (for all other domains). The credentials are sent to the Passport domain authority server over an SSL connection. The domain authority server then validates the user credentials.

• Step 5: If the user’s Passport authentication is okay, the Passport domain authority server generates an HTTP redirect back to the MoneyCentral server.

• Step 6: The Passport domain authority server writes a set of domain- and user-specific Passport data to the user’s machine.

• Step 7: The MoneyCentral Web server sends a new copy of the MoneyCentral homepage to the user’s browser. On this new copy the Passport “Sign In” icon has changed to a “Sign Out” icon. The MoneyCentral Web server also writes a set of site- and user-specific Passport data to the user’s machine.

If the user hadn’t already obtained a set of Passport credentials before clicking the “Sign In” icon in step 1 of the exchange, the scenario would look slightly different: In this case Passport would first redirect the user to a registration Web page in order to create a set of Passport credentials.

The actual URL for the redirect in Step 5 is specified by the participating site in the original authentication redirect of Step 2. This URL is validated against the site’s Passport Site ID before the user is redirected back. The redirect URL must be within the primary domain of the site as regis- tered in the Passport Nexus. This also means that authenticated users can be sent to locations other than the participating site’s homepage: for example sending authenticated MSN users to the “My MSN” page rather than the MSN homepage after authentication.

An important feature of the basic Passport authentication sequence explained above is that the user’s Passport credentials are never sent to the participating Web site. The participating Web site relies on a Passport-specific mechanism to actually authenticate the user. This mechanism is explained in Section 7.5.

The credentials that the user uses to authenticate to Passport in Step 4 are the user’s e-mail address and a password or PIN code of at least six characters. Beginning with version 2.0, Passport supports a feature that is known as “strong-credential sign-in.” It requires the user to enter, besides this e-mail address and password, a four-digit security key in order to authenticate to Passport. Passport will automatically block the user’s Passport account key after ten attempts to log on with the wrong security key. Strong-credential sign-in is a Passport infrastructure feature: Its availability is independent of the platform that is used on the Passport user side. Strong-credential sign-in combined with Passport’s use of the SSL protocol for the exchange of authentication-related data greatly enhances the security of the Passport protocol.

Another initiative that will certainly enhance the Passport security quality is to make Passport users aware of a Passport spoofing problem and its associated risks. A simple trick you can teach your users is how to check the authenticity of the name attributes of an SSL Passport server certificate (e.g., making sure that the certificate was issued to the “passport.com” Web site and not “pasport.com”) or a Passport Web site’s URL (e.g., making sure the URL shows http://login.passport.com and not http://login.pasport.com). These spoofing attacks on earlier Passport versions were also known as “Bogus Merchant” attacks. For an overview of these attacks, take a look at David Kormann and Aviel Rubin’s paper available at http://avirubin.com/passport.html.