With the release of Windows XP comes access to a new feature called Passport. Passport has been around since January 2000, but it is receiving more attention now that it is integrated with Windows XP and is related to Hailstorm. Passport is a single signon mechanism for e-commerce. Instead of e-commerce customers needing to create separate usernames and passwords for every e-commerce site they visit, they need only to authenticate with a single Passport server. Then through a series of authentications and encrypted cookie certificates, the user is able to purchase items at any participating e-commerce site.
Sounds reasonable, right? Well, not so fast. According to Avi Rubin and Dave Kormann there are substantial risks involved with Passport. They detail these risks and more in their article entitled, "Risks of the Passport single signon protocol," available at InformIT. In addition to detailing the risks, they also explain how Passport works in more detail. This tip will summarize the risks of Passport so that you as a security expert will be informed enough to advise your customers.
User Interface - In security systems, the user interface is one of the most crucial and frequently inadequate parts. For example, any merchant site that uses Passport displays a Passport signout icon that is supposed to remove Passport cookies. One of the most popular Passport services currently deployed is the Hotmail e-mail service from Microsoft. We set up some Hotmail accounts and did some experimentation. One thing we discovered is that, in addition to the Passport signout icon, there is also a Hotmail logout option on the page. So, what does this mean to a user? Presumably, the Hotmail logout button is used to remove the Hotmail credentials, while the Passport signout button is used to remove the Passport credentials to all services. While this may be clear to computer security experts, it is unlikely that the average nonexpert computer user will understand the distinction. A user making the mistaken, but reasonable, presumption that the Hotmail Logout button will remove Passport credentials could easily walk away from a browser still able to authenticate on behalf of the user.
Key Management - The Passport protocol requires that the Passport server share triple DES keys with each merchant. The keys are used to encrypt information transferred from Passport to the merchants in redirect messages. These keys must be generated securely (that is, randomly) and assigned out of band. Many systems have been broken because poor randomness was used to generate keys. It is a difficult problem that requires careful attention.
Passport encrypts information for itself and stores the information in Passport cookies on client machines. A single key is used to encrypt all of the cookies. This represents an unnecessary risk of exposure of that key. A better solution is to use a master key to generate a unique key per client.
Central Point of Attack - As with all single-signon systems, Passport establishes a service trusted by all others to make authoritative decisions about the authenticity of a user. Whereas in traditional Web authentication each merchant is responsible for safeguarding the authentication information of customers, all data is centralized in Passport. Compromise of this central service would be particularly disastrous. Besides authentication data, the Passport login service maintains consumer profile information on all registered users. Storing this information in a central location, while convenient, makes the server an extremely attractive target for attack, both for denial of service and for unauthorized access. The centralized service model is antithetical to the distributed nature of the Internet that has made it so robust and so popular.
Cookies and Javascript - The danger with cookies is limited to the exposure of sensitive cookie payloads to unintended recipients. Because the Passport cookie contains sensitive data, the system encrypts these cookies using triple DES. Passport cookies, though, are also proofs of authentication whose lifetimes are determined only by the lifetime of the Web browser and the (encrypted) time window in the cookie. On a public machine, a user who forgets to log out of a Passport account could leave valid authentication tokens behind on the machine for any user to recover.
The most important problems, however, with cookies and JavaScript are more social than technological. Regardless of their actual value or security, these technologies have been shown to compromise user privacy. Dictating (or even strongly recommending) the use of technologies that are not felt to be trustworthy in a system whose purpose is to establish trust can undermine significantly the perceived value of that system.
Persistent Cookies - Passport leaves authenticators, in the form of browser cookies, on the client machine. The Passport server does not have to reissue credentials if the cookie has not expired yet. This is reminiscent of single signon in Kerberos.
Kerberos uses tickets, which are encrypted credentials, to establish continuous authentication within a specified amount of time, without requiring a return trip to the authentication server. In Passport, where cookies stand in for tickets, possession of the cookie is all that is necessary to impersonate the valid user of that cookie. No further proof is required.
Bogus Merchant - The bogus merchant threat is probably the weakest aspect of Passport. Imagine that users get accustomed to using Passport. They enjoy the convenience of single signon and wallet services, while trusting that the service is secure. Now, to attack the system, a merchant sets up a phony Web store, selling something attractive. When the user visits the phony Web site, the server simulates a redirect to pasport.com, and the user is prompted for his credentials on a page that looks exactly like the legitimate Passport server. The user is in the habit of filling this out every once in a while, so he does not notice the misspelled URL, or check the certificate. Even if he did check the certificate, he might not notice the misspelling. In practice, any URL, even one that does not resemble the word "passport," would probably work as well.
Active Attack - An attacker with access to the network between the client's Web browser and the merchant server (and able, therefore, to rewrite packets passing between the two hosts) can take advantage of this access to achieve the same result described above while permitting the client to interact normally with the merchant site. Such access is not prohibitively difficult to obtain. Large ISPs concentrate the traffic of thousands of users through a fairly small set of routers and servers. Obtaining unauthorized access to one of these hosts interposes the attacker between these users and all services they wish to access. Any traffic passing through such a compromised host could potentially then be read and rewritten.
DNS Attacks - Passport's security model depends heavily on the Domain Name System. In addition to the well-known problem of SSL's dependence on the DNS, HTTP redirects generally specify a host to receive the redirection in the form of a DNS name. An intruder who controls a client's DNS service could transparently perform the rewriting process by simply aliasing http://www.passport.com to the IP address of a server controlled by the intruder.
This tip has really just been a summary of the risks of Passport. Read the full article at InformIT. Registration is required, but it is free.
