WebTicket

WebTicket: Account Management Using Printable Tokens ABSTRACT Passwords are the most common authentication scheme for web services. However, it is difficult for people to memorize random sequences of characters, as suggested by best practices in computer security. Additionally, passwords, on their own, do not provide security against phishing. In this paper, we introduce WebTicket, a low cost, easy-to-use and reliable web account management system that uses “tickets”, which are tokens that display a two-dimensional barcode. Users can log into accounts by presenting the barcodes to web cameras connected to computers. Through two user studies consisting of 49 participants in total, we suggest that WebTicket can provide reliable authentication and phishing resilience. Author Keywords Password, User Authentication, and Usable Security ACM Classification Keywords H.5.2 Information Miscellaneous Interfaces and Presentation: INTRODUCTION Passwords are the most commonly used form of authentication for web services today. A fundamental assumption here is that users can memorize secure passwords. If users have only a few passwords, it is possible to memorize them. However, as the number of passwords increases, users have difficulty in remembering passwords due to the large number and possible interference among them [4]. The cost of forgetting passwords is not a trivial matter either. It has been reported that, for the NYTimes online, 100,000 readers forget their passwords each week. Furthermore, 15% of new readers were actually old readers signing up again because of a forgotten password [12]. As another example, a recent Gartner report investigated the cost of forgotten passwords at a large beverage company. This investigation found that 30% of help desk calls were Submitted to CHI2011 related to passwords, with an average cost of $17.23 USD per call, resulting in an annual impact of more than $900,000 USD [10]. A Google search for “forgot my password” returns 11 million hits, providing further support that forgetting passwords is a very common problem. (a) Front (b) Back Figure 1 An example of a paper-based WebTicket. On its front side, it has a two-dimensional barcode that includes a login script. On its backside, it has a favicon, user-editable text, a user-chosen border, and instructions. Instructions were added after the first user study to prevent custom phishing attacks. People cope with the burden of managing passwords in many ways, but these coping strategies often lead to new security risks. For example, to improve memorability of passwords, users are likely to choose simple, easy-toremember passwords [4,26]. However these simple passwords are highly vulnerable to dictionary attacks, where an attacker cracks a password based on a list of frequently used passwords [15,17]. Analysis of 32 million passwords exposed in a security breach at RockYou.com showed that the top 20% most common password could compromise over 5% of the accounts. [31] Another strategy is to reuse the same or a slightly modified password. Gaw and Felten found that undergraduate students used 3.31 unique passwords for 7.86 accounts on average [11]. Hayashi et al. also reported that users had 11.4 online account and reused passwords among the accounts. [33] These findings illustrated that people commonly reused passwords. Reusing passwords reduces the number of passwords that users must memorize. However, if one account using a shared password is cracked, other accounts are potentially compromised. In this paper, we introduce WebTicket, a web account management system that lets users manage their accounts without having to memorize passwords. Users can print a ticket (see Figure 1), or store a ticket in their mobile phones (see Figure 4). WebTicket generates a strong password and embeds a login script – including a URL of a web site, a user ID, and the password – in a 2D barcode on a ticket. Users can show the barcode to a webcam on their computers to log into an account. The information in the barcode is encrypted using a key stored in the user's computer. Therefore, an attacker must have access to both the user's computer and the ticket to log into an account. In this way, WebTicket transforms knowledge-based authentication into token-based authentication at a relatively low monetary and operational cost. WebTicket also protects users from phishing, as users do not know their own passwords. Thus, even if they are led to phishing web sites, they cannot type their passwords. We note that WebTicket is not intended to replace all passwords. WebTicket works well in managing infrequently used or secure passwords where users are more likely to forget passwords, while passwords work well for frequently used accounts where users are less likely to forget passwords. In this paper, we present the design and implementation of both a printed version and a mobile phone version of WebTicket. We also present the results of two user studies consisting of 49 participants total, which suggest that WebTicket can provide easy and reliable user authentication while also being resilient against phishing. The rest of this paper is organized as follows. First we position WebTicket within the literature. Second, we introduce WebTicket's design goals. Third, we describe in more details how WebTicket works. Fourth, we explain our user study and its results. Fifth, we discuss alternative designs and limitations of WebTicket. Finally, we discuss implications and future work. RELATED WORK We have organized related work into two categories: usable security and tangible interfaces. Usable security User authentication systems depend on three types of mechanisms: what you know, what you have and what you are. In the case of what you know, an authentication system and a user share a secret, e.g., a password, at enrollment. Then, at authentication, the system authenticates the user by verifying whether the user knows the secret shared between the system and the user. In the case of what you have, a system authenticates a user based on whether the user has a physical object, such as a credit card, which is given to the user at enrollment. In the case of what you are, an authentication system records some aspect of a user's physiology or behavior at enrollment, then, authenticates the user based on whether this property matches or not. Password managers. Much past work has examined how to reduce memory workload to make account management for what you know authentication easier. The most straightforward approach is to develop a system that stores all user IDs and passwords. All major web browsers support password managers that can store user IDs and passwords when users log into their web accounts. Once user IDs and passwords are stored, the password managers fill them in when users visit the same web site again. This allows users to manage their accounts without memorizing passwords. However, if attackers have access to a user's web browser, they can access the user's accounts without any authentication. Similarly, if users’ computers crash, they will lose access to their accounts. Finally, password managers neither prevent people from reusing passwords, nor guarantee that users create strong passwords. An alternative to custom software for managing passwords is to simply write down passwords. WebTicket is better than this existing practice in that it guarantees strong passwords, tickets are keyed to specific computers only, and WebTicket helps users avoid phishing attacks. Master password approach. Some systems try to decrease the number of passwords that users have to memorize by generating account specific passwords from master passwords. PwdHash generates account specific passwords using limited number of passwords and domain names [25]. PassPet uses one master password and user-chosen site names to generate passwords [30]. In these schemes, users must memorize only a limited number of passwords; however, because the additional information (i.e., domain names and user-chosen name for web sites) is easy to guess or obtain, the security of the generated passwords depends on the user-chosen master passwords. Thus, attackers could launch online attacks on insecure web sites, which do not restrict number of trials, to obtain master passwords, then, compromise secure and important accounts. Mnemonic passwords. Another approach to reduce memory workload is to make each password easier to memorize. Mnemonic passwords are seemingly random sequence of letters generated from a phrase, typically by taking the first letter of each word. For instance, ``Ilts@7S!'' can be generated from a phrase “I love to ski at Seven Springs!” Because users can rely on meaningful phrases, mnemonic password are easy to memorize for users and relatively difficult to guess for attackers [29]. However, because users are likely to choose specific phrases as sources of mnemonic passwords, attackers can guess mnemonic passwords more easily than random passwords [17]. Furthermore, even using mnemonic passwords, users can forget which password is for which account, due to scaling issues and interference effects. Graphical passwords. Another solution to making each password easy to memorize is to use graphical passwords instead of textual passwords [5,28,13]. Graphical passwords are based on the observations that people are better at memorizing (or recognizing) graphics than at memorizing text [18,24]. However, these graphical password authentication schemes have challenges in actual deployment because of uncertainty about their security and scalability [6,8,9]. Tokens. Other authentication systems depend on what you have. eToken is a USB device which can be used as a “physical key” to log into users' accounts [1]. A one-time password token is a device with an LCD, which shows numbers based on the current time and a key stored in the token. To authenticate, users can type the number shown on the device, with a server-side application checking whether that number was actually generated by that device. RSA secureID, a variant of the one-time password token, depends on both what you have and what you know. In addition to a number shown on the RSA secureID, users have to type their personal identification number to be authenticated [3]. However, there are challenges in scaling these kinds of approaches across all accounts a person has, since these tokens require server-side support, and it would be impractical to carry a custom token for each web site. As such, these tokens tend to be used only for accounts with very high security requirements. WEBTICKET DESIGN GOALS WebTicket is designed with to support people in accessing infrequently used accounts as well as accounts with stringent password requirements. WebTicket is also intended to help novice users who are uncomfortable with computers or have a hard time remembering not only their passwords, but also what website to go to. In this sense, WebTicket can be thought of as a tangible web bookmark. Towards this end, we defined the following design goals. Be Reliable for Logins. WebTicket should support logging into accounts reliably even after a long period of inactivity. Be Easy to Understand. Users often have difficulties in understanding security systems because of a lack of awareness and knowledge about computer security [27]. We wanted WebTicket to offer users a simple mental model of how it works and how to use it, which should help improve security in practice. Finally, there are systems that use barcodes for authentication. Phoolproof Phishing is a mobile phonebased user authentication scheme designed to prevent phishing attacks, key loggers, and other kinds of malware. Users select what site to login to on their mobile phone, which opens the web site on a local computer. The mobile phone also checks the site’s certificate to verify that the opened site is the correct site, at which point users can login normally. While WebTicket does not offer as strong mutual authentication, it does not require server-side changes, and also facilitates logins by helping to enter usernames and passwords. Seeing-Is-Believing is a pairing protocol for cell phones [20]. The protocol pairs two devices by conveying a hash value, i.e., a number, using a 2D barcode. In contrast, in WebTicket, a 2D barcode on a ticket conveys richer information, such as a URL, a user ID and a password for user authentication. Offer Strong Passwords. Users tend to choose easily guessable passwords or reuse passwords to improve memorability [4,29]. To maximize the security provided by passwords, WebTicket should use a randomly generated strong password for each account. Tangible Interfaces Support Incremental Buy-in. Rather than forcing people to switch completely to a new system, we wanted to lower the switching costs, letting people use WebTicket for some accounts but not requiring it for all accounts. Tangible interfaces are computer systems that let people manipulate physical objects to interact with computers [14]. In this paper, we used tangible objects, i.e., tickets, to help users to manage their online accounts. We also defined the following three design goals to facilitate adoption of WebTicket. Be Compatible with Existing Web Sites. Virtually all web sites today use password-based authentication. We want WebTicket to be compatible with the majority of web sites to avoid server side modifications. Be Easy to Deploy. Some account management systems entail additional costs, in terms of initial purchase costs, setup, and maintenance, which can be barriers to widespread deployment. Hence, we wanted these costs for WebTicket to be low. WEBTICKET DESIGN AND USAGE There are many tangible interfaces that make use of paper (e.g., [19,21]). Palette is a presentation tool that allows presenters to access digital presentations quickly using physical cards with unique barcodes printed on them [23]. The Designer's Outpost, which consists of Post-it notes and a large workspace augmented by a computer, enable users to design web sites utilizing the advantages of both paper and electronic media [16]. Collaborage is an augmented board where users can put paper tags with 2D identification codes, which connect the paper tags and information on computer to utilizing both ease of paper usage and richness of the information [22]. WebTicket is an interactive system consisting of a webbrowser extension, tokens (either printed or on a mobile device), a webcam, and a computer. When creating an account using our system, a user can print a paper-based token (ticket) with a 2D barcode containing a login script. This login script includes the URL of a web site, a user ID, and an encrypted password. To log into an account, a user can show the ticket to a webcam attached to their computer. WebTicket scans the 2D barcode, opens the website in a browser, and logs into the account, obviating the need for users to enter in user names and passwords. These projects demonstrated that users could manage complicated information well using tangible objects, e.g., paper, with augmentation by computers. In this section, we provide more detail on installation, account creation, tickets, and the login process (See Figures 1 to 3), along with our design rationale. Towards the end of the paper, we discuss alternative approaches. Installing WebTicket The backend portion of WebTicket is currently implemented as a Firefox extension, and is available through a small icon in the browser. On installation, WebTicket generates a random number that is used as a key to encrypt information on tickets paired with that computer. Users can print a backup of the key as a special kind of WebTicket if desired, which allows users to copy the key to other computers. After generating the key, WebTicket prompts users to choose a border from a large set of borders, which is printed on tickets (see the border of the card in Figure 1b) and displayed on the WebTicket reader dialog (Figure 3). This border is based on Dynamic Security Skins [7]. Because the border is a secret shared between a user and the WebTicket system, an attacker will have a harder time creating a fake phishing dialog that pretends to be WebTicket. Note that even if an attacker obtains the data on a ticket using a fake reader dialog, the attacker cannot access an account without the encryption key stored in the computer. Account Creation When signing up for web services, users create web accounts and tickets using the WebTicket wizard (Figure 2). The account creation process consists of (1) signing up, (2) recording, and (3) printing. In the signing up step, a user is asked to sign up for the web service, e.g., amazon.com. WebTicket automatically fills password fields with a randomly generated strong password consisting of upper case, lower case, numbers, and at least one symbol. In the recording step, the wizard asks the user to log into the web service. When the wizard detects that the user is typing in their user ID, the wizard fills in the password field with the password generated in the previous step. Then, when the user clicks the login button, the wizard records the login process of the web site, i.e., the URL of the login form, the user ID, the password, and names of relevant HTML objects. We currently focus on web sites where users can log into their account in a single step, e.g., typing a user ID and a password, and click login button. Technically, WebTicket could support more complicated login processes, such as those that have intermediate steps like showing a picture, as long as the process requires same input every time, though we do not currently support this. In the printing step, the user can edit what text appears on the backside of the ticket, thus personalizing a ticket with a name or short memo, and then print the ticket. WebTicket also supports creating tickets for existing accounts. Here, users create tickets using existing passwords, or change the passwords to ones which WebTicket generates. The Ticket In WebTicket, users rely on tickets (Figure 1) to log into their accounts. Its size is 53mm×85mm. Each ticket is associated with a web account. On the front side of a ticket is a QR Code that contains a login script. QR Codes are 2D barcodes standardized by Denso [2]. We choose QR Codes because they can be easily decoded by a webcam. However, any barcode that can store enough data can be used. The password in this script is encrypted using a key stored on a user's computer, which prevents simple theft or camera-based attacks. The backside of a ticket has a favicon of the web site associated with this ticket, user-editable text (e.g., the user's name), the user-chosen border, and instructions about the login process. We added these instructions after the first user study because some participants had difficulty in finding the WebTicket icon on the Firefox toolbar. These instructions also include steps to help avoid WebTicket phishing attacks. Figure 2 WebTicket wizard. Users can open the wizard from create ticket tab in WebTicket’s reader dialog (Figure 2), then, create an account and a ticket using this wizard. One challenge in generating passwords is that different web sites have different password policies. We analyzed the 100 most frequently visited web sites listed by Alexa. Of these, 52 web sites had a sign-up mechanism. Ten of these 52 web sites did not allow free sign up (e.g., Comcast). Of the remaining 42 sites, 78.6 % of the web sites were compatible with our password generation algorithm. Other web sites had password policies not compatible with our algorithm (e.g., do not allow symbols). In these cases, users can type letters in password fields to satisfy the policies. WebTicket then randomizes the order of letters to make the passwords stronger. In this way, users can handle web sites with password policies not compatible with WebTicket. If a ticket is lost, stolen, or damaged, users can revoke a ticket and print a new ticket. Because a ticket is tied to a combination of a URL, a user ID and a password, users can revoke a ticket by changing the old password to a new one using password reset mechanisms provided by the web site, typically involving answering a secret question. Users can then print a new ticket that contains the new password using a WebTicket wizard designed for existing accounts. Because tickets are physical objects, we can describe tickets as being analogous to physical keys. We chose this description to help users to foster a better mental model of how they should treat their tickets. Furthermore, because a ticket is associated with one account, users can manage them differently. For instance, users can keep tickets for their bank accounts securely at their home, while carrying around tickets for e-commerce web sites. Logging in Using WebTicket When a user wants to log into her accounts, she has to first click on the WebTicket icon in Firefox's toolbar to launch WebTicket's reader dialog (Figure 3). The border of the dialog is identical to the border the user selected on installation. The dialog shows a real-time image captured by the computer’s webcam. After launching the dialog, the user should check whether the border on the ticket matches the border on the dialog, to avoid custom phishing attacks on WebTicket. Since an attacker does not know which border the user has chosen, the attacker will have a difficult time guessing which border should be shown on fake dialogs [7]. If the user sees that the borders match, then, the user can proceed and scan the QR Code on her ticket. The WebTicket application then decrypts and executes the login script to log into the account. smart phone, which will display a QR code. Because the paper-based and mobile-phone version of WebTicket use the same QR code, they can be used simultaneously. USER STUDY #1: BASIC USABILITY We conducted a user study consisting of two sessions to compare WebTicket with passwords in terms of their usability using a within-subject design. In the password condition, participants created accounts and logged into the accounts using passwords. In the WebTicket condition, they did the same using the paper-based version of WebTicket. At this point, we had not implemented mobile phone-based WebTicket. We used three mock e-commerce web sites (for a practice and the two conditions), which were different in content and color but identical in terms of registration and login forms. The login form, shown on their home pages, required participants’ email addresses and passwords to log into their accounts. We designed these web sites based on an analysis of 27 existing e-commerce sites. Participants We recruited 20 participants using an existing university recruitment site. Their ages ranged from 21 to 57 with a mean age of 31.9 (σ=11.5). Nine participants were males and 11 were female. They consisted of 11 university students, nine university staffs and two domestic residents. None of the students were computer science majors. We paid $10 USD for their participation and an additional $3 USD for each successful login in the second session. Figure 3 WebTicket’s reader dialog. Users scan their tickets by showing their ticket to a webcam. The user-chosen border is shown around the dialog. The color of the green part in the dialog also changes along with the border. (a) List View (b) Information (c) QR Code Figure 4 Screenshots of smart phone-based WebTicket. All the tickets in a cell-phone are listed in (a) ListVeiw. When user chooses one of them, (b) information is displayed. (c) QR code is displayed when the show barcode button is clicked. WebTicket on Mobile Phones In the first user study, some participants expressed concerns about carrying tickets. We also realized that there were potential problems with managing large number of tickets. To address these concerns, we implemented WebTicket for Android smart phones. Instead of printing tickets, users can use their mobile phones to scan a QR code shown on a computer’s display to import the data in printing step. To log into an account, a user can select an account on their Procedure In the initial session, firstly, we asked participants to create an account and log into the account using WebTicket as a practice at our instruction. After that, as the actual study, we asked participants to create two accounts, one using WebTicket and one using standard passwords (randomized in order). In both conditions, they started from a blank page opened in Firefox, with WebTicket wizard opened in the WebTicket condition. For the password condition, we asked them not to use their existing passwords. These were intended to improve the internal validity of this study. After creating the accounts, we asked the participants to log into the accounts starting from a blank page. In the password condition, the participants opened a web site associated with their account using a bookmark. Then, the participant typed their email addresses and passwords in a login form to log into their accounts. In the WebTicket condition, the login process involved more steps. We prepared nine extra tickets for the e-commerce web sites. Then, a participant’s ticket was shuffled in with the nine extra tickets to emulate the situation where they managed 10 accounts using WebTicket. In addition, we asked each participant to put the stack of 10 tickets in a place where she kept other cards, e.g. a wallet in a bag. We asked participants to start the login process from this status. Therefore, a typical login process involved taking out a wallet from a bag, taking out the stack of tickets from a wallet, searching a ticket for specified web account from the stack, launching the WebTicket reader dialog, and scanning the ticket. In both conditions, we regarded a login process as successful if participants could log into their accounts within two minutes. At the end of the initial session, we asked participants to complete a survey. We also asked them to keep their tickets for one week and bring them back to the follow-up session. One week later, in the follow-up session, we asked the participants to log into their accounts using passwords and tickets. We also asked them to complete another suvery. We conducted this study in an isolated room. An experimenter sat next to a participant and gave instructions. The same experimenter supervised all participants. We used a Macbook Pro laptop (MB766LL/A) with a built-in camera, and a Canon iP4200 printer. The resolution of the built-in camera was 640×480. We placed the printer and a pair of scissors next to the laptop. We videotaped the whole user study using two camcorders for analysis. RESULTS OF USER STUDY #1 Account Creation Table 1 shows account creation times and their breakdowns. In total, creating an account in the WebTicket condition took 71.1 seconds longer than that of the password condition. In the WebTicket condition, it took less time for participants to complete registration than in the password condition. This was because in the WebTicket condition, the wizard generated passwords on behalf of the participants, while they had to come up with passwords by themselves in the password condition. Table 1 Breakdowns of the account creation times. Numbers denote means and numbers in parentheses denote standard deviations. Asterisks “*” denote that the differences were statistically significant (p < 0.05 in Mann-Whitney U test). (1) Go To a registration page (2) Complete registration (3) Record login process (4) Edit text on a backside (5) Print a ticket (6) Cut and fold a ticket Total Password 20.0 (17.1) *73.0 (33.8) *93.0 (45.8) WebTicket 15.9 (8.9) *50.0 (18.7) 34.4 (21.3) 4.8 (2.8) 19.7 (0.7) 39.3 (11.2) *164.1 (38.3) Login Process Table 2 shows the overall success rates. On the first day, all participants succeeded in both conditions. However, one week after, five participants could not log into their accounts in the password condition, while all participants brought back their tickets and logged into their accounts in the WebTicket condition. Additionally, among those who succeeded in the password condition, it took an average of 1.93 login attempts before successfully logging in. This result indicated that participants were likely to forget their passwords, while they could keep a ticket for one week. Table 3 shows means and standard deviations of the login times of participants who successfully logged in. On the first day, the mean time for the password condition was shorter than the WebTicket condition (p < 0.05 using Mann-Whitney U test). However, one week later, the login time for the password condition increased while that of the WebTicket condition did not, leading to there being no statistically significant difference in the mean login times between the two conditions. Table 2 Success rates of logins. One week later five participants could not log into their accounts using passwords. Asterisk stands for the difference was statistically significant, p < 0.05 in χ 2 test. Password WebTicket On the first day 100% (20/20) 100% (20/20) One week later 75%* (15/20) 100%* (20/20) Table 3 Login time. On the first day login using WebTicket took longer than that using passwords. However, one week later, there was no statistically significant difference between the two conditions. Asterisks stand for the differences were statistically significant, p < 0.05 in Mann Whitney U test. Password WebTicket On the first day *24.9 (12.4) *35.8 (13.2) One week later 44.6 (30.7) 30.5 (12.2) In the WebTicket condition, some participants had difficulty in finding which icon they had to click to launch WebTicket reader dialog. We also observed that some participants opened the home pages and typed their email addresses before launching WebTicket’s reader dialog. This process was unnecessary because WebTicket automatically complete the process when QR code was scanned. These observations indicated that people were not clear about WebTicket’s login process. Thus, we added the instruction on the backside of tickets after the first user study to show the login process clearly (see Figure 1). Table 4 Participants’ perceptions about account creation processes and login processes. The numbers denotes means and the numbers in parentheses denotes standard deviations. One stands for very difficult or very long, and five stands for very easy or very short. Asterisks stand for the differences were statistically significant (p<0.05 in Mann-Whitney U test). Password WebTicket Account Creation Ease Length 2.1 (0.86) 2.5 (0.94) 3.1 (0.51) 2.9 (0.64) Login Ease Length 2.4* (1.1) 2.3* (1.1) 3.1* (0.9) 3.2* (0.7) At the end of the second session, in a post-survey, we asked participants’ perceptions of the login process using 5-point Likert scales. We asked whether the login processes using passwords and WebTicket were easy or difficult, and short or long (Table 4). In terms of ease of the login, participants perceived the login process using passwords rather difficult (2.4), and perceived one using WebTicket as neither easy nor difficult (3.1). The difference between the results in the password condition and the WebTicket condition was significant (p<0.05 using Mann-Whitney U test). In terms of length of the process, participants perceived the login process using passwords long (2.3), and one using WebTicket neither short nor long (3.2). The difference was significant (p<0.01 using Mann-Whitney U test). These results indicated that, although the actual login time using WebTicket was not shorter than the process using passwords, participants perceived that WebTicket was shorter and easier than using passwords. USER STUDY #2: EVALUATING PHISHING RESISTANCE We conducted the second user study to investigate two issues. First, we wanted to evaluate WebTicket including the mobile phone version with higher ecological validity. Second, we wanted to examine the phishing resilience of WebTicket. The study had two sessions: an initial session and a follow-up session one week later. The initial session was similar to the first study, with an extra condition for mobile phone WebTicket. However, the second session was quite different. We asked participants to handle emails, including a phishing email, asking them to complete some tasks in a role-playing scenario. Participants We recruited 35 participants using an existing university recruitment web site. Twenty-nine participants completed the study. None of them participated in the first user study. Their ages ranged from 19 to 57 with a mean age of 30.1 (σ=11.1). Sixteen participants were males and 13 were female. They consisted of 19 university students, two university staffs and eight domestic residents. None of the students were computer science majors. We paid $10 USD for their participation and also paid additional $2 USD for each successful login in the follow-up session. In the initial session, we did not yet tell that they could get the bonus for successful logins. Thus, the bonus did not affect the participants’ choice of passwords, while the bonus gave the participants an incentive to login in the follow-up session. Procedure In the initial session, we explained WebTicket to participants. Then, we asked the participants to create two accounts as a warm-up task, using both the paper-based and mobile phone versions of WebTicket. We then had participants create three accounts in three different mock ecommerce web sites, using password, paper-based WebTicket, and mobile-phone-based WebTicket (randomized order). A change from the first study was that participants could choose any passwords in the password condition. Additionally, in the two WebTicket conditions, WebTicket wizard was not opened initially. Thus, the participants had to open it by themselves. The web sites were same in the first user study except that we added more fields in their registration forms, such as a credit card number field, to make them fit our phishing evaluation. We provided a persona of a university staff, whose identity the participants used to create these accounts. After creating the accounts, we asked the participants to log into their accounts one by one. We also increased the number of dummy tickets to 20 to evaluate scalability of WebTicket. At the end of the initial session, we gave participants their tickets and asked them to bring them back to the follow-up session. In the follow-up session, we evaluated the phishing resilience of the three authentication systems following the procedure used in Egelman et al.’s study [32] as much as possible. We asked participants to handle five emails from a professor. Three of them asked to purchase products using the accounts created in the first session. The other two emails were distracters. When purchasing products, the participants received three confirmation emails and one phishing email. The phishing email was same as one used in Egelman et al.’s study, although we modified shop names and URLs to make it fit with our study. The phishing email said that an order would be delayed and that, unless the participants clicked a link in the email to approve the delay, the order would be canceled. When the participants clicked the link, they went to a simulated phishing web site. In terms of phishing, we divided participants into five conditions. Participants in the first condition received a phishing email against their accounts using a password. Participants in the next two conditions received a phishing email against their accounts using paper-based WebTicket. Participants in the last two conditions received a phishing email against their accounts using mobile-phone-based WebTicket. We used two different kinds of phishing attacks on WebTicket (both paper and mobile phone). The first was a standard phishing attack that tried to trick people into using their username and password to log into a fake site. We call this general phishing. The second kind was a new attack that specifically targeted WebTicket itself, tricking people into giving up their QR codes by using a fake dialog (Figure 5). We define this phishing as WT phishing. In the current WebTicket design, the QR code by itself does not allow attackers to access users’ accounts because the information embedded in QR code is encrypted. However, we thought that the investigation of WT phishing could contribute to the evaluation of alternative designs (e.g., not using encryption). Figure 5. Fake reader dialog implemented by Flash. Users must click allow, then, close to enable a web camera. At the bottom, there was an instruction asking to do so. In WT phishing, the fake dialog was implemented by Flash; hence it had to show the Flash privacy setting dialog asking for access to a web camera. If users choose allow and click close, the fake dialog worked the same way as in WebTicket. We decided not to show any border around the dialog since attackers would not know which border to use, and since users are not good at noticing that something is missing [7]. Moreover, we added an instruction asking users to choose allow and click close to help users to be phished (Figure 5). RESULTS OF USER STUDY #2 Account Creation and Login Table 5 shows account creation times and login times. As described in the previous section, participants had to launch the WebTicket wizard first in the WebTicket conditions. Additionally, in the password condition, we allowed participants to use any passwords, including reusing existing passwords. Although account creation time increased as a result of modification of registration forms, the results were in line with those of the first user study. In the second session, we asked participants to handle five emails. Three of the emails asked the participants to log into their accounts that they created in the first session, and purchase products. Table 6 shows the success rates of the logins. Although we allowed participants to choose any passwords, there were still statistically significant differences between the success rates of passwords condition and that of the two WebTicket conditions. Table 5 Account creation times and login times. The results complied with the results in the first user study. Differences in account creation times between the password condition and the two WebTicket conditions were statistically significant (p < 0.05, using Mann-Whitney U test). Password Paper-based WebTicket Mobile-phone WebTicket Account Creation *113.8 (47.1) *192.3 (61.7) *165.1 (75.6) Login 27.0 (14.6) 30.3 (10.8) 32.5 (12.3) Table 6 Success rates of the logins. Asterisk stands for the difference was statistically significant, p < 0.05 in χ 2 test. Password Paper-based WebTicket Mobile-phone WebTicket On the first day 100% (29/29) 100% (29/29) 100% (29/29) One week later *90% (26/29) *100% (29/29) *100% (29/29) In the second session, we also investigated phishing resilience of passwords and WebTicket. We found that some participants opened the phishing email and close it right away without reading its content to save their time. Thus, we analyzed only the participants who actually read the phishing emails. Moreover, because there was no statistically significant differences between paper-based WebTicket and mobile-phone WebTicket, we combined these two conditions in the following analyses. All participants who read the phishing emails clicked the links in the emails. Table 7 shows the number of participants who typed their email addresses and passwords, or scanned their tickets in the phishing web site. Table 7 The ratios of phished participants out of those who read the phishing emails. The differences between general phishing against password and other two conditions were statistically significant (p < 0.05 using χ 2 test). General Phishing 100%* (6/6) 0%* (0/6) In the WT phishing, seven participants out of ten did not scan their tickets. According to our post-survey, five participants noticed that the fake dialog’s border did not match with the border on their tickets. Two other participants did not notice the difference. They simply clicked close on the privacy setting dialog without reading anything, and found that the web camera was not working. Then, they closed the fake dialog and opened the legitimate reader dialog to scan their tickets to make it work. This illustrates that dynamic security skins could help our participants detect the fake dialog. On the other hand, three participants scanned their tickets using the fake dialog. Interestingly, one of the three initially closed the fake dialog and logged into his account using the legitimate dialog. However, because he was not sure what to do next to approve the delay, he clicked the link in the phishing email again, followed the instruction on the fake dialog carefully, and scanned his ticket using the fake dialog. He noticed that the fake dialog’s border was different; however, he did not relate it to a phishing attack. This finding suggests that it may be better for WebTicket to detect phishing by comparing the contents of the web page shown before users launch the WebTicket dialog and that of the web page specified by a ticket. When WebTicket detects a phishing attack, it can show a warning along with educational material to educate users about phishing scams. DISCUSSION Phishing Resilience Password WebTicket As shown in Table 7, all the participants who read the general phishing emails against their accounts in the password condition were phished. In contrast, using WebTicket, none of the participants were phished by general phishing emails. This result is not too surprising, though, since participants do not know their own passwords with WebTicket, and so cannot fall for a large class of phishing attacks. WT Phishing 30%* (3/10) Our results indicate that participants were not slower than passwords when logging in with WebTicket. Participants also perceived the login process with WebTicket as easier and shorter than with passwords. These results are very encouraging considering that the passwords generated by WebTicket are more secure than user-chosen passwords. Note that we do not intend to replace all passwords with WebTicket. Instead, we want users to choose authentication schemes according to their needs. For frequently used web sites, standard passwords may make more sense because these passwords are less likely to be forgotten and fast to enter in. In contrast, for occasionally used web sites, WebTicket will make more sense because WebTicket can provide a reliable way to login. Additionally, because WebTicket does not require server side modifications, users who have difficulty in memorizing passwords, such as memory impaired or novice users, could choose WebTicket for a site, while others use passwords for the same site. Our second user study also provided interesting example about the importance of feedback in phishing prevention. We observed that one participant went back to the phishing web site after WebTicket prevented the phishing attack. Similarly, the two participants who just clicked close button without noticing the different border did not understand that there were phishing attacks. This implies that unless a system provides feedback to users when it prevents phishing, users could repeat the same thing again. As a result the users could be phished eventually. ALTERNATIVE DESIGNS FOR WEBTICKET In our study, we investigated one possible point in the design space. However, there are cases where different design choices may make more sense. One major design decision was whether to have one ticket for each account, or just have one ticket for multiple accounts. If we had opted for the latter, the passwords would need to be stored on the computer itself, and the ticket would simply be the key to access those passwords. The advantage of this approach is that users do not need to carry many tickets. The disadvantages are in synchronizing account information when new accounts are created (if there are multiple computers), and having a slightly more complex mental model. We have also considered a hybrid approach, having one ticket per important account, and one ticket for all “unimportant” accounts. In this case, the ticket for unimportant accounts might use something like PwdHash [25]. In this design, synchronization does not matter because passwords are generated dynamically. However, this design has challenges dealing with site-specific requirements about passwords without a big database of site-specific password requirements. For instance, some web sites only allow alphabetic and numeric characters for passwords, while others require at least one special character. Another important design choice is whether we should encrypt the information embedded on a ticket. Without encryption, users can log into their accounts from any computer including foreign computers as long as WebTicket is installed. However, past work has found that users mostly access their accounts from their own computers at work or home [33]. As such, we felt that allowing access on foreign computers was a corner case, and allowing it would expose users to a large number of vulnerabilities, including theft of tickets as well as cameras taking pictures of the QR codes. LIMITATIONS OF WEBTICKET AND OUR STUDIES In this section, we discuss some limitations of WebTicket and our studies. One constraint is that WebTicket requires webcams, and either printers (for the paper-based version) or smart phones (for the mobile-phone version). Although we feel that this is an acceptable tradeoff, given that these devices are becoming common, this limitation could hinder WebTicket’s adoption. In the paper-based WebTicket, the durability of tickets is a limitation. Because the ticket is paper, it can become worn out, washed, or crumpled making the QR code illegible. Although, users can address this problem by creating a new ticket, creating backups of existing tickets (by photocopying them), or laminating tickets, these approach incur additional monetary and operational costs. Scalability is also a limitation of the paper-based WebTicket. Our user study implies that people can find a ticket among 10 to 20 tickets, which cover a large portion of users [11,33], with reasonable speed. However, people may not be willing to carry that many tickets (as noted by our participants). As a result, people must keep some of their tickets at secure places, e.g., home or office. Although people access their accounts mostly from their home or office [33], further investigation is needed to see if and how usability is impacted by being able to access some of the accounts only from certain places. One potential weakness with paper-based tickets is that people might leave them near their computers, in which case these tickets are only slightly better than a post-it note with passwords on them (since people can’t use the ticket on other computers). However, depending on one’s threat model, this may not be a huge security risk, especially if one has good physical security that restricts access to computers. Although data shows that people use their own computers most of the time to login [33], there may be cases where users want to access their accounts from a foreign computer. WebTicket does not work well for this use case. One possible solution is to store the master key in a user’s mobile phones and decrypt QR codes on tickets using a mobile phone’s camera. Then, users can access their accounts using user IDs and passwords shown on the mobile phones’ display. However, in this case, there is no phishing protection. Our user studies also have some limitations. One is ecological validity. Since our system is novel, we designed our first user study focusing on internal validity. In the second user study, we put some more weight on ecological validity; however, it was still limited. To evaluate WebTicket with higher ecological validity, we made WebTicket publicly available and are collecting data from actual users. We need further analysis to evaluate WebTicket in the wild. However, we do note that, given the widespread usage of passwords and users’ familiarity with passwords, WebTicket fared quite well in terms of balancing its usability and security. CONCLUSIONS We introduced WebTicket, a novel web account management system using tickets. WebTicket transforms knowledge-based authentication into token-based authentication using a webcam, a printer and paper, or mobile phones. WebTicket works with existing web sites without having to modify existing servers. Through two user studies consisting of 49 participants, we found that participants perceived the account creation process using WebTicket as not worse than the account creation process using password, and that the login process using WebTicket was easier and shorter than the login process using passwords. WebTicket also provided reliable authentication after one week. Moreover, WebTicket provided good phishing protection. Although there are limitations, we believe that WebTicket works quite well among good portion of accounts and users. REFERENCES 1. eToken. http://www.aladdin.com/etoken/. 2. QRCode.com. http://www.denso-wave.com/qrcode/. 3. RSA securID http://www.rsa.com/node.aspx?id=1156. 4. A. Adams and M. Sasse. Users are not the enemy. Communications of the ACM, Jan 1999. 5. S. Brostoff and M. Sasse. Are passfaces more usable than passwords: A field trial investigation. In Proc. of HCI 2000, (2000). 6. S. Chiasson, R. Biddle, and P. V. Oorschot. A second look at the usability of click-based graphical passwords. In Proc. of SOUPS (2007). 7. R. Dhamija and J. Tygar. The battle against phishing: Dynamic security skins. In Proc. of SOUPS (2005). 8. A. Dirik, N. Memon, and J. C. Birget. Modeling user choice in the passpoints graphical password scheme. In Proc. of SOUPS (2007). 9. K. Everitt, T. Bragin, J. Fogarty, and T. Kohno. A comprehensive study of frequency, interference, and training of multiple graphical passwords. In Proc. of CHI (2009). 10. Gartner. Automated password resets can cut it service desk costs. 2004. 11. S. Gaw and E. Felten. Password management strate-gies for online accounts. In Proc. of SOUPS (2006). 12. J. T. Hallinan. Why We Make Mistakes. Broadway, 2009. 13. E. Hayashi, R. Dhamija, N. Christin, and A. Perrig. Use your illusion: secure authentication usable anywhere. In Proc. of SOUPS (2008). 14. H. Ishii and B. Ullmer. Tangible bits: towards seamless interfaces between people, bits and atoms. In Proc. of the SIGCHI (1997). 15. D. V. Klein. ”foiling the cracker”: A survey of, and improvements to, password security. In Proc. of Second USENIX Workshop Security, (1990). 16. S. Klemmer, M. Newman, and R. Farrell. The designers’ outpost: a tangible interface for collaborative web site. In Proc. of UIST (2001). 17. C. Kuo, S. Romanosky, and L. Cranor. Human selection of mnemonic phrase-based passwords. In Proc. of SOUPS (2006). 18. S. L. Learning 10,000 pictures. Quarterly Journal of Experimental Psychology, (1967). 19. W. MacKay. Is paper safer? The role of paper flight strips in air traffic control. ACM Transactions on Computer-Human Interaction, (1999). 20. J. McCune, A. Perrig, and M. Reiter. Seeing-isbelieving: Using camera phones for human-verifiable authentication. In IEEE S&P (2005). 21. D. McGee, P. Cohen, R. Wesson, and S. Horman. Comparing paper and tangible, multimodal tools. In Proc. of SIGCHI (2002). 22. T. Moran, E. Saund, W. V. Melle, A. Gujar, K. Fishkin, and B. Harrison. Design and technology for collaborage: collaborative collages of information on physical walls. In Proc. of UIST (1999). 23. L. Nelson, S. Ichimura, E. Pedersen, and L. Adams. Palette: a paper interface for giving presentations. In Proc. of CHI (1999). 24. A. Paivio and T. Rogers. Why are pictures easier to recall than words? Psychonomic Science, (1968). 25. B. Ross, C. Jackson, N. Miyake, D. Boneh, and J. Mitchell. Stronger password authentication using browser extensions. In Proc. of the USENIX Security(2005). 26. M. Sasse, S. Brostoff, and D. Weirich. Transforming the ‘weakest link’— a human/computer interaction approach to usable and effective security. BT technology journal, (2001). 27. A. Whitten and J. Tygar. Why johnny can’t encrypt. In USENIX Security, (1999). 28. S. Wiedenbeck, J. Waters, J. Birget, and A. Brodskiy. Passpoints: Design and longitudinal evaluation of a graphical password system. International Journal of Human-Computer Studies, (2005). 29. J. Yan, A. Blackwell, R. Anderson, and A. Grant. Password memorability and security: Empirical results. In IEEE Security & privacy, volume 2, pages 25–31, Jan 2004. 30. K. Yee, K. Sitaker. Passpet: convenient password management and phishing protection. In Proc. of SOUPS (2006). 31. Your Top 20 most frequently used passwords. http://www.tomshardware.com/news/imperva-rockyoumost-common-passwords,9486.html 32. S. Egelman, L. F. Cranor, J. Hong. You've been warned: an empirical study of the effectiveness of web browser phishing warnings. In Proc. of SIGCHI (2008) 33. E. Hayashi, J. I. Hong, A Diary Study of Password Usage in Daily Live. CyLab Tech. Report (2010)