Security, Privacy and Usability Requirements for Federated Identity Michael Hackett and Kirstie Hawkey Faculty of Computer Science Dalhousie University Halifax, Nova Scotia, Canada e-mail: [email protected], [email protected] Abstract—Federated Identity systems promise to solve the about an individual and could become the targets of hackers increasingly vexing problem of password overload. However, and identity thieves. If an identity account is compromised, existing systems, such as OpenID and CardSpace have failed the potential damage could be much more widespread and to gain the expected levels of adoption, due in part to usability and security issues, while proprietary systems such as Facebook devastating for the target individual than if a password to Connect raise serious privacy concerns over their usage of the a single site were compromised. Therefore, the security data collected. In this paper, we examine two new contenders— of these systems must be scrutinized carefully and the BrowserID from Mozilla and WebID from the W3C WebID opportunities for user mishaps minimized. Community Group—and find that, while both offer significant Two newer proposals that are not yet widely deployed but improvements, we were still able to identify a number of important security, privacy, and usability issues that need to which are garnering much attention are WebID [3], [4] and be addressed before beginning to widely deploy these new BrowserID [5], [6]. Both take a decentralized approach to platforms. identity management (where there is no one single central authority, such as Facebook), and aim to provide improved I. INTRODUCTION usability, security and privacy over prior decentralized sys- Federated Identity systems attempt to solve the growing tems, such as OpenID. dilemma among computer users sometimes referred to as In this paper, we focus on analysing some of the key “password fatigue”. According to one recent study [1], the security and privacy claims of these new proposals, with the average computer user has 25 different password-protected goal of raising alarms early in the design process, when the accounts, many of them used only infrequently, creating a developers of these schemes still have the ability to solve situation where it is almost impossible to commit all of those the issues. We will begin with some further background on usernames and passwords to memory. Coping strategies the problem being addressed and some useful terminology include the use of password management software, writing in section II, and then discuss some related projects in down of passwords (often on sticky notes attached to a section III. This will be followed by two sections introducing computer!), and using the same password for all accounts. the two proposal being examined here, BrowserID in sec- In addition to reducing security, these often create a de- tion IV, WebID in section V. Our analysis of the protocols pendency on a particular device (where the passwords are on a number of key issues appears in section VI, followed stored) or item (such as a notebook) or location (such as by our future work and conclusions. one’s desk), such that the person may be unable to use their “accessible anywhere” accounts whenever he or she is away II. BACKGROUND from their particular storage medium. When using a Federated Identity, an individual need only Although the different proposals described herein gener- remember one set of credentials in order to gain access to ally share many of the same concepts, their specifications all services, without needing to share those credentials with often use different terminology for these concepts. For ease the service providers. OpenID [2] is one well-known attempt of comparison, this paper uses the following terms, based on to create such a system, but adoption has been hindered by those given by Maler and Reed [7], noting the corresponding usability and security issues. Proprietary systems, such as term wherever one of the official specifications differs. Facebook Connect and Microsoft Passport, have made some • A service provider (SP) is some web site or service that gains in usability, but they raise serious privacy concerns for the user must sign into to use. When the SP depends on many users, as the companies operating these systems are a third party for identity authentication, it is often called able to track users’ activity and make use of the information a relying party (RP), because it relies on the external they obtain, including making a user’s activity public without authentication service. his or her consent or knowledge. • An identity provider (IdP) is another web site or service Another concern is that, for all their convenience, these whose job is to verify or provide information to aid in identity accounts are the keys to a great deal of information verifying the identity of a user. • A user agent (UA) is a web browser or other software Microsoft’s CardSpace [11], [12] uses the metaphor of application that communicates with a remote system on Information Cards that are analogous to the physical identity behalf of the user. and membership cards most of us carry in our wallets. Each Although both WebID and BrowserID can be used for card holds either a collection of identity attributes (referred authenticating software agents (that is, automated systems) to as claims) or a link to an IdP that can supply such as well as human users, for simplicity we will simply use information on demand. Just as in a physical wallet, users the term user for both cases. (The X.509 specification [8] may have cards from several different IdPs, and can choose uses the term subject to mean “person or system”, but this the one the that is most appropriate for a given context, word has several other meanings as well, so we find user to such as using a government-issued ID to vote online, or be more clear in this context.) a self-issued card containing only an email address for a Also, throughout the paper, in the name of grammatical web discussion board. With claims-based identity, a user expediency, we will use the conventional user “Alice” to might be able to use any one of a number of cards to satisfy stand in for a general user of either system. a particular RP’s authentication request, provided the card Note that while federated identity systems are often re- includes the requested claims and is issued by an authority ferred to single sign-on (SSO)—probably a more end-user- that the RP trusts. friendly term—this is not strictly accurate. In a true SSO Yet, despite bundling the CardSpace client with Windows system, one would not be required to sign into each site Vista and Windows 7, thus ensuring an installed base of mil- separately; once you had signed into your identity account, lions of potential users, claims-based identity has not gained you would automatically be recognized at each cooperating traction with service providers, and Microsoft decided to site that you visited. This can be convenient, and might cancel the product in February 2011. Service providers did be a reasonable default within an organization, but many not see any compelling advantages to implementing support, users would not be comfortable with applying it to the and users “were often confused by their first encounter with entire Internet. They may want to use different identities CardSpace” [13], finding it too complicated in comparison on some sites and have the option of anonymity on others. with the username/password forms to which they had be- Furthermore, it would be inconvenient to have to remember come accustomed. In addition, Microsoft admitted that the to sign out of one identity and into another for each site. lack of tools for service providers for creating claims-ready Both BrowserID and WebID give you the option to either services was another factor in the lack of uptake [14]. select an identity to share with each service provider, or Nonetheless, other groups remain interested in the In- to not share one; they never share anything without your formation Card concept. Higgins1 and openinfocard2 are explicit consent. While slightly less convenient, from a two open-source projects that have also built Information privacy perspective, this is probably what most people would Card clients. The Higgins project, for example, has experi- prefer. (That said, it would almost certainly be possible for mented with several alternative client implementations, such someone to create a user agent that did immediately sign as a Firefox-based browser extension (without the native into every compatible site automatically, if that was what platform component that CardSpace required) and clients some users wanted.) for mobile phones. They have also created native client applications for Linux and Mac OS X, and introduced a web III. RELATED WORK service to solve the problem of sharing Information Cards Of course, neither BrowserID nor WebID is the first across devices, with the active clients becoming simple attempt to solve the digital identity problem. OpenID is shells that interfaced with the web service. perhaps the best known decentralized web identity system. However, in addition to the aforementioned lack of service It uses URLs to identify users, and users are free to choose provider interest in claims-based authentication, a lack of their identity providers, or may even set up their own IdP. visibility and an overly technical installation process have As OpenID “does not require any pre-established trust rela- further limited Higgins’s appeal to a niche of developers tionships between IdPs and [RPs]” [9], the barriers to entry and researchers. Also, some aspects of the card selection for new IdPs and RPs are low. OpenID adoption by users, interface have been identified as “overly intrusive and annoy- however, has been hindered by usability issues—particularly ing,” particularly when returning to previously visited sites with respect to inconsistencies in the sign-in interface [10]— or having to select multiple cards to satisfy a request.