188宝金博页面版

What Makes Users Refuse Web Single Sign-On?An Empirical Investigation of OpenIDSan-Tsai SunUniversity of British ColumbiaVancouver, BC, Canadasantsais@ece.ubc.caEric PospisilUniversity of British ColumbiaVancouver, BC, Canadaericpospisil@gmail.comIldar MuslukhovUniversity of British ColumbiaVancouver, BC, Canadaildarm@ece.ubc.caNuray DindarUniversity of British ColumbiaVancouver, BC, Canadanuraydindar@gmail.comKirstie HawkeyDalhousie UniversityHalifax, NS, Canadahawkey@cs.dal.caKonstantin BeznosovUniversity of British ColumbiaVancouver, BC, Canadabeznosov@ece.ubc.caABSTRACTOpenID is an open and promising Web single sign-on (SSO)solution. This work investigates the challenges and concernsweb users face when using OpenID for authentication, andidentif i es what changes in the login f l ow could improve theusers’ experience and adoption incentives. We found ourparticipants had several behaviors, concerns, and misconcep-tions that hinder the OpenID adoption process: (1) their ex-isting password management strategies reduce the perceivedusefulness of SSO; (2) many (26%) expressed concerns withsingle-point-of-failure related issues; (3) most (71%) held theincorrect belief that the OpenID credentials are being givento the content providers; (4) half exhibited an inability todistinguish a fake Google login form, even when prompted;(5) many (40%) were hesitant to consent to the release oftheir personal prof i le information; and (6) many (36%) ex-pressed concern with the use of SSO on websites that containvaluable personal information or, conversely, are not trust-worthy. We also found that with an improved af f ordanceand privacy control, more than 60% of study participantswould use Web SSO solutions on the websites they trust.Categories and Subject DescriptorsD.4.6 [Security and Protection]: AuthenticationGeneral TermsHuman Factors, SecurityKeywordsOpenID, Web Single Sign-On, Identity Enabled BrowserCopyright is held by the author/owner. Permission to make digital or hardcopies of all or part of this work for personal or classroom use is grantedwithout fee.Symposium on Usable Privacy and Security (SOUPS) 2011, July 20–22,2011, Pittsburgh, PA USA1. INTRODUCTIONToday’s Web is site-centric; a typical web user has abouttwenty-f i ve accounts that require passwords, and enters ap-proximately eight passwords per day [13]. Web users facethe burden of managing this increasing number of accountsand passwords, which leads to“password fatigue”[42]. Asidefrom the burden on human memory, password fatigue maycause users to devise password management strategies thatdegrade the security of their protected information [15, 13].In addition, the site-centric Web makes online prof i le man-agement and personal content sharing dif f i cult, as each useraccount is created and managed in a separate administrativedomain [36].Web single sign-on (SSO) systems are meant to addressthe root causes of the site-centric Web. A Web SSO systemseparates the role of identity provider (IdP) from that of re-lying party (RP). An IdP collects user identity informationand authenticates users, while an RP relies on the authenti-cated identity to make authorization decisions. OpenID [32]is an open and promising user-centric Web SSO solution.According to the OpenID Foundation, there are currentlymore than one billion OpenID-enabled user accounts pro-vided by major service providers (e.g., Google, Yahoo andAOL). In addition, the US Government has collaboratedwith the OpenID Foundation in support of the Open Gov-ernment Initiative’s (http://www.whitehouse.gov/open) pi-lot adoption of OpenID technology.One key scalability feature of OpenID is that it does notrequire any pre-established trust relationships between IdPsand RPs, and users are free to choose or setup their ownOpenID providers. In OpenID, a user’s identity is a URL;and the OpenID authentication process asserts to an RPthat the user controls the content at that URL. Figure 1aillustrates the following steps, which demonstrate how theOpenID protocol works:1. A user selects an IdP (e.g., https://yahoo.com/) or entersher OpenID URL (e.g., http://ece.ubc.ca/alice) via a loginform presented by an RP (see Figure 1b and c for examples).2. The RP discovers the IdP’s endpoint and redirects theuser to the IdP for authentication.3. The user authenticates with the IdP by entering her username and password, and then consents to the release of herprof i le information(Figure 1d).4. The IdP verif i es the credential and redirects the userback to the RP with the user’s OpenID identif i er and prof i le1