Risks of the Passport Single Signon Protocol
- The Problem with SSL
- How Passport Works
- Risks of Passport
- Conclusions
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
A NOTE FROM THE AUTHORS: We first wrote this article when we discovered Passport in January 2000. At the time, it did not receive too much attention. However, with the upcoming release of Windows XP and its integration with Passport, and with the reliance of Hailstorm on Passport, the article has become very popular.
It has become common practice for retailers, banks, service providers, and just about everyone else to provide customers with a way of shopping on the Web. To ensure the security of these customers' financial data, the online vendors often require a username and a password to access an account. Users are faced with a dilemma when creating multiple accounts. Do they use the same name and password for all the accounts? If so, that means that, for example, their online grocery store will have access to their stock trading account. The alternative is to maintain a list of usernames and passwords. This list must be written down, as so many names and passwords are cumbersome to remember. As such, compromise of this list constitutes potential for a serious loss.
Single signon is the term used to represent a system whereby users need only remember one username and password, and authentication can be provided for multiple services. Kerberos1 is an example of a system where users provide a password and receive a ticket in exchange. The ticket can be used to authenticate users to different network services. Kerberos single signon is possible because all of the services are under the same administrative control. There is a centralized database containing keys that are shared with each service, and tickets can be issued, encrypted under the keys of the target services.
Single signon on the Web is much more difficult. Different Web sites are under completely different administrative control. Thus, it is not natural to imagine signing in once and gaining authenticated access to multiple, independent Web services. Passport is Microsoft's ambitious attempt to provide this service. While the overall architecture makes sense given the constraints of the protocol, (namely, to use only existing Web technologies that are present in most browsers and servers), there are some risks associated with using this protocol that are not pointed out in the paper. We refer to the online description of Passport that can be found at http://www.passport.com/business/content_whitepaper2.html. The draft that we refer to is the one at the time of this writing. We were unable to locate a paper copy to reference.
As just mentioned, one of the constraints of Passport is that it was designed to use existing Web technologies so that clients and servers need not be modified. The protocol leverages HTTP redirects, JavaScript, cookies, and SSL. While JavaScript is not absolutely required, it is highly recommended. Some of the attacks described below result from some fundamental problems with security on the Web and, in particular, the public key infrastructure that is built into browsers. As such, they are not specific to Passport but nonetheless represent risks of using that system (and any system subject to these constraints).
The Problem with SSL
SSL is a wonderful protocol. It is well designed, it has withstood much analysis and scrutiny,2 and its deployment is probably the single most positive step toward anything resembling security on the Web. While we find no fault in the SSL protocol or its implementations in browsers and servers, we believe that the certification model and user interface can lead to problems.
Browsers come with many default "root" public keys. For example, Netscape Navigator 4.5 comes with 58 root public keys. Anyone who controls the corresponding private keys can issue certificates that are automatically trusted by all major browsers. All it takes is for one of the certifying authorities with a weak policy, security breach, or intentional compromise (for example, bribe) for the certification process to be meaningless. If an entity can obtain a certificate from a trusted authority, then the only recourse of the user when presented with a "secure" Web site is to check the security information and determine that the root CA that signed the certificate is one it trusts and that the name in the certificate corresponds to the actual entity with which it wants to have a secure session. Most users are not qualified to determine either of these things and are probably not even aware of SSL or certificates anyhow.
As it stands, the SSL model does not lend itself naturally to the problem of delegation. This is exactly the feature that Passport requires. So, Passport uses the existing Web technologies to the best of its abilities. Unfortunately, the resulting protocol poses several risks to the user, and these are the focus of this paper.