Workshop on Human-Computer Interaction and Security Systems part of CHI2003, April 5-10, 2003, Fort Lauderdale, Florida

Important Dates:
Position Papers Due: January 17, 2003
Notification of Acceptance or Rejection: February 7, 2003
Workshop Date: April 6, 2003

The human factor is often described as the weakest part of a security system and users are often described as the weakest link in the security chain. This workshop will seek to understand the roles and demands placed on users of security systems, and explore design solutions that can assist in making security systems usable and effective. In addition to examining end-users, this workshop will also examine the issues faced by security system developers and operators. The primary motivation for the workshop is that previous research on HCI and Security (HCISEC) has been scattered in different conferences and journals, and information sharing has been difficult. The goal of the workshop is to build a network of interested people, share research activities and results, discuss high priority areas for research and development, and explore opportunities for collaboration.

Security is a large topic so there are many areas where HCI is important. Three obvious areas of interest are authentication (passwords, biometrics, etc.), security operations (intrusion detection, vigilance, policies and practices, etc.), and developing secure systems (developing for security, understanding users, installation and operation support, etc.). We are interested in receiving submissions on these topics, and suggestions of other possible topic areas are also welcome.

Contributions should be in the CHI 2003 Extended Abstracts style, 2 to 4 pages long. Participants will be selected based on the contribution to the goals of the workshop, the shared interests of the other participants, and likelihood to promote discussion and collaboration.

Please send inquiries and submissions to Andrew Patrick, Andrew.Patrick@nrc.gc.ca

FORMAT OF THE WORKSHOP (subject to change)

Participation Solicitation and Selection

Method of Interaction: 1 Day Workshop

Schedule for the Workshop

9.00-9.15	Introduction and context setting by organizers
9.15-10.15	Introductions, statements of interests, and presentations by attendees 
          	(time will be adjusted according to number of attendees)
10.15-10.30	Coffee Break
10.30-11.30	More presentations
11.30-12.30	Discussion of presentations, themes, shared interests
12.30-13.30	Lunch
13.30-13.45	Summarize morning discussions, organize breakout groups
13.45-15.00	Breakout group discussions (topics to be based on themes identified earlier)
15.00-15.45	Breakout group summaries
15.45-16.00	Coffee break
16.00-17.00	Summary, compose poster and report, decide on follow-up opportunities
17.00-17.30	Wrap up and leave.
18:30-22:00	Group dinner

THE TOPIC: HCI AND SECURITY SYSTEMS

Recent history in the USA and around the world has increased the apparent importance of security systems, both physical and electronic. A number of initiatives and responses have emerged ranging from new security systems and devices to large-scale national identification and security programs. Little attention has been paid, however, to the issue of whether such systems will be usable and effective. HCI researchers and practitioners have a lot to offer security system developers, purchasers, and users. This workshop will be an opportunity for these people to come together, share information, and develop relationships.

Scope of the Topic

Authentication

Probably because of the difficulty remembering, users also have a tendency to write their passwords down. In one study, 50 percent of the users surveyed admitted to writing down their passwords, and the other 50 percent did not answer the question [1]. Other notorious password behaviors are: (1) users share their passwords with their friends and colleagues, (2) users fail to change their passwords on a regular basis even when instructed to, (3) users may choose the same password (or closely related passwords) for multiple systems, and (4) users are often willing to tell their passwords to strangers who asked for them (asking was the most common technique use by Kevin Mitnick in his infamous security exploits [10]).

There are solutions to the security issues caused by the behavior of users, but they are not commonly used (see [1] for an excellent review). To alleviate the problem of a remembering multiple passwords, for example, organizations can support synchronized passwords across systems. A related solution is a single-sign-on system where users are authenticated once and then they are allowed to access multiple systems. Another technique is to reduce the memory load placed on users. It is well known that cued recall, where users are prompted for the information they must remember, is more accurate than free recall [4]. This can be used in security systems by requiring personal associates for passwords, such as "dear - god, "black - white", "spring - garden". Performance can also be improved by not asking users to recall at all, but rather to recognize certain material. Recognition is much easier and more accurate than recall [8]. There is some evidence, for example, that Passfaces are easier to remember than passwords, especially after long intervals with no use [3].

There has been much interest recently in using biometrics, such as fingerprints or voice patterns, for user identification [5] [9], but these systems can have their own problems. Biometrics can be hard to forge but easy to steal [11]. For example, fingerprints can be lifted from objects and used when the owner is not present. Also, the master file of biometric templates can be compromised so that an intruder could replace a legitimate thumbprint file with their own. If the integrity of a biometric has been compromised (e.g., a thumbprint file has been widely distributed) it makes the biometric system unusable forever. Also, a biometric security network can be compromised by packet sniffing and insertion, where an illegitimate biometrics file is inserted in place of a legitimate one that is being transmitted.

Biometrics systems can be based on physical characteristics, such as fingerprints, or behavioral characteristics, such as voice patterns [7] or typing styles [6]. The performance of behavioral biometrics (in terms of correction rejections and false acceptances) can be affected by circumstances such as health, stress, and other factors. Also, at least one behavioral biometric system, the one based on typing styles, appears to be less acceptable to users, who are afraid that their work performance may be monitored in some way [3].

Security Operations

System operators of large installations also face the problems encountered in other domains of monitoring and controlling large complex systems. Tools such as distributed firewalls promise to improve security, but configuring, monitoring, and controlling these systems is difficult. Operators would benefit from better interfaces for these systems.

Another problem seen with system operators is poor operating procedures. This includes not keeping the system up-to-date, not responding to security notices, badly managing their own passwords, cost-cutting, and simple laziness. An interesting research area might be an analysis of factors that contribute to inappropriate system operator behaviors. Finally, operator fraud can be a serious problem in situations where security compromises can lead to financial gain [2].

Developing Secure Systems

• Path of Least Resistance. To the greatest extent possible, the natural way to do any task should also be the secure way.
• Appropriate Boundaries. The interface should expose, and the system should enforce, distinctions between objects and between actions along boundaries that matter to the user.
• Explicit Authority. A user’s authorities must only be provided to other actors as a result of an explicit action that is understood by the user to imply granting.
• Visibility. The interface should allow the user to easily review any active authority relationships that would affect security-relevant decisions.
• Revocability. The interface should allow the user to easily revoke authorities that the user has granted wherever revocation is possible.
• Expected Ability. The interface must not generate the impression that it is possible to do something that cannot actually be done.
• Trusted Path. The interface must provide an unspoofable and faithful communication channel between the user and any entity trusted to manipulate authorities on the user’s behalf.
• Identifiability. The interface should enforce that distinct objects and distinct actions have unspoofably identifiable and distinguishable representations.
• Expressiveness. The interface should provide enough expressive power (a) to describe a safe security policy without undue difficulty; and (b) to allow users to express security policies in terms that fit their goals.
• Clarity. The effect of any security-relevant action must be clearly apparent to the user before the action is taken.

Another development issue is design philosophy. Especially in the realm of Web applications and services, design typically proceeds from the bottom up, driven by well established Web application design patterns and the constraints imposed by underlying technologies, such as public key cryptography. However, it is often difficult to retrofit these design patterns with acceptable security architectures. An alternative approach begins with a user-centered analysis of workflow and information flow (with emphasis on the boundaries), followed by a design approach that is driven from the top, taking care to use well established security models to enforce access control and data separation where appropriate.

REFERENCES