Abiodun Ogunyemi

David Lamas
email: david.lamas@tlu.ee

Emmanuel Rotimi Adagunodo

Isaias Rosa
email: isaiasbr@gmail.com

Isaias Barreto Da Rosa

HCI Practices in the Nigerian Software Industry

Keywords: HCI, Human-Centred Design, Human-Centred Software Engineering, Usability, HCI Education

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Although the field of human-computer interaction has been in existence for more than three decades, its spread has yet to be significant. Most of the spread has been in the developed countries and developing countries continue to lag behind [START_REF] Smith | Institutionalizing HCI in Asia[END_REF].

Nigeria has an overwhelming population of 150 million people, which also accounts for approximately 20% of Africa's population (situation in 2012) [START_REF] Hotez | Nigeria: "Ground Zero" for the High Prevalence Neglected Tropical Diseases[END_REF]. Recently, the Nigerian government introduced a cashless economic policy, which implies that economic transactions are to be conducted electronically. Furthermore, many businesses have been moved online, and e-commerce is becoming a major business trend in the country [START_REF] Akintola | Appraising Nigeria Readiness for E-Commerce Towards Achieving Vision 20:20[END_REF]. Thus, the role of software systems and services cannot be ignored in Nigeria. Approximately 33% of Nigeria residents are connected to the Internet in a country where approximately 67% of the Internet users are mobile 1 . Nigeria is in the 133 rd position in the recent World ICT development index 2 .

Although it is the biggest Economy in Africa (primarily because it is the biggest oil producer in Africa), Nigeria still remains a developing nation . It can be envisaged as well what leading role Nigeria could play in promoting HCI in Africa in terms of the country's size and economy.

The story of HCI uptakes in developed and developing countries so far, might not differ, especially, when talking about certain practices such as usability engineering, user experience and Human-Centred Design (HCD). For example, Larusdottir, Haraldsdottir, and Mikkelsen, [START_REF] Larusdottir | User Involvement in Icelandic Software Industry[END_REF], ran a survey of the Icelandic software industry to determine how practitioners perceive the importance of usability and user involvements in software projects. The authors found that most of the companies use their own method regarding user involvement methods, and more than a third of the organizations surveyed, are skeptical regarding the importance of usability. Similarly, Ji and Yun, [START_REF] Ji | Enhancing the M inority Discipline in the IT Industry: A Survey of Usability and User-Centered Design Practice[END_REF], conducted a survey of 184 Korean IT professionals and 90 User Interface/Usability practitioners, regarding User-Centred Design (UCD) and usability practices in the Korean IT industry. Their results show that awareness of UCD/Usability is high, but the reality of its application in projects is not fully realized.

The Nigerian software industry is still very young and in its formative stage. There are not yet regulations for the industry and most software companies use in -house methods [START_REF] Egbokhare | Causes of Software/Information Technology Project Failures in Nigerian Software Development Organizations[END_REF][START_REF] Soriyan | A Profile of Nigeria's Software Industry[END_REF]. There are many small companies and only a few of these companies focus on custom developments [START_REF] Lizano | Usability Evaluation in a Digitally Emerging Country: A Survey Study[END_REF]. Most custom developments are largely based on web applications. Very few of these organisations develop off-the-shelf software in which lower-level applications such as payroll, human resources management, educational, and accounting solutions are built from scratch as semi-packages and configured for various customers over time [START_REF] Soriyan | A Profile of Nigeria's Software Industry[END_REF]. There are very few universities that offer an elementary course in HCI. Thus, there are very scarce sources to describe the state of HCI practices in Nigeria.

This paper describes and discusses the results from a recent field study regarding the state of HCI practices in Nigeria. To the best of our knowledge, a study such as this has not been conducted in Nigeria so far.

In the next section, we present our method. Next, we present the results, and finally, we discuss the results and describe future work that needs to be done.

Method

An online survey was deployed using the LimeSurvey open source tool. Respondents were targeted from indigenous software companies in Nigeria. The focus of the survey was on how Nigerian software practitioners conduct usability, user experience and human-centred design practices. The questionnaire was designed in such a way that some questions would only pop up, if an earlier answered question is related to the next one. Furthermore, there were questions, which allow respondents to choose multiple options and there were some, which allow single option.

Prior to the commencement of this study, the Institute of Software Practitioners of Nigeria (ISPON) was partnered with and a list comprising 50 indigenous software companies was obtained. A database search on relevant websites was made and through this search, a total of 95 companies were invited through e-mail to join the study. Sixty-seven companies participated in the survey, which gave us a response rate of 70%. However, only 22 responses were useful for our analysis. Forty-five responses were rejected because they did not answer at least 75% of the questionnaire [START_REF] Hussey | Business Research: A Practical Guide for Undergraduate and Postgraduate Students[END_REF].

In order to strengthen and exemplify the results of the survey, we conducted ten semi-structured interviews in three indigenous software companies. The three companies were randomly selected. One of the goals of the interviews was to deepen our understanding of the keys issues regarding HCI practices in Nigeria. This study was conducted between October 2014 and December 2014.

Results

Demographics

A majority of the respondents came from the software development sector [START_REF] Hussey | Business Research: A Practical Guide for Undergraduate and Postgraduate Students[END_REF] and information technology services [START_REF] Hussain | Current State of Agile User-Centered Design: A Survey[END_REF]. Other sectors include telecommunication (1), non-governmental organisation ( 1) and e-commerce [START_REF] Agarwal | Risks of Rapid Application Development[END_REF].

Regarding organisation size, 12 participants were from very small companies (10-20 staff), 5 were from small companies (50-90 staff), 3 were from medium companies (100-199 staff), and one participant each was from a large company (200-499 staff) and a very large company (more than 500 staff) respectively. This suggests that the Nigerian software industry is primarily composed of small companies. A previous study also suggested a similar trend [START_REF] Soriyan | A Profile of Nigeria's Software Industry[END_REF]. Twenty companies are located in the South-West of Nigeria and one organisation each comes from the North and one from the South. Fifteen companies are located in Lagos . Lagos is the Economic Capital of Nigeria where the most prominent Nigerian Companies are located .

Regarding their educational qualifications , 15 respondents (68%) possess a BSc degree, three respondents each (14%), have diplomas and other certificates and one respondent (4%), has a High School certificate. Figure 1 (left-hand side) is the overview of the respondents' background regarding their first degree. The results show that 45% of the respondents posses s a Bachelor's degree in Computer Science. With respect to the composition of software teams, the results indicate that there are very few HCI experts in the teams, and that the major aspect of HCI found in practice is graphic design. The results are also in Figure 1 (right-hand side). Regarding HCI awareness, 17 organisations (77%) are aware and five organisations (23%) are not aware.

10# 0# 1# 1# 1# 1# 1# 7# 45%# 0%# 5%# 5%# 5%# 5%# 5%# 32%# 0# 2#
Of the 15 respondents, who possess a BSc degree, only 9 indicate they took a course in HCI, and when asked to describe these HCI courses, some of the responses are: "MYT364 -Fundamentals of interaction design" "Covered just the basics of HCI" "Visibility and Affordance" "It involves the study, planning, design and uses of the interaction between people (users) and computers" The roles of the respondents in their organisations are Usability Designer (2), Programmer [START_REF] Gulliksen | Key Principles for User-Centred Systems Design[END_REF], Software Engineer (5), UX Designer (1), Project Manager (3), CEO (2), Technical Resource Engineer (1) and Chief Software Architect [START_REF] Agarwal | Risks of Rapid Application Development[END_REF].

The responses regarding the HCI courses suggest that this category of practitioners received elementary HCI knowledge. However, it is imperative that these graduates are well-equipped with hands-on skills in order to succeed in the industry [START_REF] Phillips | The Integration of HCI and Software Engineering[END_REF].

Regarding the years of experience of the respondents , the results obtained suggest that most of the respondents might be relatively young in their main roles. Eleven respondents (50%), have less than five years of experience. Seven respondents (32%), have 5-10 years of experience, one respondent (9%) each had 10-15 years of experience and more than 15 years of experience respectively. In comparison with the respondents' educational backgrounds , it is possible that the bulk of the practitioners with less than five years of experience are those with some level of HCI education.

We wanted to know what software development methodologies are used in respondents' organisation. Figure 2 reveals that most of the organisations used the Rapid Application Development (RAD) methodology. Figure 2 also reveals that none of the software organisations used such methods as Rational Unified Process, Unified Process, V-Model and Spiral. We asked if the organisations address user experience (UX). Seventeen organ isations (77%) were positive and five organisations (23%) indicate they do not address UX.

Fig.3. How UX is perceived in the respondents' organizations (multiple options allowed)

The results in Figure 3 suggest that the organizations might not fully understand the distinction between user experience and usability issues. The results show that pragmatic aspects of user experience are prioritized by the organisations ahead of hedonic aspects such as fun/joy and helpfulness. These findings are also similar to the findings by [START_REF] Wechsung | Views on Usability and User Experience: From Theory and Practice[END_REF].

When asked about the frequency of conducting us ability testing in projects, 12 organisations (55%) indicate they always conduct usability testing and 10 organizations (45%), indicate they sometimes do. Figure 4 (left-hand side) show some reasons why usability testing is not always conducted in the ten organisations.

The major reason indicated by the ten organisations was time constraints. This is consistent by the findings of [START_REF] Ardito | Lanzilotti R: Investigating and Promoting UX Practice in Industry: An Experimental Study[END_REF]. However, software organisations that neglect usability aspects due to time or cost constraints, often spend more time and money on training and fixing bugs [START_REF] Lizano | Usability Evaluation in a Digitally Emerging Country: A Survey Study[END_REF][START_REF] Shneiderman | Designing the User Interface: Strategies for Effective Human-Computer Interaction[END_REF].

Fig. 4. Reasons for not conducting usability tests and the typ es of users selected for usability tests when they were conducted

Respondents also provide information regarding the kind of users selected for usability testing in their organizations. This is shown in Figure 4 on the right. As it can be seen, eleven organisations (50%) indicate they use a representative sample of users for usability testing. Four organisations (18%), used their own employees, four organisations (18%), used their customer's employees and three organisations (14%), used an arbitrary sample of actual users.

Similarly, some challenges as presented in Table 1 s uggest reasons for the choice of RAD in most of the organizations. Rapid Application Development is particularly used where organisations are constrained by a short time frame for software projects, cost, and need for quality [START_REF] Agarwal | Risks of Rapid Application Development[END_REF]. However, organizations suffer when they substitute HCI aspects for time and cost [START_REF] Gulliksen | Key Principles for User-Centred Systems Design[END_REF]. A respondent reports: "It's time consuming." We requested the organisations to select the principles for HCD, being applied by them, according to the ISO 9241-210 framework [START_REF]Ergonomics of Human-System Interaction -Part 210: Human-Centred Design for Interactive Systems[END_REF]. The results obtained and presented in Figure 5 show that the only aspect that is more prioritized is the understanding of users, tasks and environments. Other important dimensions such as user involvement and involvement of multidisciplinary -skilled experts are less prioritized. Our results in this regard, are similar to the study by [START_REF] Larusdottir | User Involvement in Icelandic Software Industry[END_REF].

Interviews

We conducted ten semi-structured interviews with software practitioners in three companies. Two of the companies are small-sized and are involved with custom development. The other company is medium-sized and is involved with off-the-shelf development. We wanted to know about interviewees' educational background. None of the interviewees, including those saddled with user interface design, have strong HCI backgrounds. At their best, these interviewees have developed their knowledge of HCI from reading HCI books and web descriptions of HCI practices such as usability. One of the interviewees, a Chief Technical Officer (CTO) in one of the small-sized companies, responded: "In trying to protect ourselves, we found ourselves implementing HCI." The insight we can draw here is that of an educational limit.

Regarding user experience and human-centred design practices, we can say that the practitioners' organizations are not implementing these HCI practices, as we would expect. There are a couple of issues to justify our assumption. For example, none of the companies have a UX expert and no interaction design labs exist. The Project Manager (PM) in the medium-sized company attests: "one area that we know we need to still work on is even our own development standards; we have not accepted that we are there, (in terms of) our benchmarks..." The PM also indicated their challenge in doing UX work: "we don't have a lab to say 'change the colour and see what people react to?' we don't do scientific experiment s to decide what is the best colour scheme for this and that."

Regarding usability practices, again, we see some limitations in all of the three companies. As explained by the CTO of the medium-sized company, although the company uses focus groups for product conception and evaluation, there is bias in the user selection. The CTO hints : "we get people within the company at different levels of IT to come and do like a focus group and run through this piece of software and throw up their challenges." We do not agree that that using our own employees would provide objective assessments for obvious reasons. In one of the small companies, a programmer, when asked about when to involve end-users in usability testing, responded: "when the software is about to be implemented." The PM in the medium-sized company corroborates by indicating that: "end-users are coming later into things that have been developed in many cases."

We wanted to know more about the importance of end -user involvement in software projects. The PM in the medium-sized company gave a hint: "Where I see the involvement of the users would be because in a project for example, we are dealing with a specified level of users, maybe the senior users, the technical users, within the company to accept your product." We therefore, asked the company's perception of the end-user. The response is: "Those are the people (the senior users and technical users) I call end-users per se."

Finally, we found out through the interviews, that none of the three companies was familiar with the ISO 9241-210 framework for human-centred design. Thus, the companies only used their own methods. However, we found promise for the adoption of HCI practices in these companies. All the companies are aware of HCI, strive to build intuitive and visually appealing products, albeit the companies lack the expertise to engage in more productive HCI practices.

Discussions

The overarching insight drawn from our study is that there is a major gap between what HCI practice is elsewhere and how it is currently practiced in the Nigerian software companies investigated. It appears that HCI education and practice in Nigeria so far, are at the same level. Although HCI awareness is there and there is basic knowledge of HCI being applied in the industry, several issues exist which limit the uptake of HCI practices in Nigeria.

End users' involvement is lacking in the way software development is carried out in all the companies investigated. As Nigeria has embraced a cashless economy, people involvement in software projects is critical. A major problem regarding end user involvement in Nigeria could be that of the perception of who the end user actually is. So far, we have not seen it documented in the literature that the end -users should be technical people and senior employees. The primary purpose for users involvement seems to be endorsement of a product. This would not be ideal for an information society.

Government policies are reported to be plodding and ineffectual. For example, the current software policy is yet to be enforced and many of the government actions are spontaneous. However, as can be seen in the introduction, the software industry in Nigeria is still in its formative stage and it is clear that standards and regulations are lacking as well.

The level of HCI knowledge in Nigeria currently, is limited. Thus, the industry is not able to give enough to meet the demands from the market. There could be a need to review the HCI education curriculum to ensure that it matches global standards. Unlike in the developed countries where HCI practices have advanced, the story is quite different in developing regions such as Africa (see e.g. [START_REF] Hussain | Current State of Agile User-Centered Design: A Survey[END_REF]). In a recent study conducted in Colombia by Collazos and Merchan, [START_REF] Collazos | Human-Computer Interaction in Colombia: Bridging the Gap between Education and Industry[END_REF], the need was stressed for local universities to "develop real-world projects as experimental studies that consider industry needs, bringing together participants from both academia and industry " [p.8]. Similarly, Winschiers, [START_REF] Winschiers | The Challenges of Participatory Design in an Intercultural Context : Designing for Usability in Namibia[END_REF], in a study in Namibia emphasized that "methods have to be evaluated within the design process and adopted to the context" [p.75].

However, in comparison to other developing countries such as India and China where HCI practice is growing rapidly [START_REF] Smith | Institutionalizing HCI in Asia[END_REF], the same cannot be said of Nigeria. At best, HCI is just at the awareness level in Nigerian software companies. However, the Nigerian market environment seems to be driving these software companies towards fully taking up HCI practices. A CTO of one of the small companies, when asked how they came to be aware of HCI, responded: "maybe the market taught us."

This study has a major limitation. Although we strove to get many participants for the survey, our sample is not representative. This is still a major challenge to most quantitative studies [START_REF] Cycyota | What (Not) to Expect When Surveying Executives: A M eta-Analysis of Top M anager Response Rates and Techniques Over Time[END_REF].

In future work, we plan to investigate HCI education in Nigerian universities.

Fig. 1 .

 1 Fig.1. Respondents' first degree backgrounds and composition of software teams

  a n : C o m p u t e r #I n t e r a c < o n # S o

Fig. 2 .

 2 Fig.2. Software development methodologies used in respondents' organizations (multiple options allowed)

Fig. 5 .

 5 Fig. 5. HCD principles used in respondents' organizations (multiple options allowed)

Table 1 .

 1 Challenges indicated for conducting usability, user experience and HCD Practices

	Challenges	Respondents	Percentage (%)
	Lack of standard tools for integration	2	9%
	Lack of knowledge of best practices	5	23%
	Short time to deploy software projects	7	32%
	Cost of hiring HCI experts	7	32%
	Ineffective Government policies	1	4%

UN e-Government survey -http://unpan3.un.org/egovkb/Portals/egovkb/Documents/un/2014-Survey/E-Gov_Complete_Survey-2014.pdf

[START_REF] Akintola | Appraising Nigeria Readiness for E-Commerce Towards Achieving Vision 20:20[END_REF] ICT development index -https://www.itu.int/en/ITU-D/Statistics/Documents/publications/mis2014/M IS2014_without_Annex_4.pdf

Acknowledgments. This research was supported by European Social Fund's Doctoral Studies and Internationalisation Programme DoRa, which is carried out by Foundation Archimedes.


Teddy Seyed
email: teddy.seyed@ucalgary.ca

Xing-Dong Yang
email: xing-dong.yang@dartmouth.edu

Anthony Tang

Saul Greenberg

Jiawei Gu
email: gujiawei@baidu.com

Xiang Cao
email: xiangcao@acm.org

CipherCard: A Token-based Approach against Camerabased Shoulder Surfing Attacks on Common Touchscreen Devices

Keywords: Shoulder-surfing attack, capacitive touchscreen, PIN entry, security

We present CipherCard, a physical token that defends against shoulder-surfing attacks on user authentication on capacitive touchscreen devices. When CipherCard is placed over a touchscreen's pin-pad, it remaps a user's touch point on the physical token to a different location on the pin-pad. It hence translates a visible user password into a different system password received by a touchscreen, but is hidden from observers as well as the user. CipherCard enhances authentication security through Two-Factor Authentication (TFA), in that both the correct user password and a specific card are needed for successful authentication. We explore the design space of CipherCard, and describe three implemented variations each with unique capabilities. Based on user feedback, we discuss the security and usability implications of CipherCard, and describe several avenues for continued exploration.

Introduction

Capacitive touchscreens have become the primary input mechanism for many security related applications such as access control systems (e.g. door locks), public kiosks (e.g. ATMs, cash registers, point of sales via large screens), or mobile aut hentication (e.g. payment through personal mobile devices). Because user authentication through touchscreens is often carried out in public spaces, the user is susceptible to shouldersurfing attacks: unscrupulous individuals or cameras can see the password or PIN being entered into the system [START_REF] Bianchi | T he phone lock: audio and haptic shouldersurfing resistant PIN entry methods for mobile devices[END_REF][START_REF] Kumar | Reducing shoulder -surfing by using gazebased password entry[END_REF][START_REF] Luca | Now you see me, now you don't: protecting smartphone authent ication from shoulder surfers[END_REF][START_REF] Shirazi | Assessing the vulnerability of magnetic gestural authentication to video-based shoulder surfing attacks[END_REF][START_REF] Wiedenbeck | Design and evaluation of a shouldersurfing resistant graphical password scheme[END_REF][START_REF] Luca | Back-of-device authentication on smartphones[END_REF]. Further exacerbating the problem, user interfaces for touchscreens are often designed to be larger (because of the fat finger problem [START_REF] Vogel | Shift: a technique for operating pen -based interfaces using touch[END_REF]), making it difficult to shield input from observation. As well, the lack of haptic feedback on touchscreens makes eyes-free operation difficult, which means that users cannot easily shield the display from view.

To enhance user authentication security on touchscreen devices, we present Ci-pherCard, a physical token that protects a users' PIN entry against camera-based shoulder-surfing attacks. CipherCard (Fig. 1.) is an opaque overlay that is placed atop a touchscreen's password input area (e.g., a touchscreen PIN pad), where it serves as a physical proxy for the touchscreen's original password input UI. When a user touches a button on the CipherCard, this touch point is remapped to a different button location on the touchscreen via its internal wiring, hiding the actual input location from observers or hidden cameras. CipherCard translates the input sequence ("user password") into a distinct sequence ("system password") that is received by the touchscreen. For example, Fig. 1. illustrates a user entering their user password of '1 3 5 8' into CipherCard, which is translated to the system password of '4 1 2 6'. Thus , the system password is hidden from observers or hidden cameras. A shoulder-surfing attacker may acquire the user password, but without the user's CipherCard, the attacker cannot successfully authenticate. CipherCard mappings can be permanent (where they are manufactured with a single translation for use on particular systems) or reconfigurable (where a user can specify the translation between user and system passwords). CipherCard allows a user to choose a set of easy-to-memorize user passwords, and use them as proxies for "strong" system passwords (e.g. PINs with random combinations). Renewing a sy stem password can be as easy as getting a new CipherCard or reconfiguring an existing one, where the user password can remain the same. CipherCard can be designed to automatically adapt to different password input UIs (e.g. size, orientation, and layout), and vice versa.

The CipherCard authentication scheme raises many engineering, security, and us ability questions that warrant long-term research. At this early stage, we focus on a thorough exploration of the design space. We implemented three prototypes: cardshaped, wallet-based, and phone-based CipherCards, each with a unique form factor and usability features. To evaluate our progress, we conducted two studies: first, a feasibility evaluation with five usability professionals, where we identify usability issues of the three prototypes. Based on the findings, we proposed an improved de-sign. Second, we conducted a separate workload evaluation to verify our improved design as well as the overall usability and security of CipherCard.

Our contributions in this paper are three-fold: (a) a novel CipherCard concept that allows remapping for key entries to protect PIN input against camera-based attacks. (b) An exploration of the design space of CipherCard concept through the impleme ntation of three prototypes, and (c) a feasibility evaluation and a workload evaluation that validate the usability of CipherCard and its form factors.

Related Work

Researchers have developed several authentication schemes and interaction tec hniques with the goal of hindering shoulder-surfing attacks. However, many are still susceptible to camera-based attacks, where the input can be reviewed in detail at a later time.

Cognitive trap techniques increase the complexity of the authentication process , for example by showing distractive keystrokes or cursor movements to observers. This makes it more difficult for an observer to derive the password [START_REF] Kim | A new shoulder-surfing resistant password for mobile environments[END_REF][START_REF] Keyani | Spy-resistant keyboard: more secure password entry on public touch screen displays[END_REF] from observing a single authentication instance. However, these schemes are still susceptible to camera-based attacks that afford analyzing multiple authentication instances in detail. In contrast, some schemes allow the user to create a customized 3D gesture (e.g. [START_REF] Shirazi | Assessing the vulnerability of magnetic gestural authentication to video-based shoulder surfing attacks[END_REF][START_REF] Kratz | AirAuth: a biometric authentication system using in-air hand gestures[END_REF]). These have been demonstrated to be challenging to forge from simple video review; however they are still susceptible to automated video capture and ana lysis from depth cameras. CipherCard occludes the real password entered into the system, thus resisting camera-based attacks Hiding PIN input techniques shield against the visibility of input actions. In its simplest form, people can position their bodies/hands to shield their actions from an observer's view [START_REF] Kim | Multitouch authentication on tabletops[END_REF]; however, most users do not do this [START_REF] Luca | T owards understanding AT M security: a field study of real world AT M use[END_REF]. While easy to perform, shielding is vulnerable to well-placed cameras [START_REF] Luca | T owards understanding AT M security: a field study of real world AT M use[END_REF] or thermal imaging after entry [START_REF] Mowery | Heat of the moment: characterizing the efficacy of thermal camera-based attacks[END_REF]. Many technical approaches also try to decrease the visibility of password entry. Examples include back-of-the-device PIN entry [START_REF] Luca | Now you see me, now you don't: protecting smartphone authent ication from shoulder surfers[END_REF][START_REF] Luca | Back-of-device authentication on smartphones[END_REF], eye gaze input [START_REF] Luca | Look into my eyes!: can you guess my password? SOUPS '09[END_REF], pressure [START_REF] Kim | Multitouch authentication on tabletops[END_REF], and haptic/tactile feedback as secret input or output channels to assist password entry [START_REF] Bianchi | T he phone lock: audio and haptic shouldersurfing resistant PIN entry methods for mobile devices[END_REF][START_REF] Sasamoto | Undercover: authentication usable in front of prying eyes[END_REF][START_REF] Luca | #223, mann: Vibrapass: secure authentication based on shared lies[END_REF]. Although resistant to direct human observation, all remain susceptible to video-or audio-based observation attacks. For example, a pressed fingertip can be detected from the change of its color [START_REF] Kim | Multitouch authentication on tabletops[END_REF]. Similarly, haptic/tactile feedback can be detected from a recorded sound track [START_REF] Luca | #223, mann: Vibrapass: secure authentication based on shared lies[END_REF]. CipherCard allows PIN input to be completely hidden from observers, video and audio recording.

Biometric methods distinguish users based on biometric characteristics, e.g. fingerprint, hand geometry, retina, etc. [START_REF] Liu | A Practical Guide to Biometric Security T echnology[END_REF] or their behavioral signatures [START_REF] Sae-Bae | Biometric-rich gestures: a novel approach to authentication on multi-touch devices[END_REF]. Biometric methods are effective against video-based attacks but suffer major drawbacks preventing them from wide deployment in real-world applications. For example, physiological biometric characteristics are not renewable after the attacker has successfully forged them. Furthermore, behavioral biometric signatures are prone to high recognition error, making them impractical [START_REF] Sae-Bae | Biometric-rich gestures: a novel approach to authentication on multi-touch devices[END_REF].

Physical token methods require that the user present a physical object to a reader (e.g. keyfob), and these are immune to shoulder-surfing [START_REF] Roth | #252, ldenring: T he IR ring: authenticating users' touches on a multi-touch display[END_REF]. However, these require entry systems to have special hardware to detect the physical object, such as an RFID card readers. Recent advances have begun to explore general capacitive touchscreens as sensors; however this is still in its infancy [START_REF] Vu | Distinguishing Users with Capacitive T ouch Communication[END_REF]. Of course, a lost or stolen token could still allow individuals to pass the authentication. This is not the case for Ci-pherCard, which requires both the token and password to pass authentication.

Two-factor authentication (TFA) requires a user to present at least two of three factors: knowledge ("something you know", e.g. password or PIN), inherence ("something you are", e.g. biometric characteristics), and possession ("something you have", e.g. physical token) [START_REF] Schneier | T wo-factor authentication: too little, too late[END_REF] to enhance authentication security. Combining a password with a physical token requires a dedicated hardware (e.g. RFID readers) that is usually unavailable on a typical touchscreen device. A popular solution involves asking a user to enter 2 codes (e.g. a PIN + a 1-time passcode generated by a token) through a 2step authentication process [START_REF] Schneier | T wo-factor authentication: too little, too late[END_REF]. A common problem in these solutions is that they are vulnerable to man-in-the-middle attacks. Whereas, CipherCard is resistant to such attacks. Additionally, CipherCard does not expose system passwords to attackers. This allows a number of novel applications to be carried out by CipherCard users. For example, a user can use an easy-to-memorize user password while the system can be protected by a strong system password. The user can also use a single user password to authenticate multiple systems each protected by a different system password. Finally, the user can renew a system password while continuing to use the existing user password (see details in Section 7).

CipherCard Concept and Design Space

CipherCard is an opaque overlay that is placed on top of a software authentication UI, acting as a physical proxy to the UI elements. Users can place it on a touchscreen, and use it as a PIN pad to enter PINs. When touching the front side of the card (e.g., a button), the card generates a touch point on its back, however at a different input location on the underlying screen. This creates a randomly preset or user specified permutation between the two sets of locations on the two sides of the card. Thus, the Ci-pherCard provides substitution cipher capabilities, translating the touch input sequence on the CipherCard (user password) to another unique sequence that is sent the touchscreen (system password). The system password is never exposed. So long as the touchscreen UI and card layout are compatible, which can be achieved through software modification on touchscreen devices, one CipherCard can be reused for an arbitrary number of different PINs for different applications.

The concept behind CipherCard can be realized in a number of different ways. We articulate the factors that describe this design space, and the trade-offs these present.

Passive vs. active

CipherCards can be made either passive or active. A passive CipherCard translates touch via electrical wiring, and requires no battery or external power source. The passive CipherCard can be cheap to design, produce, and customize for various touchscreen devices and authentication UIs. It can be disposed and replaced when a user needs a different pattern (e.g. to renew a system password) at a minimal cost. It can also be made reconfigurable (e.g., via jumpers) with more engineering effort and monetary cost.

In contrast, an active CipherCard receives user touches, and uses a control circuit and electrodes to remap those to the touches matching those required by the capacitive sensor on the authentication device. This mapping can be reconfigured through software, giving the user control over the substitution cipher. Furthermore, it is poss ible to generate complex mappings, where a single tou ch on the front side generates multiple fake "touches" on the back side (i.e. a 1-to-m mapping). An active Cipher-Card has chips, circuits, and software, and thus is more costly.

Input/output resolution

The input and output resolution of CipherCard is determined by the number of electrodes on either side of the card. The output resolution of CipherCard is also determined by authentication UIs and the input required. We restricted our early explorations to simple PIN pads of 10 electrodes (to enable 0-9 number entry); however, it is possible to scale CipherCard keypads with more keys, and even to gestural entry, given higher resolution and electrode density.

Form Factor

CipherCards should be easy to carry and deploy. For example, it can resemble a credit card carried in a wallet or purse, or ID tag worn on clothing. Alternatively, it can be integrated into flat daily personal belongings, e.g. a wallet or phone case (that flips open) or even an existing bank or credit card-this avoids the need to carry an extra card. Integrating a passive card into personal belongings can be relatively easy due to its simplicity, but can be challenging for an active card without significantly impac ting the normal usage of the personal item. Finally, an active CipherCard can be integrated into existing personal electronic devices, e.g. smartphones or tablets.

UI Alignment

A practical concern is the variety of sizes and layouts of PIN pads may not (by default) match that of a CipherCard. Having a mechanism that can automatically align the two interfaces may largely improve the practicality of the concept. Fixed Alignment to PIN pad. A passive card must be made to match a particular touchscreen layout and is not scalable to UIs with different layouts or button sizes. An active card could utilize higher output resolution to be able to scale to different UI layouts and button sizes (within the card's physical dimensions).

PIN pad aligns to CipherCard. An alternative approach could be to have the software PIN pad align with a CipherCard (either passive or active) automatically. This could be achieved by, for example, adding spatial tags to CipherCard [START_REF] Yu | T UIC: Enabling T angible Interaction on Capacitive Multi-touch Displays[END_REF]. This would allow the touchscreen to identify the size, position, and orientation of a Ci-pherCard, and align the PIN pad interface accordingly. We expect that the size and layout of the buttons inside PIN pad boundaries can follow a common standard, thus once boundaries are detected by the touchscreen device, the buttons can be automatically aligned with the electrodes of the CipherCard. In cases when custom sizes and layouts are needed, this information can be pre-stored in the touchscreen devices, and can be loaded upon receiving an encoded 'request' from the CipherCard. A request can be encoded into a certain touch patterns (either static or dynamic) based on the pattern of electrodes interpreted by the touchscreen [START_REF] Yu | T UIC: Enabling T angible Interaction on Capacitive Multi-touch Displays[END_REF].

Finally, the system software can be used to consider only the relative locations (rather than the absolute locations) of the generated touches, where it can match it against a given pattern. That is, the numeric password is treated as a gestural password. While this means that the CipherCard can be placed anywhere on the system screen, security is somewhat reduced as some key combinations may create the same gestural pattern.

CipherCard Prototypes

We developed three proof-of-concept prototypes based on this design space: a passive credit card sized prototype; a passive wallet-based prototype, and an active smartphone-based prototype. These prototypes are described below and are the su bject of our feasibility and usability studies.

Card-shaped CipherCard

CipherCard works based on the fact that touch input can be simulated by any condu ctive object in contact with the capacitive sensor and electrically connected to the u ser's hand (or body). We implemented a card-shaped passive CipherCard using a printed circuit board (PCB). Each side of the card contains an identical 3×4 grid layout of electrodes (Fig. 2a). For the sake of simplicity, this prototype does not employ utility electrodes for detecting the size and orientation of the card. Each electrode on the front side is uniquely connected to an electrode on the back side. Connections can be either randomized or pre-specified by the user (so they can use a particular u ser/system password mapping) at the time of manufacture. The electrodes (1×1cm) and connecting paths (0.025cm width) were printed using a thin layer of tin. To prevent attackers from deciphering the mapping by visual inspection, CipherCard must be constructed in a manner that hides the connecting paths, e.g. by a surface material or by using a multi-layer PCB design. In our prototype, the connecting paths were co vered by paper tape.

To connect the electrodes on both sides, we used tin -coated holes ("vias"). For each electrode on the bottom, we connected it to a via (diameter: 0.2cm and hole size: 0.071cm) placed 0.1 cm away from its edge (Fig. 2a). Connecting an electrode to a via from the top connects it to the corresponding electrode on the bottom. Finally, the connecting paths were covered by tape to shield the connection patt ern from outside the card. The finished prototype measures 8.6×5.4×0.15 cm (L×W×H), only slightly thicker than a standard credit card, and it can be easily carried in a wallet.

Wallet-based CipherCard

To demonstrate that CipherCard can be integrated into a daily personal belonging, we built a second passive prototype based on a conventional wallet (Fig. 2b) of size 10×8.2cm when folded. Similar to the card, each side of the wallet has a 3×4 grid of electrodes, where one side's electrodes are connected to the opposite side through copper wires. Our prototype uses two hard PCB, but we expect a deployable version to use flexible materials, for example, tin paths printed on PET film. What is important is that the deployable version preserves the appearance, feel and functionality of a wallet.

Smartphone-based CipherCard

We explored the feasibility of an active CipherCard by creating a smartphone prototype (Fig. 3). We used an HTC 8X Windows Phone as our platform. Input is handled by the phone's native touch input API, and passed via WiFi to a Spark Core develo pment board. The Spark Core drives a 3×4 grid of electrodes printed on a plastic boards. A touch is simulated by programmatically connecting one of the pins of the Spark Core to the ground (e.g. configuring the pin as output and set its voltage to 0V). We found that the ground of Spark Core could not reliably trigger a touch, and thus solved this by connecting the battery jack to the phone body: when the phone is held by user's hand, the Spark Core is grounded through the user's body, and generates simulated touch points reliably. While our prototype is unwieldy, we expect that the deployable version would integrate the logic into the phone hardware, and integrate the simulated touch circuitry into the phone's body.

To simplify our explorations, we constrained the output resolution of our Cipher-Card prototypes to a fixed PIN layout. However, further engineering efforts would allow resolution of the electrodes to be significantly increased (e.g. 20×20 2×3mm electrodes), thus taking advantage of the higher input resolution available from the smartphone.

Reconfigurable CipherCard Mappings

In this section, we present reconfigurable designs for both passive and active Cipher-Card.

Passive CipherCard reconfigurable design

Completely passive cards are cheap to produce. However, they must be replaced when a user needs a different pattern (e.g., to change the desired user or system pas sword). It would be more convenient to design CipherCard so they can be reconfigured on the fly. We designed (not implemented yet) one possibility, illustrated in Fig. 4, which allows a user to reconfigure the connection pattern by rearranging the positions of the electrodes on one side (here the front side). Using a 3×3 grid layout as an example, each electrode (numbered A-I in Fig 4) on the front side can be freely removed and re-plugged into any of the 9 sockets (numbered 1-9), and the permutation order they are plugged in intuitively defines how each socket location maps to one of 9 fixed-position electrodes on the back side (numbered a-i). To make this possible, we must provide a mechanism to ensure the same removable front -side electrode (e.g., A) always connects to the same back-side electrode with the matching letter (a), regardless of which socket it (A) is plugged into. This is enabled by having 9 small condu ctive pins (3×3) inside every socket. Each pin is hardwired to one of the back-side electrodes with the corresponding relative position (e.g., top-left for a). Each frontside electrode has only one pin on its bottom, the relative position of which corresponds to that of the back-side electrode with the matching letter (again top-left for a). Thus, whichever socket that electrode A is plugged into, its pin always contacts the socket pin that connects to electrode a, and so on. Therefore, changing the electrode for a certain socket position will change the position of its associated touch point seen by a touchscreen. With this simple design, a CipherCard pattern can be reconfigured as easily as switching positions of removable electrodes.

Mobile App for Reconfiguring Active CipherCard

We also implemented a Windows Phone app, which illustrates one interface for reconfiguring the previously described active CipherCard. By default, our app shows a 10 key PIN pad when it starts (Fig. 5a). The touch locations (e.g. electrodes) are shown to guide the reconfiguration of the key mappings. To change a key mapping, the user drags a number key to inside a desired touch location (Fig. 5b). This way, when the key is tapped, the corresponding touch location is triggered (Fig. 5c). Once the configuration is confirmed, the activated touch location is highlighted. When needed, the user can add or remove a number key. To configure a 1-to-m mapping, the user can duplicate a number key, and then drags each of the duplicated keys to a desired location (Fig. 6 right). Once done, tapping the number key triggers the associated locations in a sequence that the keys were created. Although not implemented in the hardware, our software also supports configurable key sizes and layouts. First, a variety of standard keyboard layouts can be selected, where each matches the keys and layout of a particu lar touch-screen security system. Second, layouts can be designed from scratch, although the interactions to do so are more complex. For example, the user can specify the dimensions of the key, and drag it to a desired location. The software also allows the user to scale key sizes using pinch gestures. Our software automatically identifies the candidate location(s) that need be triggered for simulating a touch at the position of the key. To do so, the user first specifies the resolution of the touch locations (or electrodes). The software then walks through the locations and associates one with the key, which has the largest overlap with that key (Fig. 6 left). Notice that most of the capacitive sensors ignore touches that are smaller than a threshold size (e.g. 3 mm for Microsoft Surface). To accommodate this, our algorithm triggers all the electrodes (if smaller than 2mm) that reside inside the key.

Authoring a New Card

At the current stage, passive CipherCards can be designed using popular circuit software (e.g. Altium), and built using a standard PCB. A much easier way is to print on paper using a home printer and conductive ink [START_REF] Kawahara | Instant inkjet circuits: lab-based inkjet printing to support rapid prototyping of UbiComp devices[END_REF]. This allows CipherCard to be widely adopted for home and office use.

Security Analysis

Our assumption of a threat model is based on real world threats, under which a shoulder-surfing attack may take place. We assume the user is in a public environment fully controlled by the attacker, who has hidden a number of high-resolution cameras in that environment. The cameras can record (from multiple angles) all the user's actions on a software PIN pad on a capacitive touch-sensing device. Multiple authentication sessions of the same user can be recorded, which can then be reviewed in order to extract the PIN. We also assume that the adversary has direct access to the authentication system but without the possession of CipherCard.

An attacker who has observed the user password is unable to pass authentication without possessing the user's CipherCard. Copying the card configuration is also difficult without physically possessing it. CipherCard can be deployed where the system password is not revealed to the user. This means the user would only know their user password, which in turn mandates CipherCard in user verification. This makes the user immune to the social engineering attacks [START_REF] Orgill | T he urgency for effective user privacyeducation to counter social engineering attacks on secure computer systems[END_REF], where the user may divulge the system password to attackers, who can then bypass the CipherCard to authenticate directly.

Losing both the user password and a CipherCard to an adversary will grant access to protected services or locations. Hacking into an active card, e.g. user's phone, or breaking into a computer which stores translation files may disclose a user's password mapping to an adversary. Individuals or organizations that design or have access to the design of the password mapping may also present risks to the security of Cipher-Card.

CipherCard does not prevent attacks directly on the authentication device. With the 1-to-1 translation of a password, CipherCard does not increase the overall entropy (i.e. the total number of possible authentication inputs seen by the system) [START_REF] Burr | Electronic Authentication Guideline[END_REF]. We therefore assume the original password mechanism on the device is sufficiently strong on its own (e.g., with an appropriate password length and a limited number of trials) against direct attacks, e.g. brute-force attacks (i.e. enumerating all possible pas swords) [START_REF] Kim | Fundamentals of Information Systems Security[END_REF]. CipherCard however protects against dictionary attacksa user may choose a common word as the user password, yet the translated system password is highly unlikely to be in the dictionary of guessed passwords. The entropy of the 1-to-1 mapping is equal to the total number of permutations of the n electrodes, i.e. n!. For example, a 3×3 grid layout offers 9! = 362880 unique CipherCard patterns. In contrast, a 1-to-m translation of a password increases the overall entropy by allowing a longer system password, thus providing a higher level of security . Note that m can vary for each character in the user password. Brute-force attacks can be extremely difficult if the length of the system password is unknown to the attacker, and can be thwarted simply by limiting the number of incorrect entries and/or by introducing time delays between attempts. Notice that if a chosen user password is too easy to guess, the level of security of CipherCard can be reduced. For example, in an extreme case of 1-to-m mapping, a user password can contain only one character, which serves as a shortcut to a longer system password. This way, the user password becomes extremely easy to obtain. Even so, the attacker would still need to somehow take possession of the CipherCard.

CipherCard Usage

CipherCard makes it possible for people to choose easy-to-remember PINs instead of using strong ones that are les s memorable [29], which often imposes security concerns [START_REF] Luca | Now you see me, now you don't: protecting smartphone authent ication from shoulder surfers[END_REF]31]. Furthermore, CipherCard makes it possible to have a single user pas sword associated with different system passwords , either through the use of multiple passive CipherCards set to that user password (but generating different system passwords), or a single active CipherCard (which would change the mapping based on the service). This allows the user to reuse passwords for multiple accounts without significantly impacting security [START_REF] Zezschwitz | Survival of the Shortest: A Retrospective Analysis of Influencing Factors on Password Composition[END_REF].

Changing system passwords. Renewal of passwords is commonly enforced by organizations to enhance security, but places undue burden on users to generate or remember new passwords. CipherCard allows for refreshed system passwords while allowing users to continue using their existing user pass words in two ways: they can use a new (passive) CipherCard, or the internal mapping in the CipherCard can be changed. Either way, user password now maps to a new system password without loss of security.

Changing a user password. Many systems allow the user to change their system password after they have correctly logged in. After selecting that option, a user can simply place the CipherCard on the authentication UI, and enter a new user password which, in turn, generates the new system password.

Setting a user password based on an existing system password. In many scenarios, a system password is shared by many people (e.g. door entry); in this case, it is desirable to keep the system password, but also allow for a mapping between this and a user-chosen password. Because different CipherCards can generate the same system password from different user passwords, this becomes easy to do with our reconfigurable designs. The actual mapping between the two can be done by any of the prev iously described methods.

Replacing a lost or damaged CipherCard. A new CipherCard can be authored and granted to the user if the original one is lost or damaged. The user can also make one at home (see 5.3). The design of the password mapping needs to be securely stored on a safe computer in order to preserve the security of CipherCard .

Feasibility Study

We conducted two studies to evaluate the concept of CipherCard, our designs, and identify potential usability issues. In our first study, we used heuristic evaluation to identify usability issues of the three prototypes. We were also interested in perceptions of the security of the scheme. We did not implement UI alignment for Cipher-Card. This allowed us to investigate the feasibility of actual deployment without modifying existing touchscreen devices. While we believe that CipherCard warrants a long-term field deployment study, in this early development stage, we deem this study a necessary step towards refining and improving the concept before they can be deployed and studied.

Participants

Our heuristic evaluation was conducted with usability experts. We recruited five professional usability engineers (25-40 years old) from industry. Two participants had one year of industry UX experience, one had >3 years, and two h ad >5 years of experience.

Apparatus and Procedure

At the beginning of the study, we showed the participants the three CipherCard variations, e.g. card-shaped, wallet-based, and phone-based CipherCard. We then walked them through three CipherCard usage scenarios: entering a PIN into 1) a touchscreen door lock, 2) a public kiosk, e.g. ATM and POS terminal, and 3) a personal mobile device (e.g. a tablet). To simulate the ATMs or door locks, we used Microsoft Surface tablets positioned in different ways. For example, to simulate a door lock, the tablet was hung on a vertical surface. To simulate a public kiosk, the tablet was tilted 35˚ on desk. To simulate a mobile scenario, the participant was asked to hold the tablet using their non-dominant hand and authenticate using CipherCard with the other hand. For each usage scenario, the participants were asked to enter a 4-digit PIN into a PIN pad application running on the tablet. After a PIN was entered, the application indicated whether the authentication succeeded or failed. In order to Participants were encouraged to put themselves in the mindset of someone using these systems in real-life usage situations, e.g. taking the card from their pocket b efore use. They were allowed to try and use the prototypes for as long as they wanted prior to completing a questionnaire (7-point Likert scale) and an interview, in which the participants were asked about their perceived security and portability of Cipher-Card as well as their mental demand, physical demand, effort, frustration, and concentration when using the prototypes.

Results

Overall, the participants welcomed CipherCard as a method to resist camera-based shoulder-surfing. Their feedback confirmed the merits of the prototypes, e.g. security and portability, but also identified issues that may cause cognitive overhead (Fig. 8. Left). The results reported below are using median.

Merits of CipherCard

Security. All of the participants perceived CipherCard as more secure against shoulder-surfing than current practices (6, 7 being the most secure; s.e. = 0.5), e.g. directly entering the PIN. For the participants, who had expressed interest of using Cipher-Card (e.g. P1&P5), they found it highly attractive to have an extra layer of security. Some of the positive comments included "I shield my PIN entry, it is my habit but I don't feel I have to (with CipherCard)" -P1 and "I see myself using CipherCard to unlock my door because now I have the security of a bankcard, if someone wants to break into my house, they need to get my card as well."-P5. Portability. All prototypes were rated highly portable, e.g. card: 7, wallet: 7; phone: 7, with 7 being strongly agree; all s.e. = 0) regarding the convenience in carrying them around. P1 commented that it would be convenient to carry the phone-based CipherCard because "it is something I carry around anyways." The wallet received similar comments, e.g. "I don't have to carry something else as I already carry one"-P5. While the card-shaped CipherCard is considered an extra burden (i.e. a new thing to carry), our participants found it easy to carry as well: "I have a lot of cards anyways, so I don't think if carrying a lot of them (cards) will be an issue " -P1, and "I will be ok to carry it around if the credit card company decides everybody needs to do"-P3.

Issues that cause cognitive overhead UI alignment. Prior to entering the PIN, CipherCard needs to be physically aligned with authentication UI, e.g. PIN pad. This was seen as an unwanted extra step. Among the three prototypes, the card-shaped design was the easiest to align, while the rest were initially challenging for the first time users. Misalignment resulted in touc hes being unregistered on the touchscreen, which had consequently caused frustration.

Slippery screens. Touchscreens are slippery. This had made alignment even more difficult. The participants had to spend extra effort when holding the prototypes stea dily, especially when the screen was tilted. The participants also worried about dro pping their phone on tilted screens.

Two-handed operation. Entering a PIN on the prototypes while making sure the device did not slide required using two hands. Two -handed operation introduced unnecessary effort for the participants to prepare for using the card. For example a p articipant commented that, by requiring two hands, "I will have to put my bag down and use both hands to operate"-P1. Additionally, the holding hand had sometimes o ccluded the number buttons that the participant wanted to tap.

Orientation. The translated output locations are dependent on the orientation of the card and the side that is used for input. The phone-and card-based prototypes have clear visual affordance, making it easier for the participants to identify the desired side and orientation to use. However, the wallet is symmetrical in its appearance, thus requiring extra effort from the participant to figure out the right direction .

Preparation effort. All of the aforementioned issues had introduced unnecessary preparation efforts from the users prior to entering the CipherCard's user password.

Overhead also includes the effort to take out the device from where it is carried. The card-shaped device is less convenient than the other two prototypes in the sense that the users will have to take out the wallet first (assuming the card is not worn as an id tag). With the phone, the participants even more overhead, where they had to first unlock the phone, open the app, and then search for the desired card mapping.

Improved Design

After carefully reviewing the results from the first study, we came up with a number of solutions to resolve some of the most outstanding issues.

To reduce the preparation time for phone-based CipherCard, we implemented a new function, which allows the phone to automatically load a desired mapping by tapping it on a Near Field Communication (NFC) tag. In circumstances that the size and layout of the capacitive PIN pad does not match the one on the phone, the software can automatically load a key pad configuration that matches its specification.

For issues regarding UI alignment, slippery screens, and two-handed operation, we designed a card-holder that can be attached on top of the capacitive PIN pad. This allows the user to snap CipherCard into the right position on the screen without aligning or holding by hand. The card-holder guides the position of CipherCard, holds it onto the screen, and aligns it properly. We implemented a prototype on-screen cardholder to demonstrate the idea (Fig. 7). To use it, the user simply slides the cardshaped prototype into the holder from the top and enters a PIN. This allows singlehanded operation without the need for user alignment. Alternatively, magnets can be attached to the card and screen to achieve the same goal, while preserving the flatn ess of the screen. This design is more suitable to phones and wallets as they do not have a uniform form factor. Thus, an on-screen holder may not work for them. The user can snap CipherCard onto the screen (e.g. using magnets) in an arbitrary orientation. The software PIN pad aligns with CipherCard automatically. It can even adjust its button size and layout to fit those of CipherCard (see details in Section 4). We can envision many different approaches for developing the snap-in mechanism, exploring which are outside the scope of this paper. We thus leave them for future work. Instead, we focused our investigation on the effectiveness of our improved designs. The goal of this study was to verify the concept of our improved design as well as the overall usability and security of CipherCard. To focus on the concept rather than the implementation, we mocked up the snap-in mechanism using the on-screen card holder shown in Fig. 7. For the wallet and phone, we used double-sided tape (on the back of different CipherCards) to simulate a magnetic snap-in effect.

Participants

Six participants (5 males and 1 female). All were adult office workers with prior experience using PIN pads and TFA.

Apparatus and Procedure

The procedure is similar to the feasibility study, except with the phone-based prototype, the participants were asked to tap the phone on a NFC tag to load the app before entering a PIN. Participants were trained on the use of the snap -in guide for the card prototype. For the wallet-and phone-based prototypes, we asked participants to snap them onto the software PIN pad and imagine that alignment would be automatically adjusted.

Results

Reduced cognitive overhead

Overall, the participants rated cognitive workload being very low (1.5, with 1 being extremely low; s.e. = 0.1). The snap-in solution led to low mental/physical demand, effort, frustration, and concentration (Fig. 8. Right). The result of this study indicated the importance of having the snap-in feature before CipherCard can be deployed.

Participants found the wallet and phone had higher level of frustration than the card due to their cost value and the potential danger of exposing them in the public. For example, "In places that is not safe, I don't want to pull out my wallet because muggings are really common, and there is way too much personal information in the wallet"-p7. Although, tapping a NFC tag still requires extra effort from the users, participants found it much easier to do than searching through an application list.

Results from Both Studies

Security. The results from both studies confirmed that CipherCard was perceived more secure against shoulder-surfing than conventional PIN entry. When asked if they felt comfortable not knowing their system password, a slight majority of partic ipants (6/11) said they preferred knowing it. Although all understood the security be nefit of not knowing the system password (e.g. enforce TFA or against social engineering attacks), more participants preferred to have a backup in case a CipherCard was lost, stolen or otherwise not available. Seven of the 11 participants expressed interest in using CipherCard in a public kiosk or door lock. A minority (4) expressed interest in using CipherCard on mobile devices for highly secured application, e.g. online banking. Others were less interested, feeling they had more control hiding their input on a mobile device. Maintaining multiple passwords. Overall, the participants saw the merits of using CipherCard to help release the workload of memorizing multiple strong passwords, e.g. 6 with 7 being strongly agree. When choosing between using one CipherCard with multiple user passwords and multiple CipherCards with a single user password, all participants leaned towards using one card. They explained it would be easier than carrying multiple cards. More participants (7) also leaned towards getting a new (pa ssive) card when renewing a system password, as they could benefit by keeping the current user password (assuming the card is associated with only one PIN).

Social pressure. Participants were asked to rate how much social pressure they may feel when using CipherCard in front of stranger, friend, and family, where the viewer may perceive it as an insult. They did not feel social pressure using Cipher-Card in front of strangers, friend, and family (all 7, with 7 being strongly disagree that they felt social pressure; s.e. = 0); They did not think they would feel uncomfortable if others (e.g. stranger, friend, or family) were to use CipherCard in front of them (1, with 7 being strongly mind; s.e. = 0).

Discussion and Limitations

In the section, we discuss the insights and limitations we discovered from our own experiences designing CipherCard.

Change of authentication behavior. While CipherCard does not change the way a user enters a PIN, it changes a user's authentication behavior, i.e., it requires the user to carry a card and put it on the touchscreen prior to entering a PIN. Users may be resistant to this extra work. Like any other security system, users are always the key to ensure the success of CipherCard. While people have been found to be the 'weakest link' in the computer system [START_REF] Orgill | T he urgency for effective user privacyeducation to counter social engineering attacks on secure computer systems[END_REF], their security behavior can be changed through education and proper design of security systems. We see that the features such as allowing easy-to-memorize user password, reuse of a user password for multiple authentication systems and for renewing a system password are handy trade-offs that may encourage users' authentication behavior by actively using CipherCard.

Convenience vs security. Our study showed that people do understand the importance of security. However, it is often the case that people sacrifice security for the sake of control or convenience [START_REF] Cranor | Security and Usability[END_REF]. CipherCard tries to motivate user's security behavior (e.g. using TFA) by providing a set of handy features. While welcomed by our participants, users need to be aware that some of the features may introduce potential security risks. For example, using a single user password for multiple accounts or updating CipherCards but never changing user password may reduce the security of CipherCard. In addition, if an adversary steals a wallet containing multiple Cipher-Cards, all with the same user password, he will be able to access all associated accounts if he knows that password, even though their system pass words may differ. Future work needs to focus on convenient techniques without impacting security.

Modification of the existing authentication device. The UI alignment technique needs to be developed before CipherCard can be deployed in the field. This, however, requires minor augmentation of the existing hardware and/or software, which would increase the cost of deployment.

Applications. We demonstrate CipherCard on capacitive touchscreen PIN pads but we envision the concept can be applied to popular gestural and QWERTY keyboard s.

Study. CipherCard warrants a long-term field study, which will help in understanding its practical usability in real-world use. The results from a field study might be more nuanced from the results from a laboratory environment due to artificial setups [START_REF] Luca | T owards understanding AT M security: a field study of real world AT M use[END_REF].

Prototypes. Our prototypes were designed as proof of concepts. Deployable sy stems will need more attention to how CipherCards appear, the cost of manufacture, and the reliability of the electronics.

Conclusion

In this paper, we introduced the concept of CipherCard to prevent PIN entry on capacitive touchscreens from camera-based shoulder-surfing attacks. CipherCard remaps a user's touch point to a different location on the touchscreen , thus translating the visible user password into a hidden system password received by the touchscreen. We explore the design space of CipherCard, and implemented three proof-of-concept prototypes. We evaluated the CipherCard concept with two user studies. The first study identified several usability issues, where we then proposed solutions that were the subject of the second study. User feedback from both studies confirmed the pro mise of CipherCard. Those studies (and our own experiences) also revealed various issues and tradeoffs that could affect its acceptance, its real-world use, and that should be considered in evolving designs. Of course, we are still in the early stages. Future work will evolve CipherCard's design, ideally resulting in a field deployment form which real-world usage data and its practicality can be better understood .

Fig. 1

 1 Fig. 1 CipherCard maps a touch into a different location.

Fig. 2 .

 2 Fig. 2. Left: Card-shaped CipherCard with a 3×4 electrode grid. Top callout shows the internal wiring and bottom callout shows the via and electrodes on the back. Right: Wallet -based CipherCard.

Fig 3 .

 3 Fig 3. Phone-based CipherCard.

Fig 4 .

 4 Fig 4. Design of a reconfigurable CipherCard.

Fig. 5 .

 5 Fig. 5. (a) grid shows the position of the electrodes; (b) dragging a number key to inside a desired electrode to change a key mapping;( c) finished configuration.

Fig. 6 .

 6 Fig. 6. Left: configuring a grid of 15 × 15 electrodes; Right: duplicating a number key to configure a 1-to-m mapping.

Fig. 7 .

 7 Fig. 7. Snap-in card holder allows one handed PIN entry .

Fig. 8 .

 8 Fig. 8. Average responses on several measures of cognitive overhead from both studies (Likert-scales: 1: very low, 7: very high) (Error bar shows standard error).