
Iulia Ion
ETH Zurich
|
Abstract
Writing secure programs is not just about producing a bug-free, technically secure implementation or using sound cryptographic algorithms. Developers might follow the OWASP specifications, conduct code reviews and penetration testing, and still discover that their system failed badly in the hands of end-users due to security breaches. As the guru in the field Bruce Schneier says: "Security is a chain; it's only as secure as the weakest link"; and the weakest link is the end user. Kevin Mitnick, the world’s most notorious hacker, like so many others, did a career by breaking systems through social engineering. The same Bruce Schneier bluntly puts it: “Amateurs hack systems, professionals hack people.”
In this talk, we present our real case experience in completing the process of providing security by accounting for the end user, in the context of the development of the Java-based toolkit for mobile device authentication, OpenUAT, the implementation of which we presented at Jazoon 2009. OpenUAT enables spontaneous Bluetooth communication between two devices, but offers usable and secure alternatives to the PIN-based Bluetooth secure wireless connection set-up, which has repeatedly (1) been broken. Alternative authentication methods supported by OpenUAT include taking a picture of a 2D barcode displayed by the partner device, (2) transmitting key material encoded in a short audio melody that is played by one device and recorded by the other, and (3) combinations of synchronized vibrations and button presses across the two devices. OpenUAT works on most JVMS, and consequently runs on a number of devices such as laptops, PDAs, and mobile phones.
To see how users perceive the usability and security of the different authentication methods, we set on to conduct a comparative usability study with 25 participants. We presented the different methods and asked users which ones they would prefer in a number of hypothetical real-world situations: (1) connecting the mobile phone to a wireless printer to print a financial report, (2) making a payment using the mobile phone in a duty-free shop, and (3) exchanging electronic business cards with a newly met CEO at a business event. Thanks to the extensive feedback received in this user study, we gathered understanding on the factors that make a certain mobile interaction seem secure and on the factors that determine users to adopt or avoid the presented methods. We noticed discrepancies between the actual security protection of a method and the users perception of security, which could have been exploited by malicious attackers. Users do worry about security, but not in terms of data encryption. Instead, a method is perceived to be secure if it reassures users through double confirmation and control that everything went as planned and they indeed connected to the intended device. Furthermore, social factors influence greatly method requirements. For example, when connecting to a friend's phone the method can be playful, but with a newly met person in a business environment professionalism is required. Similarly, in the office, at home, in a public place, or in a meeting, different methods and security levels are desired. Further factors that should be accounted for are the social conventions appropriate for the particular place and setting where the interaction is taking place and the time constraints on the user. Our results unveiled inadequate mental models of how systems work in the view of non-technical users, which are also relevant to other system designers in order to protect their applications from undesired security breaches. In this talk, we show the key findings in regard to properties of mobile applications and users’ security needs, as well as a set of guidelines for system designers emerging from our work.
As mobile devices and applications invade our everyday lives and increasingly meet non-technical users, it is critical that designers build usable systems that fit user’s needs and mental models, otherwise users will bypass the security mechanisms or stop using the applications all together.
|