Identity Management: Strengthening One-Time Password Authentication through Usability ·...

213
Identity Management: Strengthening One-Time Password Authentication through Usability by Mohammed Alzomai Bachelor of Science (Computer Science), KSU, Saudi Arabia, 1992 Master of Science (Computer Science), FSU, USA, 1999 Thesis submitted in accordance with the regulations for the Degree of Doctor of Philosophy Information Security Institute Faculty of Science and Technology Queensland University of Technology May 2011

Transcript of Identity Management: Strengthening One-Time Password Authentication through Usability ·...

Page 1: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

Identity Management:Strengthening One-Time PasswordAuthentication through Usability

by

Mohammed Alzomai

Bachelor of Science (Computer Science), KSU, Saudi Arabia, 1992Master of Science (Computer Science), FSU, USA, 1999

Thesis submitted in accordance with the regulations for theDegree of Doctor of Philosophy

Information Security InstituteFaculty of Science and Technology

Queensland University of Technology

May 2011

Page 2: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through
Page 3: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

Keywords

Security, usability, identity management, authentication, authorization, scalability,online banking, password, one-time-password, hardware token, software token,trusted computing, display security, SMS, mobile phone, cellular network.

i

Page 4: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

ii

Page 5: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

Abstract

Usability in HCI (Human-Computer Interaction) is normally understood as thesimplicity and clarity with which the interaction with a computer program or aweb site is designed.

Identity management systems need to provide adequate usability and shouldhave a simple and intuitive interface. The system should not only be designedto satisfy service provider requirements but it has to consider user requirements,otherwise it will lead to inconvenience and poor usability for users when managingtheir identities. With poor usability and a poor user interface with regard tosecurity, it is highly likely that the system will have poor security.

The rapid growth in the number of online services leads to an increasing numberof different digital identities each user needs to manage. As a result, many peoplefeel overloaded with credentials, which in turn negatively impacts their ability tomanage them securely. Passwords are perhaps the most common type of creden-tial used today. To avoid the tedious task of remembering difficult passwords,users often behave less securely by using low entropy and weak passwords. Weakpasswords and bad password habits represent security threats to online services.

Some solutions have been developed to eliminate the need for users to createand manage passwords. A typical solution is based on generating one-time pass-words, i.e. passwords for single session or transaction usage. Unfortunately, mostof these solutions do not satisfy scalability and/or usability requirements, or theyare simply insecure.

In this thesis, the security and usability aspects of contemporary methods forauthentication based on one-time passwords (OTP) are examined and analyzed.In addition, more scalable solutions that provide a good user experience while atthe same time preserving strong security are proposed.

iii

Page 6: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

iv

Page 7: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

Contents

Keywords i

Abstract iii

Table of Contents v

List of Figures ix

List of Tables xi

Declaration xv

Previously Published Material xvii

Acknowledgments xix

1 Introduction 11.1 Introduction and overview . . . . . . . . . . . . . . . . . . . . . . . 11.2 Research Significance and Objectives . . . . . . . . . . . . . . . . . 41.3 Outline of the thesis . . . . . . . . . . . . . . . . . . . . . . . . . . 51.4 Contributions and achievements . . . . . . . . . . . . . . . . . . . . 7

2 Background 112.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4 Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.4.1 Principles of Security Usability . . . . . . . . . . . . . . . . 192.5 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.6 Identity Management Threats . . . . . . . . . . . . . . . . . . . . . 22

v

Page 8: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

2.6.1 Keyboard Logging Attack . . . . . . . . . . . . . . . . . . . 232.6.2 Spoofing Attack . . . . . . . . . . . . . . . . . . . . . . . . . 232.6.3 Man-In-The-Browser Attack . . . . . . . . . . . . . . . . . . 25

2.7 Current Identity Management Models . . . . . . . . . . . . . . . . . 262.7.1 The Silo Model . . . . . . . . . . . . . . . . . . . . . . . . . 272.7.2 The Common Identity Model . . . . . . . . . . . . . . . . . 282.7.3 The Centralized SSO Identity Model . . . . . . . . . . . . . 292.7.4 The Federated Identity Model . . . . . . . . . . . . . . . . . 30

2.8 User Centric Identity Management . . . . . . . . . . . . . . . . . . 322.8.1 Solutions Using Out-of-band Communication Channels . . . 362.8.2 Solutions with Separate Repositories . . . . . . . . . . . . . 37

2.9 Analysis of User Centricity in Existing Identity Management Solutions 382.10 Passwords Credentials . . . . . . . . . . . . . . . . . . . . . . . . . 392.11 Attacks on Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . 432.12 One-Time Password Solutions . . . . . . . . . . . . . . . . . . . . . 45

2.12.1 SMS-based Authentication . . . . . . . . . . . . . . . . . . . 462.12.2 One-Time Password Tokens . . . . . . . . . . . . . . . . . . 51

2.13 Trusted Computing (TC) . . . . . . . . . . . . . . . . . . . . . . . . 522.13.1 TPM Cryptographic Keys . . . . . . . . . . . . . . . . . . . 542.13.2 Key Certification . . . . . . . . . . . . . . . . . . . . . . . . 552.13.3 Mobile Trusted Module . . . . . . . . . . . . . . . . . . . . . 57

2.14 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3 Research Approach and Design 613.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613.2 Research Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 613.3 Research Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4 Investigating the Usability of SMS-based Authentication 694.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.2 Experiment Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

4.2.1 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704.2.2 Ethical Considerations . . . . . . . . . . . . . . . . . . . . . 714.2.3 Participant Recruitment . . . . . . . . . . . . . . . . . . . . 71

4.3 System Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

vi

Page 9: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

4.3.1 Server Front End . . . . . . . . . . . . . . . . . . . . . . . . 734.3.2 Server Back End . . . . . . . . . . . . . . . . . . . . . . . . 76

4.4 Participant Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774.5 Simulated Security Attacks . . . . . . . . . . . . . . . . . . . . . . . 78

4.5.1 Phase Shift of Attacks . . . . . . . . . . . . . . . . . . . . . 794.6 Participant Demographics . . . . . . . . . . . . . . . . . . . . . . . 804.7 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4.7.1 Observations of Obvious Attacks . . . . . . . . . . . . . . . 824.7.2 Observations of Stealthy Attacks . . . . . . . . . . . . . . . 834.7.3 Attack Phases and Attack Type . . . . . . . . . . . . . . . . 83

4.8 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844.8.1 Experimental Environment Considerations . . . . . . . . . . 86

4.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

5 Strengthening SMS-based Authentication through Usability 915.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915.2 Improved SMS-Based Authentication scheme . . . . . . . . . . . . . 935.3 Analysis of the New Scheme . . . . . . . . . . . . . . . . . . . . . . 955.4 Experiment Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

5.4.1 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015.4.2 Ethical Considerations . . . . . . . . . . . . . . . . . . . . . 1015.4.3 Participant Recruitment . . . . . . . . . . . . . . . . . . . . 101

5.5 System Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1035.5.1 Server Front End . . . . . . . . . . . . . . . . . . . . . . . . 1045.5.2 Server Back End . . . . . . . . . . . . . . . . . . . . . . . . 104

5.6 Participant Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1065.7 Simulated Security Attacks . . . . . . . . . . . . . . . . . . . . . . . 1065.8 Participant Demographics . . . . . . . . . . . . . . . . . . . . . . . 1075.9 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

5.9.1 Observations of Obvious Attacks . . . . . . . . . . . . . . . 1095.9.2 Observations of Stealthy Attacks . . . . . . . . . . . . . . . 1105.9.3 Attack Phases and Attack Type . . . . . . . . . . . . . . . . 110

5.10 Data Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1115.11 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

vii

Page 10: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

6 Display Security for Online Transactions 1156.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1156.2 The Cronto System . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

6.2.1 System Architecture . . . . . . . . . . . . . . . . . . . . . . 1176.3 The Display Security Architecture . . . . . . . . . . . . . . . . . . . 119

6.3.1 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1206.3.2 Practical Aspects . . . . . . . . . . . . . . . . . . . . . . . . 1216.3.3 Security Analysis . . . . . . . . . . . . . . . . . . . . . . . . 1256.3.4 Usability Analysis . . . . . . . . . . . . . . . . . . . . . . . . 127

6.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1296.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

7 A Robust Scalable Token-based Authentication Solution 1337.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1337.2 OTP Token Using Trusted Computing . . . . . . . . . . . . . . . . 135

7.2.1 Architecture Description . . . . . . . . . . . . . . . . . . . . 1387.2.1.1 OTP Token Configuration . . . . . . . . . . . . . . 1397.2.1.2 OTP Generation . . . . . . . . . . . . . . . . . . . 1437.2.1.3 Protecting OTP Generation . . . . . . . . . . . . . 144

7.2.2 Access to the Mobile Phone . . . . . . . . . . . . . . . . . . 1457.3 Security Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1467.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1497.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

8 Conclusion and Future Work 1538.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1538.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

A PHP Source Code of the Virtual Online Bank 159A.1 New Transaction Web Page (ch.4) . . . . . . . . . . . . . . . . . . . 159A.2 Confirmation Web Page (ch.4) . . . . . . . . . . . . . . . . . . . . . 163A.3 New Transaction Web Page (ch.5) . . . . . . . . . . . . . . . . . . . 165A.4 Confirmation Web Page (ch.5) . . . . . . . . . . . . . . . . . . . . . 170A.5 Database Administarion . . . . . . . . . . . . . . . . . . . . . . . . 172

Bibliography 175

viii

Page 11: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

List of Figures

1.1 Entities, digital identities and identifiers relation . . . . . . . . . . . 1

2.1 Typical phishing attack scenario . . . . . . . . . . . . . . . . . . . . 242.2 Silo user identity domains . . . . . . . . . . . . . . . . . . . . . . . 272.3 Common user identity domain . . . . . . . . . . . . . . . . . . . . . 282.4 Centralised user identity domain . . . . . . . . . . . . . . . . . . . . 292.5 Federated user identity domains . . . . . . . . . . . . . . . . . . . . 312.6 Seven segment display sample . . . . . . . . . . . . . . . . . . . . . 412.7 PassWindow card sample . . . . . . . . . . . . . . . . . . . . . . . . 422.8 Authorising bank transactions via SMS . . . . . . . . . . . . . . . . 472.9 Example SMS message with authorisation code . . . . . . . . . . . 482.10 A sample of an Infineon TPM chip . . . . . . . . . . . . . . . . . . 532.11 TPM’s Key Hierarchy Example . . . . . . . . . . . . . . . . . . . . 56

3.1 The Proposed Research Design [156] . . . . . . . . . . . . . . . . . 63

4.1 Simulated Online bank Model . . . . . . . . . . . . . . . . . . . . . 744.2 New Transaction Web Page . . . . . . . . . . . . . . . . . . . . . . 754.3 Confirmation Web Page . . . . . . . . . . . . . . . . . . . . . . . . 764.4 A sample of a confirmation email message . . . . . . . . . . . . . . 774.5 Authorising bank transactions via Email . . . . . . . . . . . . . . . 784.6 Participant Demographics . . . . . . . . . . . . . . . . . . . . . . . 814.7 Overall attack response . . . . . . . . . . . . . . . . . . . . . . . . . 834.8 Obvious attack first . . . . . . . . . . . . . . . . . . . . . . . . . . . 844.9 Stealthy attack first . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

5.1 Man-In-the-Middle Attack Scenario . . . . . . . . . . . . . . . . . . 935.2 Auto-validation of transaction details . . . . . . . . . . . . . . . . . 945.3 Simulated sample message . . . . . . . . . . . . . . . . . . . . . . . 97

ix

Page 12: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

5.4 Simulated sample message . . . . . . . . . . . . . . . . . . . . . . . 985.5 Simulated sample message . . . . . . . . . . . . . . . . . . . . . . . 995.6 Simulated sample message . . . . . . . . . . . . . . . . . . . . . . . 1005.7 Email message of a trusted account . . . . . . . . . . . . . . . . . . 1055.8 Email message of a malicious account . . . . . . . . . . . . . . . . . 1055.9 Participant Demographics . . . . . . . . . . . . . . . . . . . . . . . 1085.10 Overall attack response . . . . . . . . . . . . . . . . . . . . . . . . . 1095.11 Obvious attack first . . . . . . . . . . . . . . . . . . . . . . . . . . . 1105.12 Stealthy attack first . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

6.1 Cronto security system . . . . . . . . . . . . . . . . . . . . . . . . . 1186.2 Scenario for the Cronto security system . . . . . . . . . . . . . . . . 1186.3 Scenario for the display security architecture . . . . . . . . . . . . . 1206.4 A screen shot of a transaction data . . . . . . . . . . . . . . . . . . 1226.5 A photo of a transaction data . . . . . . . . . . . . . . . . . . . . . 1236.6 Text data resulting from converting a transaction image . . . . . . . 1236.7 Participants groups . . . . . . . . . . . . . . . . . . . . . . . . . . . 1246.8 Results using iPhone 3GS camera . . . . . . . . . . . . . . . . . . . 1256.9 Results using iPhone 4 camera . . . . . . . . . . . . . . . . . . . . . 126

7.1 Many tokens for a single user . . . . . . . . . . . . . . . . . . . . . 1357.2 One token for a single user . . . . . . . . . . . . . . . . . . . . . . . 1367.3 Token-based authentication scenario . . . . . . . . . . . . . . . . . . 1377.4 OTP Token Configuration . . . . . . . . . . . . . . . . . . . . . . . 1397.5 A sample of an XML file identifying the computer where the Infineon

TPM is installed . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1427.6 Input parameters to the OTP generation function . . . . . . . . . . 144

x

Page 13: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

List of Tables

2.1 Worldwide Economic Damage Estimates for All Forms of DigitalAttacks, 1996-2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2 Messages in the SMS-based authentication scenario . . . . . . . . . 47

4.1 Virtual online bank scenario . . . . . . . . . . . . . . . . . . . . . . 784.2 Phase shift of attacks . . . . . . . . . . . . . . . . . . . . . . . . . . 804.3 Overview of recorded transactions . . . . . . . . . . . . . . . . . . . 824.4 Overall attack response . . . . . . . . . . . . . . . . . . . . . . . . . 824.5 Obvious attack first . . . . . . . . . . . . . . . . . . . . . . . . . . . 834.6 Stealthy attack first . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

5.1 Overview of recorded transactions . . . . . . . . . . . . . . . . . . . 1095.2 Overall attack response . . . . . . . . . . . . . . . . . . . . . . . . . 1095.3 Obvious attack first . . . . . . . . . . . . . . . . . . . . . . . . . . . 1105.4 Stealthy attack first . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

6.1 Messages and actions in the display security architecture . . . . . . 1216.2 Participants groups . . . . . . . . . . . . . . . . . . . . . . . . . . . 1246.3 Results using iPhone 3GS camera . . . . . . . . . . . . . . . . . . . 1256.4 Results using iPhone 4 camera . . . . . . . . . . . . . . . . . . . . . 126

7.1 Messages in the token-based authentication scenario . . . . . . . . . 137

xi

Page 14: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

xii

Page 15: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

List of Abbreviations

AIK Attestation Identity KeyBAL Black Account ListCA Certification AuthorityCC Common CriteriaCoT Circle of TrustDLL Dynamically-Loaded LibrariesDNS Domain Name ServerDRM Digital Rights ManagementEK Endorsement KeyHCI Human-Computer InteractionHMAC Hashed Message Authentication CodeFIPS Federal Information Processing StandardIBAN International Account Bank NumberIMEI International Mobile Equipment IdentityKAL Known Account ListKDC Key Distribution CentreMITB Man-in-the-BrowserMLTM Mobile Local-Owner Trusted ModuleMRTM Mobile Remote-Owner Trusted ModuleMTM Mobile Trusted ModuleOCR Optical Character RecognitionOTP One-Time PasswordPC Personal ComputerPCR Platform Configuration RegisterPDA Personal Digital AssistantPIN Personal Identification NumberPKI Public Key Infrastructure

xiii

Page 16: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

RFID Radio Frequency IdentificationRSA Rivest Shamir AdelmanSHA Secure Hash AlgorithmSMS Short Message ServiceSRK Storage Root KeySSL Secure Socket LayerSSO Single-Sign-ONTAN Transaction Authentication NumberTC Trusted ComputingTCG Trusted Computing GroupTCP/IP Transmission Control Protocol/Internet ProtocolTCPA Trusted Computing Platform AllianceTLS Transport Layer SecurityTPM Trusted Platform ModuleURL Universal Resource LocaterVDU Visual Display UnitWAL White Account ListXML Extensible Mark-up Language

xiv

Page 17: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

Declaration

The work contained in this thesis has not been previously submitted to meetrequirements for an award at this or any other higher education institution. Tothe best of my knowledge and belief, the thesis contains no material previouslypublished or written by another person except where due reference is made.

Signed: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Date: . . . . . . . . . . . . . . . . . . . . .

xv

Page 18: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

xvi

Page 19: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

Previously Published Material

The following papers have been published and presented, and contain materialbased on the content of this thesis.

• M. Alzomai, A. Jøsang and B. Alfayyadh. Display Integrity Assurancefor SMS Transaction Authorisation. International Journal for Informa-tion Security Research (IJISR), Volume 1, Issue 2, ISSN: 2042-4639, 2011.http://www.infonomics-society.org/IJISR/

• M. Alzomai, B. Alfayyadh, A. Jøsang. Display Security for Online Trans-actions: SMS-Based Authentication Scheme. In The Proceedings of the 5th

International Conference for Internet Technology and Secured Transactions(ICITST-2010), London,UK, November, 2010. IEEE Computer Society.

• M. Alzomai, A. Jøsang. The Mobile Phone as a Multi OTP Device UsingTrusted Computing. In The Proceedings of the 4th International Conferenceon Network and System Security , pages 75-82, Melbourne, Australia, 2010.IEEE Computer Society.

• M. Alzomai, A. Jøsang, A. McCullagh, and E. Foo. Strengthening SMS-based authentication through usability. In ISPA ’08: Proceedings of the2008 IEEE International Symposium on Parallel and Distributed Processingwith Applications, pages 683-688, Sydney, Australia, 2008. IEEE ComputerSociety.

• M. Alzomai, B. Alfayyadh, A. Jøsang, and A. McCullagh. An experimen-tal investigation of the usability of transaction authorization in online banksecurity systems. In Ljiljana Brankovic and Mirka Miller, editors, 6th Aus-tralasian Information Security Conference (AISC 2008), volume 81 of CR-PIT, pages 65-73, Wollongong, Australia, 2008. ACS.

xvii

Page 20: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

• A. Jøsang, M. Alzomai, and S. Suriadi. Usability and Privacy in IdentityManagement Architectures. In The Proceedings of the Australasian Infor-mation Security Workshop (AISW), CRPIT Volume 68, Ballarat, Australia,January 2007.

• A. Jøsang, B. Alfayyadh, T. Grandison, M. Alzomai, and J. McNamara.Security Usability Principles for Vulnerability Analysis and Risk Assessment.In The Proceedings of the Annual Computer Security Applications Conference(ACSAC’07), Miami Beach, December 2007.

xviii

Page 21: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

Acknowledgments

I am heartily thankful to my supervisors, Professor Audun Jøsang and AdjunctProfessor Adrian McCullagh whose encouragement, supervision and support fromthe preliminary to the concluding level enabled me to develop an understandingof the subject.

I also wish to express my sincere gratitude to Dr Jason Reid for his guidanceand valuable comments throughout the thesis and for his feedback on the TrustedComputing Group work. I also sincerely thank Professor Chris Mitchell from RoyalHolloway, University of London for his comments in Trusted Computing.

I gratefully acknowledge the contribution and support of Matthew Bradfordwho helped me to develop the simulated online bank using the PHP programminglanguage.

I also offer my regards and blessings to all of those who supported me in anyrespect during the completion of the research project.

I am most appreciative to King Fahd Security College in Saudi Arabia forsponsoring my research and for supporting me and my family during the periodof conducting my research.

My parents and grandmother as well as my wife deserve special mention fortheir enduring support, prayers and persistent confidence in me.

xix

Page 22: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

xx

Page 23: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

Chapter 1

Introduction

1.1 Introduction and overview

An identity is “a representation of an entity in a specific domain and consists ofa set of characteristics and attributes, which are called identifiers when used foridentification purposes” [84]. Digital identities represent who we are when engagingin online activities and transactions. The relationship between entities, identitiesand identifiers is shown in Figure 1.1 below.

Figure 1.1: Entities, digital identities and identifiers relation

Managing identities in the digital world is called Identity Management. Iden-tity management can be defined as “The combination of technical systems, rules

1

Page 24: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

2 Chapter 1. Introduction

and procedures that define the ownership, utilization, and safeguard of personalidentity information. The primary goal of the Identity Management process is toassign attributes to a digital identity and to connect that identity to an individual”[142].

Identity management is normally interpreted as the management of users’ iden-tities and credentials for accessing resources. Identity management systems canthus be seen as consisting of multiple functions related to authentication and accesscontrol. For example, identities need to be registered and deregistered. Creden-tials need to be securely distributed to principals. Access authorizations need tobe defined and implemented on the system. During operation, principals needto be authenticated, and the access control function must grant or deny accessto applications and resources residing on a system or in a network, as a functionof the previously defined authorizations. The authentication and access controlcomponents are often tightly integrated.

Authentication is the process of establishing a level of confidence in the cor-rectness of a claim. More specifically, there are two main types of authentication:identity authentication and data origin authentication. Identity authentication isthe process of validating the claimed identity of an entity. Data origin authenti-cation provides assurance that the source of a message is as claimed.

In some online systems, data origin authentication is important. Althoughthe user has logged on from a specific client terminal and has been authenticatedat the start of a session, this in itself does not guarantee that every data packetoriginating from the client terminal is the intentional result of user actions. Forexample, a malware could initiate online bank transactions from the client ter-minal without the user’s consent or knowledge. The Clampi Trojan1 is one suchexample which enables attackers to remotely control victims’ computers to per-form financial transactions [40]. Zeus is another malware program that targetsonline banking and steals sensitive information. The malicious software installsitself on the targeted victim’s computer through for example phishing schemesand captures the victim’s account details to log into online banking accounts. Themalware is described in more detail in Section 2.6.2. Data origin authenticationcan theoretically eliminate this threat by authenticating the transaction requestitself.

The importance of identity management systems is increasing every day. Users1A Trojan is a malicious software application that is not controlled by the owner of the

computer.

Page 25: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

1.1. Introduction and overview 3

and organizations need a secure and convenient system capable of controlling digi-tal identities. This system should address all identity management related aspectssuch as authentication, access control and usability [42, 26].

The fast growth in the number of online services leads to an increasing numberof different digital identities that each user needs to manage, which may negativelyimpact the user’s ability to manage them securely. This situation can be describedby saying that users suffer from identity overload and password fatigue [87].

Passwords are perhaps the most common type of credential used today. Thetraditional requirements which dictate that passwords shall be difficult to guessand be different for different services put a considerable mental burden on users.Various studies [111] show that people use heuristic strategies to reduce the mentalload. Unfortunately, these strategies also make passwords vulnerable to attack.A typical strategy consists of reusing a small number of passwords for all theservices a user accesses. This means that the number of passwords is constantwhile the number of services increases. To protect the service with the highestrisk, users often reserve a single password for that service. Users tend to reuse thesame password, or variations of the same password for all low risk services. Thispractice reflects that users will disregard good security practices when faced withfrustrating tasks [13, 138, 4]. This represents a serious threat to the security ofuser authentication, making systems vulnerable to all variants of password crackingattacks and identity theft as well.

As a response to the importance of identity management and the growingthreats to online services security, new identity management systems includingspecial password management methods have been developed. In addition, thesemethods enhance data origin authentication by allowing the authentication processat single communication sessions or even at the transaction level. User authenti-cation alone is insufficient given the vulnerability of the standard client terminaland the relatively high risk of some online services such as bank transactions.

Typical methods for identity and transaction authentication involve using anOTP (One-Time Password). An OTP is 6 to 8 alphanumeric password that isused only once for user authentication or for the user to authorize a transaction.The two most common solutions used to implement this are:

• SMS-based authentication and

• token-based authentication.

Page 26: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

4 Chapter 1. Introduction

Both solutions can generate OTPs that can be used for user authentication aswell as data origin authentication. The SMS-based authentication is a scheme thatuses the mobile network as an out-of-band channel to verify the integrity of Webtransactions. It is typically used by online banks and is based on sending the detailsof bank transaction together with an authorization code in an SMS messages to thecustomer’s mobile phone. The customer is supposed to inspect the SMS messageand verify that the transaction details are correct, and to confirm and completethe transaction by returning the authorization code to the online bank throughthe Web interface. The token-based solution is based on giving a user a hardwaredevice or software that generates OTPs.

The SMS-based and token-based authentication schemes effectively improvethe process for users to create and manage passwords and consequently reducepassword cracking attacks. However, the usability aspect of the two schemes maygive rise to some questions. A problem with many identity management systemsis that they are designed to be cost effective and scalable from the perspective ofthe service provider, which sometimes creates poor usability from the consumers’perspective. With poor usability the user becomes the weakest link and the overallsolutions may result in poor security.

Therefore, there is a need to:

• investigate the usability aspect of the two authentication schemes, and

• redesign the two schemes to provide a good user experience while at the sametime preserving strong theoretic security.

The aim of the research project described in this thesis is to accomplish thesetwo main tasks.

1.2 Research Significance and Objectives

Many solutions have been developed to enhance the process of identity manage-ment. In identity management systems, usability is an important aspect [27].Unfortunately, most if not all current identity management solutions provide in-adequate usability [21].

Online markets and communities are important for the Australian economyand are necessary to stay competitive in a global context. The new Identity Man-agement approaches this research proposes will add to the efforts needed to secure

Page 27: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

1.3. Outline of the thesis 5

the online economy. This research studies and investigates the usability aspect ofidentity management and shows that some identity management solutions provideinadequate usability which can negatively influence overall security. The researchproposes new identity management approaches that will solve the scalability prob-lem from the user perspective and provide solutions with adequate usability whichcan provide stronger security than traditional solutions are able to provide.

1.3 Outline of the thesis

This thesis consists of eight chapters. The rest of the thesis is outlined as follows:

Chapter 2: Background

This chapter provides background on identity management and authenticationsystems. It categorizes the identity management models, introduces the identitymanagement objectives and presents common threats to identity management andauthentication systems. It also exemplifies the different types of password creden-tials currently in use and analyses the user behavior when creating and managingpasswords. The chapter also describes and analyses the two most commonly usedone-time password authentication solutions namely, the SMS-based authenticationand the token-based authentication. The concept of usability is illustrated in thischapter and a list of usability measures and principles is introduced. Finally, thechapter provides an overview of the trusted computing technology.

Chapter 3: Research Design

This chapter describes the methodology and research designed used in this re-search project. The research method suggested by Vaishnavi and Kuechler will beillustrated [156].

Chapter 4: Investigating the Usability of SMS-based Au-thentication

The chapter starts with a security analysis of a SMS-based authentication schemewhich is used by a number of banks in Australia followed by a usability analysis ac-cording to the usability measures and principles outlined in chapter 2. The chapter

Page 28: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

6 Chapter 1. Introduction

provides a detailed description of a practical experiment which simulated an on-line bank and examined participant’s behavior while using the simulated system.The experiment tested if the participants were able to correctly use the SMS au-thorization scheme for authorizing funds transfer transactions. Participants wereprovided with instructions to complete a number of bank transactions using asimulated online bank. Some of those transactions were attacked by altering thedetails of the destination account. It was observed that the participants behaviorwas not focused and a number of participants failed to notice the alterations tothe destination account number. The experiment result is presented at the end ofthis chapter with detailed analysis and discussion.

Chapter 5: Strengthening SMS-based Authentication throughUsability

The chapter begins with discussion of some features implemented by online banksto enhance the usability of the SMS-based authentication scheme and raises somesecurity considerations of these features. The chapter then describes a proposedenhanced solution to the typical SMS-based authentication scheme. The solu-tion aimed at improving the usability aspect of the scheme which thereby willstrengthen its security. The SMS-based authentication scheme relies on user aware-ness, and it is assumed that the correctness of the transaction details is verifiedby the user. The proposed solution aims to enhance the usability of the schemewithout compromising the strong authentication process of verifying every trans-action. This is implemented by automating the validation process and minimizingthe manual verification.

The chapter then provides an analysis to the security and usability of the newproposed scheme. The usability analysis is made according to the usability mea-sures and principles presented in chapter 2. The rest of the chapter describes arepetition experiment similar to the one described in chapter 4. The experimentaimed at examining the participant’s behavior when dealing with the new pro-posed SMS-based authentication scheme. The experiment tested whether the newenhanced usability affected the participant’s awareness of the scheme’s security.

Page 29: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

1.4. Contributions and achievements 7

Chapter 6: Display Security for Online Transactions

The proposed solution illustrated in the previous chapter aimed at enhancing theusability aspect of the SMS-based authentication scheme by automating the vali-dation process and minimizing the manual validation. This chapter describes anenhancement to the solution described in the previous chapter. The added solutionused the display security assurance concept to complete the automation processof all transaction validation. This is important because validating the transactiondetails for even a few transactions can be difficult especially with the trends touse the International Bank Account Number (IBAN) which can consist of up to30 digits.

The chapter describes the display security solution in detail as well as thepractical aspects of the solution. The chapter concludes with security and usabilityanalysis of the solution.

Chapter 7: A Robust Scalable Token-based AuthenticationSolution

A typical solution to eliminate the need for users to create and manage passwordsis based on giving the user a hardware token that generates One-Time Passwords(OTP). However, hardware tokens do not satisfy scalability and/or usability re-quirements. With an increasing number of hardware tokens needed by one userto authenticate to different online services, the more inconvenient it becomes tomanage all the different tokens. Software tokens can solve the scalability prob-lem but they are considered to have weaker security than hardware tokens. Thischapter discusses the usability and scalability issues of token-based authenticationsolutions and describes a new solution based on trusted computing technology thatuses mobile phones as OTP tokens. The solution combines the strong security ofhardware tokens with scalability and usability of software tokens. The chapterconcludes with a security and usability analysis of the proposed solution.

1.4 Contributions and achievements

The main contributions and achievements of the thesis include:

• Security for online banking has changed considerably during the relativelyshort period that online banking has been in use. In particular, authen-

Page 30: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

8 Chapter 1. Introduction

tication and identity management in the early implementations were, andsometimes still are, vulnerable to various attacks such as phishing. SMS-based authentication scheme include methods for re-authenticating users viaout-of-band channels for each transaction. We investigated the security ofthis type of solution. We described a practical experiment which simulatedan online bank and tested if participants in the experiment were able tocorrectly use the SMS authorization scheme for authorizing funds transfertransactions. The investigation concluded that it protects against certainattacks while still being vulnerable to other obvious attacks. In the nearfuture, it is expected that the remaining vulnerabilities will be exploitedas the attackers get more sophisticated. We also outlined possible ways ofprotecting against these future attacks. The research results were publishedin:

– M. Alzomai, B. Alfayyadh, A. Josang, and A. McCullagh. An exper-imental investigation of the usability of transaction authorization inonline bank security systems. In Ljiljana Brankovic and Mirka Miller,editors, 6th Australasian Information Security Conference (AISC 2008),volume 81 of CRPIT, pages 65-73, Wollongong, Australia, 2008. ACS.

• Current state-of-the art solutions for online banking authentication and iden-tity management include methods for re-authenticating users via out-of-bandchannels for each transaction. SMS-based schemes belong to this category,and can provide strong authentication to protect against security attacks.Poor usability of these schemes is still a problem, which makes them vul-nerable to other obvious attacks. We proposed a method for improving theusability of typical SMS-based authentication schemes which thereby willimprove their overall security. The research results were published in:

– M. Alzomai, A. Josang, A. McCullagh, and E. Foo. StrengtheningSMS-based authentication through usability. In ISPA ’08: Proceedingsof the 2008 IEEE International Symposium on Parallel and DistributedProcessing with Applications, pages 683-688, Washington, DC, USA,2008. IEEE Computer Society.

• We investigated the security of our proposed method which aimed at im-proving the SMS-based authentication scheme security through enhancing

Page 31: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

1.4. Contributions and achievements 9

the usability aspect of the scheme. We described a follow on the previouspractical experiment to re-examine the ability of the participants in the ex-periment to correctly use the SMS authentication scheme for authorizingfunds transfer transactions. The experiment tested wither the overall secu-rity of the scheme was improved using the proposed method.

• Secure online transactions with human users normally require visual displayfor verifying the correctness of central elements of the transaction before itis submitted. When commodity computer platforms get exposed to the In-ternet, even for a short period, there is a real and substantial risk that theybecome infected with malware that can modify anything on the computer,including what is displayed to the user and what is being sent over the Inter-net. This threat makes visual verification of transaction data unreliable andundermines other security mechanisms used to protect online transactions.We proposed and analysed a method for display security to make the verifica-tion of displayed data in the SMS-based authentication scheme more robustagainst the threat of compromised platforms. The method aimed at assuringthe correctness of displayed data in online transactions, i.e. to ensure thatwhat is displayed on the screen correspond to what is being transmitted toother parties in online transactions. The research results were published in:

– M. Alzomai, A. Jøsang and B. Alfayyadh. Display Integrity Assurancefor SMS Transaction Authorisation. International Journal for Infor-mation Security Research (IJISR), Volume 1, Issue 2, ISSN: 2042-4639,2011. http://www.infonomics-society.org/IJISR/

– Alzomai, B. Alfayyadh, A. Josang. Display Security for Online Transac-tions: SMS-Based Authentication Scheme. In The Proceedings of the 5th

International Conference for Internet Technology and Secured Transac-tions (ICITST-2010), London,UK, November, 2010. IEEE ComputerSociety.

• Passwords are perhaps the most common type of credential used today. Toavoid the tedious task of remembering difficult passwords, users often behaveless securely by using weak passwords. Weak passwords and bad passwordhabits represent security threats to online services. Some solutions have beendeveloped to enhance the process for users to create and manage passwords.

Page 32: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

10 Chapter 1. Introduction

A typical solution is based on giving the user a hardware token that generatesone-time passwords, i.e. passwords for single session or transaction usage.Unfortunately, most of these solutions do not satisfy scalability and/or us-ability requirements, or they are simply insecure. We proposed and analyseda scalable OTP solution using mobile phones and based on trusted comput-ing technology that combines enhanced usability with strong security. Theresearch results were published in:

– M. Alzomai, A. Josang. The Mobile Phone as a Multi OTP DeviceUsing Trusted Computing. In The Proceedings of the 4th InternationalConference on Network and System Security , pages 75-82, Melbourne,Australia, 2010. IEEE Computer Society.

Page 33: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

Chapter 2

Background

2.1 Introduction

Identity management is commonly described as the combination of technologies,policies and practices for representing and recognising entities as digital identities.The primary goal of the Identity Management process is to assign attributes to adigital identity and to connect that identity to an individual [142]. To preservethis identity management goal many solutions have been developed to control andfacilitate users’ access to systems. Unfortunately, most if not all of these solu-tions do not provide convenient ways of managing identities from the perspectiveof users themselves. Usability of security is an important factor that should beconsidered when designing identity management systems. If usability is not con-sidered when designing a new identity management system, the user may becomethe weakest link and the system security goal may not be met. Consequently,identity management systems will have inadequate level of security.

For any identity management system to be accepted by users, it should dealwith many identity related aspects. The system should consider the objectivesthat each identity management system needs and should be designed to deal withand avoid expected threats. In this literature review, the problem of identitymanagement as well as important concepts and features of identity managementwill be reviewed.

The rest of the chapter is organised as follows. Section 2.2 describes the authen-tication concept. In Sections 2.3, 2.4 and 2.5, the privacy, usability and scalability

11

Page 34: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

12 Chapter 2. Background

of security systems are discussed. Anticipated threats and attacks on identitymanagement systems are presented in Section 2.6. Sections 2.7 and 2.8 illustratecurrent identity management models in detail while Section 2.9 provides secu-rity and usability analysis of existing identity management models. Section 2.10,discusses password credentials and attacks on passwords are reviewed in Section2.11. Section 2.12 presents one-time password solutions and focuses on the twomost common solutions used in online authentication systems; the section alsoprovides security and usability analysis of the two systems.

Finally, in Section 2.13 the concept of trusted computing technology is ex-plained. Trusted computing is used as a basis to a proposed solution aimed atenhancing the usability of one of the one-time password solutions presented inSection 2.12, namely the token-based authentication.

2.2 Authentication

Authenticity of identities and profile data is an essential issue; in fact it is thebasis for any identity management system. An authentication system aims toverify the correctness of an entity’s claim to identity. There are four ways toestablish confidence in a user’s identity claim [142]. The system can verify:

• something an entity knows. This factor is characterized by secrecy (such aspasswords) or obscurity (such as dog’s name).

• something an entity is. In this factor the identity is distinguished by theuniqueness to one entity of a physical characteristic such as fingerprints orbehavioural trend such as gait.

• something an entity has. Authentication is done by confirming the physicalpossession of a token that characterizes identity in this factor. The tokenshould be unique and difficult to counterfeit or duplicate.

• the location of an entity at the time of authentication [103].

Multi-factor authentication is a technique that combines two or more authentica-tion factors in order to form a stronger authentication mechanism. For example acombination of knowledge-based such as a PIN number and token-based such as asmart card can be used to provide stronger authentication.

Page 35: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

2.3. Privacy 13

Authentication establishes a level of confidence in the correctness of a claim.In online services there are two main types of authentication: user authenticationand data origin authentication. User authentication (also known as identity au-thentication) associates an entity with a unique identifier (e.g. username) withina domain. It is the process of validating the claimed identity of an entity, e.g.when logging in and starting a new session. In other way, it is a way of ensur-ing that users are who they claim to be when they access systems. Data originauthentication provides assurance that the source of a message is as claimed. Itis the verification that the message has not been tampered with in transit (dataintegrity) and that it originated from the expected sender (authenticity).

An identity management system should have the capability of identifying ser-vice providers since it is often equally important for users to be able to authenticateservice providers, as it is for service providers to authenticate users.

2.3 Privacy

Privacy is a major concern in any personal identity management system. Usersshould have control over their identities and personal information, so they candecide who to communicate with and give their personal information. A generalprivacy principle is that personal information should be given minimum exposureand not be shared with parties that have no direct involvement in the interactionbetween users and service providers. In fact, privacy violation is considered to bea major threat to identity management systems.

As indicated by Holtzman [73], the concept of privacy involves many aspectsthat could represent a violation to user’s privacy. Some of those aspects includeusing user’s personal information for purposes other than those agreed, the corre-lation of user’s personal information that could allow revealing his or her identity,impersonating users for malicious purposes and revealing user’s personal informa-tion which the user would not be willing to disclose.

To ensure privacy compliance, all involved parties should follow a well definedsecurity policy. For example, G. Ahn and J. Lam [5] defined four principles offair information practices that service providers need to adhere to in order toensure privacy. These principles are notice, choice, access and security. The fourprinciples require that users are notified about their information practices andthat they can decide what information can be used and for which purposes. The

Page 36: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

14 Chapter 2. Background

principles also require that users can access and modify their personal informationand that they are securely protected by service providers.

Another example is the seven “Laws of Identity” [23] developed by Kim Cameronof Microsoft that are useful to maintain a reliable identity management system.Microsoft considers that the seven laws together are essential to preserve privacyand provide security. Four of these laws are related to the privacy principle:

• User control and consent: The user should have the ability to authenticatewho requests identity related claims and the reasons for requesting them.This is necessary to gain the user trust.

• Minimal disclosure for a constrained use: Identity management systemsshould disclose the minimum amount of personal information needed fora given situation.

• Justifiable parties: Personal information should be disclosed only to thosewho directly involved in the identity management process.

• Directed identity: The system must support both identifies for general in-teraction such as URLs and limited interaction (e. g. with a bank).

The privacy guidelines issued by the Organization for Economic Cooperationand Development (OECD) in 1980 [57] are important principles of privacy. Aus-tralia is one of the countries involved with OECD that work to coordinate policieswith the aim of adopting international trade. The Australian Information privacyPrinciples [119] and National Privacy Principles [120] are based on those OECDfair information practices.

The Guidelines consist of eight principles which apply to personal data.

1. Collection Limitation Principle: There should be limits to the collection ofpersonal data and any such data should be obtained by lawful and fair meansand, where appropriate, with the knowledge or consent of the data subject.

2. Data Quality Principle: Personal data should be relevant to the purposes forwhich they are to be used, and, to the extent necessary for those purposes,should be accurate, compete and kept up-to-date.

3. Purpose Specification Principle: The purposes for which personal data arecollected should be specified not later than at the time of collection and the

Page 37: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

2.3. Privacy 15

subsequent use limited to the fulfillment of those purposes or such othersas are not incompatible with those purposes and as are specified on eachoccasion of change of purpose.

4. Use Limitation Principle: Personal data should not be disclosed, made avail-able or otherwise used for purposes other than those specified in accordancewith Principle 3 except:

• with the consent of the data subject; or

• by the authority of law.

5. Security Safeguards Principle: Personal data should be protected by reason-able security safeguards against such risks as loss or unauthorised access,destruction, use, modification or disclosure of data.

6. Openness Principle: There should be a general policy of openness aboutdevelopments, practices and policies with respect to personal data. Meansshould be readily available of establishing the existence and nature of per-sonal data, and the main purposes of their use, as well as the identity andusual residence of the data controller.

7. Individual Participation Principle: An individual should have the right:

(a) to obtain from the data controller, or otherwise, confirmation of whetheror not the data controller has data relating to him;

(b) to have communicated to him, data relating to him

• within a reasonable time;

• at a charge, if any, that is not excessive;

• in a reasonable manner; and

• in a form that is readily intelligible to him;

(c) to be given reasons if a request made under sub-paragraphs (a) and (b)is denied, and to be able to challenge such denial; and

(d) to challenge data relating to him and, if the challenge is successful, tohave the data erased, rectified, completed or amended.

8. Accountability Principle: A data controller should be accountable for com-plying with measures which give effect to the principles stated above.

Page 38: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

16 Chapter 2. Background

2.4 Usability

Usability can be defined as “the extent to which a product can be used by specifiedusers to achieve specified goals with effectiveness, efficiency and satisfaction in aspecified context of use” [81]. Usability in Human-Computer Interaction (HCI) isnormally understood as the simplicity and clarity of interaction with a computerprogram or a web site.

Identity management systems need to provide adequate usability and shouldhave a simple and intuitive interface. The system should not only be designedto satisfy service provider requirements but it has to consider user requirements,otherwise it will lead to inconvenience for users when managing their identitiesand potential security violation.

In the National Strategy for Trusted Identities in Cyberspace report [117],usability was mentioned as one of the essential characteristics of solutions thatsupport trusted identities in cyberspace. The report indicated that the increas-ing complexity and risk of managing multiple digital identities and credentialsthreaten the convenience associated with online transactions and that any identitysystem must address this complexity as well as the underlying security vulnera-bilities created by it. The report pointed out that “identity solutions should besimple to understand, intuitive, easy to use, and enabled by technology that re-quires minimal user training. Service providers should perform usability studies toquantify ease-of-use. Many existing infrastructure components in use today (e.g.,cell phones, smart cards, personal computers) should be leveraged to facilitateease-of-use through their wide adoption, accessibility, and availability”.

The poor usability of security technology has been pointed out by several au-thors. Whitten and Tygar’s study [161, 162, 160] on the usability of PGP isconsidered as pioneering in this field. The importance of the usability aspect ofsecurity was discussed by earlier authors like Zurko and Simon [167], and evenmore than 100 years earlier by the Belgian cryptographer Auguste Kerckhoffs [93],who is most known for establishing the principle that security should not be basedon obscurity. In fact, this is only one of several security principles that Kerck-hoffs proposed, some of which relate specifically to usability. Below is the list ofKerckhoffs’ security principles, translated by Fabien Petitcolas [92].

1. The system must be substantially, if not mathematically, undecipherable;

2. The system must not require secrecy and can be stolen by the enemy without

Page 39: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

2.4. Usability 17

causing trouble;

3. It must be easy to communicate and remember the keys without requiringwritten notes, it must also be easy to change or modify the keys with differentparticipants;

4. The system ought to be compatible with telegraph communication;

5. The system must be portable, and its use must not require more than oneperson;

6. Finally, regarding the circumstances in which such a system is applied, itmust be easy to use and must neither require stress of mind nor the knowledgeof a long series of rules.

Principles 3 and 6 represent important usability principles that are particularlyrelevant today, but unfortunately have been mostly overlooked in the last 120 years[135].

The experience and skills gained in the contemporary discipline of HCI can nowbe applied to the domain of information security in order to better understand andimprove the usability of security. This has enabled a relatively good understandingof the role that usability plays in information security systems [137].

Generally, the strength of a security system is determined by the weakest linkin the system. In many cases it is the human operator who represents the weakestlink [141]. It is not unusual for service providers to attribute system securityfailure to human errors. Service providers generally blame users for violatingsecurity measures and for not correctly handling complex technical systems [70].According to the Computing Technology Industry Association [34], human error isthe main cause of security breaches and it accounted for 84% of security breachesin 900 surveyed American organizations. However, Norman argues that what isoften view as human error is in fact the result of design flaws that may be overcome[110].

Social engineering attacks precisely target the human link, and represent a veryeffective attack method. Reformed computer hacker Kevin Mitnick found that henever had to crack passwords by technical means, because he could always getthem from people [109].

Therefore, security systems must be viewed as socio-technical systems that de-pend on the social context in which they are embedded to function correctly [138].

Page 40: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

18 Chapter 2. Background

It is recognised that security systems will only be able to provide the intended pro-tection when people actually understand and are able to use them correctly. Thereis a very real difference between the degree by which systems can be considered the-oretically secure (assuming they are correctly operated) and operationally secure(acknowledging that they often will be operated incorrectly). In many cases, thereis a trade-off between usability and theoretical security. It can then be meaningfulto reduce the level of theoretical security to improve the overall level of actualsecurity. For example, the strongest passwords, from a theoretical perspective,are randomly generated. However, since it is difficult or sometimes impossible toremember such passwords, people will write them down, and thereby underminethe system’s security. Thus, it may be better to allow people to choose passwordsthat are easier to remember. Although this reduces the theoretical strength of thepasswords, it may increase the security of the system as a whole.

The mentioned trade-off between usability and theoretical security strengthis not generally accepted as a fundamental property of security system design.Some authors maintain that usability can be improved without compromising thetheoretical security by taking good usability practice into account from the startin the security system development life cycle. These authors describe specificapproaches and development processes, which when followed, can improve the endresult with regard to usability [137, 50].

However, even with the best development process it can be difficult to achievegood usability when the set of security primitives and mechanisms with whichto build the system is pre-defined. Some authors point out that some securityprimitives simply have limited potential for being implemented as user friendlywithout compromising the theoretical side of security, and that it can be necessaryto invent radically new security primitives in order to create security systems thatare user friendly [148].

This thesis examines a set of usability principles and compares them to theway actual security systems are implemented. In particular, the thesis appliesthese principles to analyze the usability aspect of the SMS-based and token-basedauthentication schemes. The principles are also used to evaluate the usability ofthe new proposed solutions aimed at strengthening the theoretical security of bothschemes by enhancing their usability.

Page 41: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

2.4. Usability 19

2.4.1 Principles of Security Usability

A set of general security usability principles was defined in [84, 83]. These princi-ples distinguish between two types of user involvement with security applications.

• A security action is when users are required to produce information andsecurity tokens, or to trigger some security relevant mechanism. For example,typing and submitting a password is a security action.

• A security conclusion is when users observe and assess some security rele-vant evidence in order to derive the security state of systems. For example,observing a closed padlock on a browser, and concluding that the communi-cation is protected by SSL is a security conclusion.

Usability principles related to security actions and security conclusions aredescribed below.

1. Security Action Usability Principles

(a) The user must understand which security actions are required of him.

(b) The user must have sufficient knowledge and the practical ability tomake the correct security action.

(c) The mental and physical load of a security action must be tolerable.

(d) The mental and physical load of making repeated security actions forany practical number of transactions must be tolerable.

2. Security Conclusion Usability Principles

(a) The user must understand the security conclusion that is required formaking an informed decision. This means that users must understandwhat is required of them to support a secure transaction.

(b) The system must provide the user with sufficient information for deriv-ing the security conclusion. This means that it must be logically possibleto derive the security conclusion from the information provided.

(c) The mental load of deriving the security conclusion must be tolerable.

(d) The mental load of deriving security conclusions for any practical num-ber of service access instances must be tolerable.

Page 42: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

20 Chapter 2. Background

By comparing the security solutions with the security usability principles de-scribed above, it can easily be seen why security often fails. As an example,although SSL uses strong cryptography, it is for example unable to protect againstphishing attacks. This fraudulent practice is perpetrated by attackers posing, forexample, as online banks and sending out spam email to people asking them to logon to false, but genuine looking Web sites, which allows the attackers to ’phish’identifiers and passwords from unsuspecting users. The problem is not due toweak authentication mechanisms, but is due to poor usability of the overall Websecurity solution, of which SSL is only a small part [106, 86].

The closed padlock does not for example give sufficient evidence to logically de-rive the security conclusion of knowing the identity of the service provider (breachof security usability principle 2b).

If the user chooses to view the server certificate, the mental load of analysingits content is intolerable (breach of security usability principle 2c).

Depending on the user, it is also doubtful whether many users actually un-derstand what security conclusion they are supposed to make (breach of securityusability principle 2a).

This example shows that improved usability, not strengthened cryptography,is needed in order to strengthen users’ ability to authenticate service providers inWeb interactions.

Some studies were conducted on the usability of security. One of the earliestinfluential security usability studies is Whitten and Tygar study on the usabilityof PGP [161, 162]. In this study participants were asked to use email encryptionsoftware and to assume the role of a political campaign coordinator who wastasked with sending sensitive email messages to other campaign volunteers. Thestudy concluded that a majority of participants were unable to successfully signand encrypt a message using PGP 5.0. The study also showed that the securityvulnerabilities were a direct result from usability problems.

A study [139] evaluated how effectively website authentication indicators pro-tect users from fraudulent sites and investigated whether participants behave dif-ferently in security usability studies than they would in real life.

The study concluded that more than 92% of participants using their own ac-count, and all other participants entered their passwords after altering authentica-tion indicators such as when HTTPS were removed or when the site-authenticationimage was replaced by an upgrade message. The study also concluded that partic-

Page 43: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

2.5. Scalability 21

ipants who played roles ignored more attack indications before withholding theirpasswords than participants whose own passwords were at risk.

Another study [165] conducted on usability to investigate how participants useanti-phishing tool bars to detect fake phishing websites. In this study, dummyaccounts were created in the name of "John Smith" at a number of e-commercewebsites. The participants were asked to play the role of John Smith’s personalassistant and process email messages on his behalf while protecting his passwords.The study concluded that participants were deceived 34% of the time regardlessof the fact that they were asked to focus on the toolbars.

Dhamija et al. conducted a usability study [48] in which participants wereasked to identify legitimate websites from spoofed phishing websites. In this study,participants were asked to assume the role of someone who had clicked on a linkin email and arrived at the website in question. Even with the heightened securityawareness, the study concluded that some phishing websites were able to deceivea large percentage of participants.

Hertzum et al. [72] analysed the usability of a Danish online banking securitysystem and evaluated the usability of the installation process of a special client-ende-banking software. The study concluded that most users are only able to com-plete installation of the e-banking systems by thoroughly following instructions,accepting defaults, and avoiding any real understanding of the involved securityissues. In addition, several usability weaknesses in the online money transfer wererevealed.

2.5 Scalability

Scalability is an important issue for any identity management system. The systemshould be flexible to deal with the fast growth in the number of online serviceswhich will lead to an increasing number of different digital identities for both usersand service providers. It needs to be able to trace any changes to the identitiesof the involved parties since experience shows that digital identities may changewith time. The system must be suitable for varied technologies used by differ-ent operators in different contexts and should interact with users in a consistentmanner.

Page 44: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

22 Chapter 2. Background

2.6 Identity Management Threats

Identity Management Systems are built to protect user’s personal informationagainst attacks. The typical scenario is that an attacker is trying to illegally getsome confidential information about a user.

As the number of online services increases, the amount of transmitted sensitivedata over the Internet increases and consequently the possibility of data loss,identity theft, fraud and privacy breaches increases as well. As an example, theUS 2009 Internet Crime Report [74] indicates, “ From January 1, 2009 throughDecember 31, 2009, the Internet Crime Complaint Center (IC3) Web site received336,655 complaint submissions. This was a 22.3% increase as compared to 2008.The total dollar loss from all referred cases was $559.7 million up from $264.6million in 2008.”

Mi2g1 publishes estimates on the incidence and costs of cyber-attack. Thenumber of such attacks reported has increased from almost zero in the 1995 (only4 attacks reported) to about 200,000 in 2003. Cost estimates for digital attacks,including hacking, malware, and spam are shown in Table 2.1 below. The es-timated costs include business interruption, denial of service, data theft, loss ofsensitive intelligence or intellectual property, loss of reputation, and share pricedeclines [144].

Year Cost ($ billions) Year Cost ($ billions)1996 0.8 - 1 2000 25 - 301997 1.7 - 2.9 2001 33 - 401998 3.8 - 4.7 2002 110 - 1301999 19 - 23 2003 185 - 226

Table 2.1: Worldwide Economic Damage Estimates for All Forms of Digital At-tacks, 1996-2003

According to the US Department of Justice, more than 10 million Americansare victims of identity theft each year [44]. Beyond the financial loss, the cost ofidentity theft crimes could include the cost of restoring an identity. A survey bythe Federal Trade Commission indicates that victims of identity theft may spendmore than 100 hours rebuilding their identities after an identity theft [33].

The two main and popular identity theft attacks that identity managementsystems are trying to be protected from are keyboard logging and spoofing attacks

1A British firm, see: http://www.mi2g.com

Page 45: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

2.6. Identity Management Threats 23

in addition to the social engineering. The two attacks aim to collect personalinformation about the victim such as credentials so the attacker can use thosecredentials to authenticate himself to the service provider as the legitimate userand perform illegal operations.

Below, more details about the two attacks are presented and in Section 2.11,more attacks related to password credentials are given.

2.6.1 Keyboard Logging Attack

One of the main attacks against identity authentication is keyboard logging [166].The keyboard logger is a malicious program that runs on the victim’s infectedpersonal computer and it aims to collect personal user information by recordingkeystrokes inputted by the user without his/her knowledge. The collected informa-tion is then sent to the attacker and with analysis of such information the attackerwill often be able to gain access to the credential necessary to access online services.

2.6.2 Spoofing Attack

Spoofing attack [154] is a situation in which the attacker successfully masqueradesas another to illegally gain an advantage. Whereas keyboard logging requires infec-tion of victim’s machines with a malicious program (keyboard logger), a spoofingattack can work without this requirement. Phishing and pharming are examplesof spoofing attacks.

Phishing attack

In a phishing attack [47] an attacker sends a spam email containing an URL link tothe attacker server (the fake) as if it is the legitimate URL of the service providerto fraudulently acquire sensitive information (like passwords) about the victim.

Phishing attacks are a combination of social engineering and man-in-the-middleattacks aimed at obtaining sensitive information like login identities and passwordsfrom unsuspecting users. A phishing attack normally starts by sending email ask-ing people to log on to a fake Web site masquerading as a genuine Web site thatrequires login and authentication. There are always people who will fall victimto such emails, and they typically fail to notice the fake Web site despite usingTLS. Technically speaking, the fake Web site has been correctly authenticated.Semantically speaking, this is a case of false positive, i.e. the client has incorrectly

Page 46: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

24 Chapter 2. Background

Figure 2.1: Typical phishing attack scenario

authenticated the server. The problem is not due to weak cryptographic authen-tication mechanisms, but to poor usability of the overall authentication solution,of which TLS is only a small part [106]. This type of attack, described in [86] isillustrated in Figure 2.1, where the numbered circles indicate the sequential orderof the actions.

A relatively recent malware known as “Zeus” is used by hackers to infect com-puters around the world. Zeus targets online banking and steals sensitive informa-tion. The Trojan spreads mainly through phishing schemes where it is generallycarried in emails. The malicious software installs itself on the targeted victim’scomputer and captures the victim’s passwords, account numbers, and other cre-dentials to log into online banking accounts. The Trojan was first identified in July2007 when it was used to collect information from the United States Departmentof Transportation [131]. In June 2009, security company “Prevx” discovered thatZeus had attacked more than 74,000 “FTP” accounts on websites of major com-panies as the Bank of America, NASA, ABC, Oracle, Cisco, and Amazon [69]. OnOctober 2010, FBI announced the discovery of a major international cyber crimenetwork which had used Zeus to hack into US computers and steal around $70m[55].

Pharming attack

Pharming attacks [15, 104] trick users into logging into the attacker’s website bypoisoning the DNS2 cache on the client platform or local broadband router, so that

2Domain Name Server

Page 47: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

2.6. Identity Management Threats 25

the domain name of the genuine Web site corresponds to the IP address of theattacker’s server in the poisoned DNS cache. With a poisoned DNS, the browserwill connect to the attacker’s server even though the customer manually typesthe correct domain name. DNS poisoning can easily be executed by luring thecustomer to access a malicious website loaded with JavaScript and JavaApplet[150, 155].

2.6.3 Man-In-The-Browser Attack

The Man-in-the-Browser (MITB) [151] is a type of Internet attack which has asimilar approach to the Man-in-the-Middle threat except it exploits security vul-nerability in host platforms. MITB attacks use malware that targets web browsersand interjects itself between the user and the web browser. The MITB is capableof modifying data between the user and the browser’s security mechanism. Themost common objective of MITB is to modify or create financial transactions ofonline banking systems by manipulating transactions in a completely covert fash-ion invisible to both the user and service provider. In other words, the attackwill wait until an authenticated session with the online bank is established andthen modify or create transactions as they are formed on the browser, but stilldisplaying back the user’s intended transaction.

The attack will be successful even if SSL is used, because all security controlsand mechanisms are displayed and work as expected. As a result, it is extremelydifficult for a user to detect the attack while it is taking place. The attack canbypass authentication, modify web sessions and initiate fake transactions.

As an example, when a user initiates a funds transfer in an online bankingtransaction, he will always see, via confirmation screens, the exact transactiondetails as keyed into the browser. The online bank, however, will receive a re-quest for an altered transaction, e.g. a different destination account number. Theonline bank receives the modified transfer values as a normal request and cannotdifferentiate between the original values and the modified values, or detect thechanges. The online bank executes the transaction and generates a receipt. Theweb browser at the user side will receive the receipt for the modified transactionwhere the MITB Trojan replaces the modified data in the receipt with the originaldata. The browser displays the modified receipt with the original details. Theuser believes that the original transaction was received by the online bank andauthorized correctly.

Page 48: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

26 Chapter 2. Background

Philipp Gühring specified in his white paper [59] five weaknesses where theMITB attack can be launched. These five points of attack are:

• Browser Helper Objects - the Dynamically-Loaded Libraries (DLLs) loadedby Internet Explorer upon start-up and have full access to it.

• Extensions - have similar functionality as Browser Helper Objects but forother Browsers such as Firefox.

• UserScripts - these are the scripts that are running in the browser.

• API-Hooking - this is an attack technique between the browser and boththe browser specific DLLs such as extensions and Operating System DLLs.As an example, if the SSL engine of the browser is a separate DLL, thenAPI-Hooking can be used to modify all communication between the browserand the SSL engine.

• Virtualisation - running the entire operating system in a virtual environmentto easily avoid all security mechanisms.

The effective way to protect against MITB attack is executing the authenti-cation at the transaction level by utilising the transaction verification. This isusually implemented through an out of band transaction verification process suchas the SMS-based authentication. See [98] for more discussion of MITB attacksand solutions.

2.7 Current Identity Management Models

In the next sections, a brief description of existing identity models for managinguser identities is given. Each model will be illustrated from the perspective ofusability and scalability. This is done by showing how a user can request servicesfrom different service providers in each model. The diagrams and explanationsrepresent a very high level of abstraction, meaning that many details of each com-munication protocol and message are omitted. The diagrams are still sufficientlydetailed to show the important aspects of each model from the user perspective.

The diagrams focus in the issuance and management of identifiers and au-thentication tokens, and explicitly indicate who the identity providers (IdP) andthe authentication token providers are. The diagram also shows where the actualauthentication takes place.

Page 49: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

2.7. Current Identity Management Models 27

2.7.1 The Silo Model

In the silo model3, the service provider manages the identifiers and credentials forall its users, and therefore fills the role of identity provider. The service provideralso authenticates users based on their identifier-credential pairs. Users can beallowed to define their own identifiers and credentials such as setting passwords.This model is illustrated in Figure 2.2.

The symbol explanations provided by the legend in Figure 2.2 also apply tosubsequent figures whenever relevant.

Figure 2.2: Silo user identity domains

The advantage of this model is that it is simple to deploy for the serviceproviders, and that it exposes personal information only to the service provider.On the other hand, this model provides inadequate usability since it causes iden-tity overload and password fatigue for users when they access services from manydifferent service providers. Users routinely forget passwords to infrequently used

3Called the “isolated user identity model” in [87]

Page 50: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

28 Chapter 2. Background

service providers. Forgotten passwords or fear of forgetting them create a signif-icant barrier to usage, resulting in the services not reaching their full potential.For important sensitive services, where password recovery must be highly secure,forgotten passwords can also significantly increase the cost of service provision.

2.7.2 The Common Identity Model

In this model, a central authority acts as an identity provider and manages commonunique identifiers and credentials, but the identity provider does not authenticateusers during service access. This is illustrated in Figure 2.3.

Figure 2.3: Common user identity domain

The advantage of this model is that it is simple to manage from both theservice provider and the user perspective. The user only needs to manage a singleidentifier-credential pair. The disadvantage is that it is impossible to define andmanage a stable unique name space for all users worldwide. Email addressesrepresent an example of a unique global name space of identifiers but they arenot stable since many people may have several email addresses. Social securitynumbers or national identity numbers are also unsuitable for privacy reasons. Alsothis model violates privacy because the common unique identifier would allowdifferent service providers to match personal information about the same userwhich may reveal their identity.

Page 51: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

2.7. Current Identity Management Models 29

2.7.3 The Centralized SSO Identity Model

The centralized identity model is used for SSO (Single-Sign-On). In this modela single authority manages the name space, issues credentials, and authenticatesusers during service access. This central authority then sends a security assertionto the service provider, either directly as illustrated in Figure 2.4, or indirectly viathe client machine.

Figure 2.4: Centralised user identity domain

The advantage of this model is that it provides good usability through SSO. Itis well suited for closed networks where multiple service providers are managed bythe same organization, such as in universities, governments and large companies.In closed networks the identity provider and the service providers are assumed tobe governed by the same authority under a single policy.

The disadvantage is that it is not suitable for implementation in open en-vironments where service providers are not governed by a common policy andauthority. In fact, it is very unlikely that service providers will accept a singleidentity provider to manage identities and do user authentication on their behalf.It would violate user privacy by exposure of personal information.

Intended for use on the Internet, Microsoft introduced the Passport authen-tication service in 1999 [1], where the idea was that users would get a single,convenient method for identifying themselves across different Web sites, encourag-ing convenient e-commerce transactions. Using the Passport system, users wouldentrust Microsoft to centrally hold their personal information - such as credit card

Page 52: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

30 Chapter 2. Background

numbers - and make it available to e-commerce websites whenever needed.Kerberos [96] is another example of centralized identity management model. It

is an authentication protocol published by Massachusetts Institute of Technology(MIT), which allows users to communicate over an insecure network and authen-ticate one another by proving their identities in a secure manner. Kerberos is amutual authentication protocol where both the user and the server verify eachother’s identity. The system allows for a single sign on. The Kerberos protocolis implemented on symmetric key cryptography and some versions of Kerberosuse public key infrastructure during some authentication phases. Kerberos uses atrusted party, named a Key Distribution Center (KDC), which maintains a reposi-tory of secret keys. Each entity on the system shares a secret key with KDC whichis used to prove entity’s identity. The KDC generates a session key the entities canuse to authenticate each other and interact securely. Kerberos has its limitation[12, 134]. Kerberos authentication protocol will fail if the clocks of the interactingservers are not synchronized. Also, the KDC represents a single point of failure.When the KDC is down the whole system will stop functioning.

From a privacy perspective, the centralized model gives the identity providersignificant power to abuse the personal information it collects [85]. A general pri-vacy principle is that personal information should not be shared with parties thathave no direct involvement in the interaction between users and service providers.The centralized user identity management model is clearly unacceptable from aprivacy perspective.

2.7.4 The Federated Identity Model

Federated identity models [32, 104] are based on groups of service providers thatenter into a mutual security and authentication agreement in order to allow userSSO to their services. In the terminology of the Liberty Alliance [105], these groupsare called circles of trust (CoT) [100].

Identity federation can thus be defined as a set of agreements, standards andtechnologies that enable service providers to recognize user identities and entitle-ments from other service providers.

As in the silo identity model, each service provider manages the name space ofall its users. Various silo identity domains are then linked together to form a feder-ated domain, as illustrated in Figure 2.5. In practice, the different domain specificidentifiers of each user are mapped. This makes it possible for different service

Page 53: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

2.7. Current Identity Management Models 31

providers to refer to the same user with different identifiers. For authenticationpurposes, a service provider will accept a security assertion [115] from anotherservice provider claiming that a given user has already been authenticated.

Figure 2.5: Federated user identity domains

The Liberty Alliance is an example of the federated identity managementmodel. It was formed in 2001 to provide solutions for federated identity manage-ment. In 2002 the Liberty Alliance released the Liberty Federation which allowsusers to be authenticated using single sign-on. Liberty Alliance developed a moreadvanced identity framework named Liberty ID-FF [8, 9, 10, 158] which adds morefunctionality to previous releases such as single logout and federation termination.In 2003 the Liberty Alliance released Liberty Web Services for managing a varietyof digital identities.

Many other federated identity management systems have been developed toprovide single sign-on. The list includes WS-Federation [102], SAML 1.0, SAML1.1 [112], SAML 2.0 [113, 114, 116] and Shibboleth [54].

The main advantage of the federated identity model is that it provides SSO inopen environments. The federated model is compatible with the traditional silomodel. Service providers can thus keep existing name spaces and authenticationsystems.

The main disadvantage is that it creates legal and technical complexity. For ex-ample, service providers are technically speaking not able to distinguish between asecurity assertion that reflects a genuine user service request, or one that represents

Page 54: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

32 Chapter 2. Background

a service provider masquerading as a user. Service providers must therefore trustsecurity assertions from each other. In addition, the mapping between identifierswill technically speaking allow service providers to correlate information about thesame user, which could represent a privacy threat [85, 122]. Users must thereforetrust service providers to protect their privacy in this respect [5].

From a privacy perspective, a federated model can be both an advantage anda disadvantage. Different service providers within the same federation domain aretechnically able to match personal information of the same user because of themapping between identifiers. The privacy protection thus depends on the privacypolicy and the adherence to the policy, which can pose a threat. On the other hand,a user’s identity within a specific service provider’s silo domain can be anonymous,and only the “home” service provider needs to know the real world identity of theuser. This can provide additional privacy protection.

Federated identity domains can not solve the scalability problem for the users.By assuming that multiple federated identity domains will exist, a user will mostlikely access service providers from different domains, and will therefore have toauthenticate with the respective identity providers from each domain. The problemof password fatigue will thus remain.

2.8 User Centric Identity Management

The problem with previous identity management systems is that they are designedto be cost effective and scalable from the perspective of the service provider, whichsometimes creates inconvenience and poor usability from the consumer’s perspec-tive. Those solutions can be categorized as service provider centric. It has beenargued that such solutions will provide inadequate usability from user perspectiveand could violate user privacy [8].

User Centric Identity Management Model [90] aims to solve the privacy issuesby giving control of personal information back to the user. It is based on theassumption that the user should control the disclosure of his or her personal infor-mation. In addition to protecting user privacy, user centric solutions are designedto enhance usability of identity management.

In response to the failed attempt to get the Passport service accepted by theInternet community, Microsoft has introduced a software and network architecturecalled The Identity Metasystem [39], where multiple independent identity providers

Page 55: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

2.8. User Centric Identity Management 33

can provide authentication services for e-commerce, and where Windows Live IDsimply will be one of multiple such identity providers. The architecture is basedon a software module called CardSpace which is integrated with Internet Explorer7.

CardSpace [39, 29, 36, 37] provides a storage repository for different identitiescalled InfoCards, that a user might want to use in different situations. For example,a user might want to use different identities when contributing to online blogs,and when purchasing air tickets online. The InfoCards stored in CardSpace on thecomputer will not contain sensitive information, such as login passwords or creditcard information. Each InfoCard points to a centralized identity provider wherethe sensitive information is stored. The identity provider will be directly involvedin the communication each time a user accesses an online service that requiresidentity. For example, in the case of accessing an online blog, the identity providercan provide a security assertion containing an anonymous login identifier and apassword, and in case of purchasing air tickets, the identity provider can provide asecurity assertion containing real name and credit card information. The securityassertions are first sent from the identity provider to the CardSpace module, andthen forwarded to the service providers. There is thus no direct communicationbetween identity provider and service provider.

The advantage is that it can be simpler for users to access service providers thatrequire identity. By supporting multiple identity providers and multiple centralizeddomains, the problem of having a single monopoly identity provider is diminished.

The main disadvantage is that it is still a centralized model, and that it isunlikely that the market will accept this model any more than they accepted thePassport model. The only difference is that there are multiple identity providersinstead of a single identity provider. Online service providers will resist an architec-ture that lets a third party identity provider authenticate their users and managethe users’ identities unless there is a very close relationship between the serviceproviders and the identity provider. From a privacy perspective, it is unacceptableto entrust third parties with personal information when they have no direct in-volvement in the relationship between the user and the service provider. The onlyrealistic usage of this model is to allow closely related service providers, such aswhen belonging to the same organization, to outsource the identity managementto a common identity provider.

A fundamental problem with introducing software modules for identity man-

Page 56: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

34 Chapter 2. Background

agement such as CardSpace on the client platform is that its security relies onthe inherent security of the platform. By storing InfoCards with pointers to iden-tity providers on the platform, the potential damage caused by a compromisedplatform is amplified dramatically. Storing the sensitive parts of InfoCards at theidentity providers does not necessarily provide strong protection, all the sensitiveinformation can be accessed by anybody who controls the platform.

Higgins [52, 53, 136] is a framework that allows users to combine identity andpersonal information across multiple systems. The framework gives people theability to store their digital identities and personal information in places of theirchoice and to share them with service providers under their control. The 1.0release of Higgins project was completed in 2008. Higgins aims to provide userswith more control over their personal information by providing a single point ofcontrol over multiple identities and profiles. The project will enhance usability byproviding a way for users to manage their identities based on card icons. Thisnew implementation is important and adequate to provide a trusted mechanismfor authentication secure from attacks such as phishing.

In this framework, the users need to deal with Higgins only in order to han-dle their identities and profiles with many identity management systems. TheHiggins architecture makes this is possible by plugging in those multiple identitymanagement systems.

PRIME [22, 127, 128, 129, 124] (Privacy and Identity Management System) isan identity management system project targeting the development of a prototypecapable of enhancing privacy protection. The developed prototype will providesolutions for managing user’s digital identities in online services. The project isfunded by European Union’s Sixth Framework Program and the Swiss FederalOffice for Education and Science. PRIME is a user-centric identity managementsystem that gives control of personal information back to the user allowing himor her to be in charge of disclosing personal information when needed and uponagreement with a service provider to get access to an online service. The systemcontains user agents that give users the capability to manage their digital iden-tities. To provide a high level of privacy protection, the system is bounded andenforced by a set of legal regulations related to revealing personal information inaddition to providing the ability to authenticate a user’s identities anonymouslyusing cryptographic technology and trusted computing platforms.

Page 57: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

2.8. User Centric Identity Management 35

The PRIME project is now superseded by PrimeLife4. PrimeLife is build uponand an expansion of PRIME project. PrimeLife’s prototypes cover different areasof privacy-enhancing identity management such as social networking, web trans-actions, and mobile computing.

OpenID [130, 121] is an authentication method that enables users to authenti-cate to service providers using a single login credential through a trusted thirdparty called the “OpenID provider”. OpenID eliminates the need for serviceproviders to provide their own authentication systems and users’ login credentials.The term OpenID is also used to refer to a user ID which often takes the form ofa unique URL that represents an identifier for a particular user. This unique URLID replaces all self-generated usernames a user may have with different services.

The authentication starts when the user requests an access to the serviceprovider and provides their URL ID. The service provider uses the provided URLto extract the OpenID provider’s URL. The service provider then communicateswith OpenID provider through a user-agent such as the Internet browser to han-dle the authentication process. OpenID may work with low risk services such associal networks to avoid remembering too many passwords, but the system mayfail to work with high risk services such as online banking. Some researchers haveargued that OpenID is vulnerable to phishing attacks [99]. For example, a mali-cious service provider may relay the authenticating user to a fake OpenID providerauthentication page asking that user to enter their login details and then stealinguser’s account with the real OpenID provider. The attacker will then have accessto all services the victim user authenticates to via the stolen OpenID account.

In addition OpenID is also vulnerable to the trust problem. Using the OpenIDsystem, service providers must trust security authentication assertions from OpenIDprovider and should therefore allow users authenticated via this OpenID providerto access their services. With the increasing number of OpenID providers, it isunlikely that a circle of trust will exist between service providers and OpenIDproviders.

Many other solutions to the identity management have been proposed anddeveloped to enhance usability and scalability and to protect user privacy. Someof these user centric solutions are developed to enhance security by using out-of-band communication channels. Other solutions are designed to be user centric bystoring credentials and personal information in separate devices.

4See http://www.primelife.eu/

Page 58: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

36 Chapter 2. Background

2.8.1 Solutions Using Out-of-band Communication Chan-nels

Identity management solutions in this category use out-of-band secondary commu-nication channels such as mobile networks to strengthen identity authentication.The authentication process is independent of the Internet and therefore minimizesthe risk of attacks. To achieve security the secondary communication channel hasto be secure.

Below are three examples of mobile identity management solutions:

• Authentication Prototype with Location Support: Looi (2001) describes adual channel multi-factor user authentication prototype using GSM cellularphone networks [103]. In addition to a combination of knowledge-based (pin)and possession-based (mobile phone) authentication factors, the prototypeintroduced a new authentication factor called the location-based factor whichrepresents the location of the user at the time of authentication.

The prototype uses the challenge-response protocol by exchanging authenti-cation information (including user location) through a GSM network. Theuse of challenge-response protocol and dual channel for authentication makesthis solution very strong. However the solution doesn’t consider the usabilityand scalability aspects.

• Authentication Protocols for Third Generation Mobile Communication Sys-tems: Cheng et al. proposed an authentication framework and a secureauthentication protocol for third generation mobile communication systems[30]. In this framework, the authentication process is solely done by theservice provider without cooperation of any other mobile network. Whenthe subscriber roams to other mobile networks, the visited network is notinvolved in the authentication protocol; the role of the visited network is toforward the subscriber information to the home network for authentication.

• SMS-based Authentication: A specific implementation by some online banksis based on authorizing financial transactions using SMS messages sent tothe user’s mobile phone. Although the user has been authenticated and isalready logged in to the online bank web site, this allows authentication ofthe transaction request itself.

Page 59: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

2.8. User Centric Identity Management 37

SMS messages sent from the bank to the user’s mobile phone pass throughthe cellular network, independent of the Internet. The user can manuallytransfer data from the mobile phone to the client terminal. By verifying thecorrect transfer of data from the mobile phone to the client terminal, the bankcan conclude that the user received the data through the cellular network,read it and submitted it through the Internet. This is then interpreted asa genuine intent to submit the transaction. This scheme is similar to thatproposed by Looi[103] except that there is no processing of challenge-responseso therefore protocol is cryptographically weaker. The scheme is discussedin more detail in Section 2.12.1

2.8.2 Solutions with Separate Repositories

In the separate repositories solutions, the idea is to develop systems that separateprivate personal information from the user platform and store them in a remoterepository or an external device. The communication between the repository or thedevice and the user platform can be established using some kind of physical, wiredor wireless communication. The goal is to return the control over the personalinformation back to the owner which is the user. Some examples of such solutionsare:

• Mobile Architecture for Strong Personal Authentication: Herrera-Joancomartiand Prieto-Blazques (2003) presented an authentication architecture calledMASPM [71] (Mobile Architecture for Strong Personal Authentication) thatuses the token-based factor in authentication. The architecture substitutesthe smartcard-reader device token with a mobile device-Wireless PersonalArea Network token. The idea is to separate private personal informationfrom the user platform and store them in the mobile device, protected usingcryptographic operations. The communication between the mobile deviceand the user platform is established using a short physical range wirelesspersonal area network such as Bluetooth.

This approach provides some security enhancement by using the mobilephone as a repository for user’s personal information but it is weaker thanthe solution presented by Looi since it doesn’t use a secondary communica-tion channel for authentication. Like Looi’s solution, this approach doesn’tconsider usability and scalability aspects.

Page 60: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

38 Chapter 2. Background

• CredEx: Vecchio, Basney and Nagaratnam [43] presented CredEx which is anopen source Web Service that is used to securely store credentials in a remoterepository and dynamically allow credentials to be exchanged. CredEx usesthe WS-Trust token exchange protocol. The service allows SSO by allowingthe user to acquire a single credential and dynamically exchange it withdifferent service providers.

In fact, this solution doesn’t preserve privacy. Storing authentication in-formation in a remote repository which is managed by a third party givesthe third party control over the user’s information. The SSO and dynamicexchange of credentials improve usability from the perspective of the user.

• IDRepository: Koch and Worndl [94, 95] presented a user centric identitymanagement architecture called IDRepository. The architecture gives thecontrol of personal information to the user by separating it from serviceproviders and storing it in either a one central server repository or severalservers. The architecture uses a protocol that allows the exchange of userprofiles between service providers.

This solution is similar to CredEx and has the same advantage (usability)and disadvantage (privacy).

2.9 Analysis of User Centricity in Existing Iden-tity Management Solutions

The proposed research mainly focuses on designing scalable secure identity man-agement architectures that at the same time provide a good user experience byenhancing usability and preserving privacy. The initial assumption is that a user-centric approach represents the best basis to achieve this.

User Centric Identity Management is an approach aiming to make identitymanagement user friendly and cost effective from the users’ perspective. Accept-able approach must also be secure and privacy preserving. Current approacheshave been argued to have limited potential for providing solutions that are trulyuser centric because of the weaknesses in the areas of usability and privacy. Thesolutions proposed in this project involves the integration of hardware and softwareon the user side in order to assist users with identity management.

Page 61: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

2.10. Passwords Credentials 39

The User Centric Identity Management approach has the potential to elimi-nate the disadvantages of the existing identity management models. It aims toimprove the usability and scalability of identity management systems. Some ofthe identity management solutions presented in this preliminary literature reviewhave elements of being user-centric however they do not satisfy all desirable re-quirements for being user-centric, e.g. some do not provide adequate usabilityfrom the user’s perspective. These solutions are the Silo model, Looi’s proto-type, Herrera-Joancomarti and Prieto-Blazques architecture, SMS authentication,CredEx and IDRepository. Some solutions do not solve the scalability problemlike the Silo model, Looi’s prototype, Herrera-Joancomarti and Prieto-Blazquesarchitecture and Federated model. Some solutions do not preserve privacy suchas the Centralized SSO Identity model, Microsoft’s Metasystem, Federated model,CredEx and IDRepository. Finally, none of the identity management solutionspresented here provide an effective way for the user to be able to identify serviceproviders.

2.10 Passwords Credentials

A password is usually a secret string of characters used to authenticate an entityor gain access to a resource or service. User names and passwords are commonlyused by people in the login process that controls access to protected systems andservices. The name passcode is used when the passwords consists only of nu-meric digits, such as the personal identification number (PIN) commonly used foraccessing devices such as mobile phones.

The main problem with passwords is that they may be forgotten, stolen,spoofed or guessed by an attacker. Generally the easier a password is to remember,the easier it will be for an attacker to guess [18]. Even difficult passwords mayreduce the security of a system [56]. This is because users usually use some pass-word management strategies that weaken overall security such as writing downor electronically storing the password or re-using the same password for differentservices [145]. The more restricted requirements for password creation are thegreater the degree to which users will adopt practices that subvert security of thesystem.

Traditional passwords rely on human memory. Even though, people can re-member huge amounts of information, their memory is still limited. It can be an

Page 62: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

40 Chapter 2. Background

extremely tedious task for people to remember complex passwords. In a study [25],participants were asked to create passwords according to specific guidelines. Thestudy concluded that after one day of usage, the participant could not rememberthe passwords they created for about 50% of the time. Another study [46] foundthat users who participated in the study failed to recall a password one week afterthey created it in about 30% of cases. In a survey on human factors considerationsfor passwords and other user identification techniques [6, 7], cognitive pressure wasmentioned as one of the major aspects that has an effect on users when managingpasswords. Five factors were described to exert pressure on human memory whencreating and remembering passwords. These factors are the password length, com-plexity, frequency of change, frequency of use and number of passwords. Also in[6, 7], social aspects and user attitudes were mentioned as playing a major rolethat affect users’ password practices.

Difficult passwords can increase the user’s short-term human memory loadwhich may cause frequent errors. Studies showed that capacity of short-termhuman memory load is normally 7 +/- 2 items [107].

Traditional password systems apply some design features intended to strengthenpasswords and protect against password attacks. However, such features couldbreak some of the usability standards for security systems [70]. In fact, dealingwith traditional passwords may violate some of the eight “Golden Rules” for in-terface design recommended by Shneiderman [147]. For example, the traditionalrequirement that passwords shall be long and difficult to guess may violate the“Reduce short-term memory load” rule which indicates that the limitation of hu-man information processing in short-term memory requires security actions bekept simple.

Many solutions were used by service providers to provide strong authenticationmethods but still vulnerabilities remain. Complicated and demanding authenti-cation methods will always be misused by users. Users may usually avoid anannoying security task to get their work done [13, 138, 4]; e.g. a user might ignorechanging his password frequently.

Due to the higher possibility in which permanent passwords can be compro-mised, other passwords techniques have been developed. Some of these techniquesare presented below:

• One-time passwords or single-usage passwords are passwords which are onlyvalid once. This technique eliminates many potential attacks. One-time

Page 63: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

2.10. Passwords Credentials 41

passwords [68] have been widely implemented in online banking, where theyare known as Transaction Authentication Numbers (TANs) [97].

• Time-synchronized passwords are similar to the previous technique but thepasswords are displayed on a small portable token device and changed at aspecific time period such as every 30 seconds. The password can be reusedduring this time period. An example is illustrated in [143].

• PassWindow is a technique of generating one-time passwords and facilitatingtransaction verification. It is also used for single usage but the dynamicpassword is visible only when a user superimposes a unique printed visualkey over a challenge image generated by a server and shown on the user’sscreen. The system works by encoding digits into a segment matrix similarto the seven-segment matrices5 used in digital displays, see Figure 2.6.

Figure 2.6: Seven segment display sample

The matrix is divided into two patterns that reveal the password when su-perimposed. One pattern (i.e., the key pattern) is printed on a transparentmedia such as a plastic card, see Figure 2.7, and the other (i.e., the challengepattern) is displayed on a screen such as a computer monitor.

The challenge pattern can only be decoded by its corresponding printed key.By changing the challenge patterns displayed on the screen, a series of digitsare revealed to the card holder without being visually displayed on the screen.

5A seven-segment display is an electronic display device that displays decimal numerals.Seven-segment displays are widely used in digital clocks, digital alarms and other electronicdevices for displaying numbers.

Page 64: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

42 Chapter 2. Background

Figure 2.7: PassWindow card sample

These digits are the one-time password. More details about PassWindow canbe found in [157]

• Mouse-movement based passwords. In this technique the user is requiredto configure a mouse movement figure during password registration. Theuser will be asked to move the mouse cursor within a specific area and theposition of the mouse cursor relative to that area is stored. Later when loginis requested, the positions resulting for the login movement are matchedagainst the stored values. The user will be granted access if a matchingvalue is calculated and exceeds a certain threshold. For more details see[132].

• Graphical password systems [45, 163, 31] are an alternative that attempts tosolve the memorability problem of traditional passwords and thereby enhancethe usability of the authentication process. A graphical password system usesimages, graphics or colors instead of letter, digit or special character stringsto minimize the effort needed by users to remember passwords. In graphicalpassword systems, users are required to click on a series of images in thecorrect sequence in order to authenticate themselves and gain access. Insome implementations, the graphical system requires users to select a seriesof faces as a password [152], utilizing the human brain’s ability to recall faceseasily.

Most graphical password systems are either recognition-based or cued recall.In the recognition-based systems authentication is done by asking users to

Page 65: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

2.11. Attacks on Passwords 43

select a set of previously chosen images while in the cued recall systems usersare required to click on specific locations of an image. Some researchers be-lieve that graphical passwords are stronger than typical alphanumeric pass-words and would be harder to crack [152, 164], but it is anticipated thatusers will follow similar password management strategies which will weakenthe system security since they are just as likely to pick common images asthey are to pick common passwords, see [41].

2.11 Attacks on Passwords

The traditional requirements that passwords shall be difficult to guess and bedifferent for different services puts a considerable mental burden on users. Variousstudies [20, 133, 58] show that people use heuristic strategies to reduce the mentalload. Unfortunately, these strategies also make passwords vulnerable to attack[79]. A typical strategy consist of reusing a small number of passwords for allthe services a user accesses [58, 79]. This means that the number of passwordsis constant while the number of services increases. To protect the service withthe highest risk, users often reserve a single password for that service. Userstend to reuse the same password, or variations of the same password for all lowrisk services. This practice represents a serious threat to the security of userauthentication, making systems vulnerable to all variants of password crackingattacks.

Passwords should be also protected against various threats such as computerviruses, man-in-the-middle attacks or snooping6 an unsecured communication chan-nel. Physical security measures are also required to protect against attacks suchas shoulder surfing7, video cameras or keyboard sniffers8.

Password cracking is the process of obtaining passwords generally by guess-ing or recovering them from transmitted or stored data. A common approachis to repeatedly try guesses for the password. Attackers use password crackingtechniques to gain unauthorized access to a system. A description of attacks on

6Snooping a password by wiretapping is done by intercepting and monitoring Internet datatransmission by an attacker to steal the password if it is transmitted to the authenticating entityon unsecured physical wiring.

7Shoulder surfing is the act of visual observation, such as looking over the victim’s shoulder,to collect information like as passwords.

8Wireless keyboard sniffers are those who collect data packets while being transferred from awireless keyboard and its receiver.

Page 66: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

44 Chapter 2. Background

password authentication follows.

Exploitation of weak encryption

Systems designed with weak password protection methods and poor hashing schemesto protect stored passwords can be exploited by attackers. The system must usestrong protection and hashing mechanisms, otherwise it will be vulnerable to at-tacks such as the cryptanalysis of weak cryptographic hash algorithms.

Password guessing

A weak password created by a user can be guessed by an attacker with someknowledge about the user’s personal information [49, 60]. Passwords like date ofbirth, phone number, wife’s name or son’s name are good candidates for passwordsthat can be easily guessed.

Attackers can have access to personal information about their targeted victimsusing techniques like social engineering or from many available online services.

Dictionary attack

This is a technique to determine passwords by searching likely possibilities. Theattack tries all the words in an exhaustive list called a dictionary [146]. Sincemany people choose single words passwords that can be found in dictionaries,dictionary attacks often succeed. Repeated research over many years has concludedthat a considerable percentage of user-chosen passwords are easily guessable bysophisticated dictionary attack cracking programs. See [125] for more details.

Brute force attack

Brute force is to try every possible password. The key factor in this type ofattacks is the password length. As the length of the password increases, thenumber of possible passwords also increases. The practicality of brute force attackis reasonable with passwords that are relatively short. Techniques using parallelprocessing can be used to reduce the time needed to find passwords. There are twotypes of brute force attacks: offline and online attacks. If the attack is executedwithout a connection to the protected resource then it is an offline attack; otherwiseit is an online attack. Online attacks are generally easier to defend against because

Page 67: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

2.12. One-Time Password Solutions 45

the number of guesses in a time period can be controlled. More about brute forceattack can be found in [91].

Precomputation attack

With this attack, each word in the dictionary is hashed and the word is stored withits computed hash to enable lookup on the list of computed hashes. In this manner,when a new hashed password is intercepted, password recovery is instantaneousbecause the interceptor may have an access to the list of computed hashes wherethe hash value and corresponding password can be found. The precomputationattack can be avoided by randomizing the hashing process. This is known assalting. The salt, which is a random string value, and the password are usedas the inputs to a derivation function and the output of the derivation functionis stored as the modified version of the password. The key derivation functionis typically a cryptographic hash function. The salt is stored with the hashedpassword since it will be required during verification.

The salt data complicates precomputation attacks. To extract a passwordfrom an intercepted hash value, an attacker must calculate the hashes of randomcharacter. In this manner, a simple dictionary attack against the encrypted valuesbecomes impractical if the salt is large enough because creating a dictionary ofencrypted values (password + salt) would either take too much time or too muchspace. See [17] for more information about this attack.

2.12 One-Time Password Solutions

As the name suggests, a one-time password (OTP) is a password that can only beused once. OTPs improve password security by effectively eliminating the need forusers to create and manage passwords and consequently reduces password crackingattacks. In addition, OTPs enhance data origin authentication by allowing theauthentication process even at the transaction level.

OTPs are meant to avoid a number of threats associated with traditional staticor permanent passwords. Most importantly, OTPs are not vulnerable to replayattacks9. This means that, if a potential eavesdropper intercepted, for example,an authentication transmission and got access to an OTP that was already used

9In a replay attack, valid data transmission such as authentication credential is maliciouslyretransmitted by an attacker to gain unauthorized access or perform illegal action.

Page 68: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

46 Chapter 2. Background

in a login session; he will not be able to reuse the OTP since it will be no longervalid.

An OTP is 6 to 8 alphanumeric character password that is used only oncefor user authentication or for the user to authorize a transaction. The two mosttypical implementations for OTP used by service providers such as banks are theSMS-based authentication scheme and the token-based authentication solution.The next two sections describe the two implementations in some detail.

2.12.1 SMS-based Authentication

Architecture

The SMS-based authentication is based on authorising financial transactions usingSMS messages sent to the user’s mobile phone. Although the user has been au-thenticated and is already logged in, this allows authentication of the transactionrequest itself, and makes the security independent of the client terminal’s security.

SMS messages sent from the bank to the user’s mobile phone pass through theGSM network, which is independent of the Internet. The SMS message containsthe transaction details and an authorization code needed to confirm the transac-tion. The user can manually transfer authorization code from the mobile phone tothe client terminal. By verifying the correct transfer of authorization code fromthe mobile phone to the client terminal, the bank can conclude that the user re-ceived the data through the cellular network, read it and submitted authorizationcode through the Internet. This is then interpreted as a genuine intent to submitthe transaction. The security of this scheme is based on the assumption that itis difficult for an attacker to steal the user’s personal mobile phone and to attackthe cellular network. The security of the scheme also assumes that the mobilephone and the client platform are not simultaneously vulnerable to software at-tacks that would communicate and allow an attacker to access the OTP or changethe transaction details. The scenario is illustrated in Figure 2.8 and Table 2.2.

The SMS authorisation code typically consists of 6 to 8 digits which is the samelength as a normal telephone number, and can therefore be copied manually fromthe mobile phone to the client terminal without too much effort. A typical SMSmessage as used in the scheme of National Australia Bank is illustrated in Figure2.9.

Page 69: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

2.12. One-Time Password Solutions 47

Figure 2.8: Authorising bank transactions via SMS

� Message/Action description1. The user types and inspects the transaction data displayed on

the client VDU2. The user initiates the transaction from the client platform3. The transaction data are sent by the client to the server4. The assumed transaction data with authorization code are sent

as SMS from the server to the user’s mobile phone5. The assumed transaction data and authorization code from the

SMS are displayed6. The user reads the assumed transaction data which enables him

to make a conclusion about the integrity of the transaction. Inthe positive case the user copies and submits the authorizationcode to confirm the transaction. In the negative case the useraborts the transaction.

Table 2.2: Messages in the SMS-based authentication scenario

Security Analysis

Assuming that an attacker changes the amount and/or the destination accountnumber, e.g. by a Trojan program on the client terminal, the modified amountand account number will appear in the SMS message. It is assumed that thecorrectness of the amount and of the destination account number is verified by theuser when copying the authorisation code from the SMS message. If a user victimfails to notice that the bank account number in the SMS message is not the sameas the intended account number, and submits the authorisation code through theclient terminal, the attack will succeed.

Assuming that the user verifies the correctness of the amount and of the bankaccount number in the SMS message, this scheme is thus secure against attacks on

Page 70: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

48 Chapter 2. Background

Figure 2.9: Example SMS message with authorisation code

the client terminal, and is in fact independent of the security of the client terminal.This represents a considerable security improvement. It is possible to leverage theuse of SMS messages in this way because the amount of crucial data is sufficientlysmall to be communicated in a single SMS message.

This scheme assumes that the mobile terminal can be trusted, i.e. that noattacker is able to take over the control of mobile terminal as is the case forstandard desktop client terminals. If it were possible to take over the control ofthe mobile terminal, an attacker could change the SMS message, and present theexpected amount and the bank account number, so that the SMS message thatthe user reads is not the same as the SMS message that the bank sent.

The scheme depends to some degree on the security of the mobile phone net-works, and it assumes that no attacker is able to modify SMS messages sent tothe user. Even if interception and cryptanalysis of SMS messages sent over the airwere possible, it requires that the attacker is physically present in the same basestation coverage area, and this excludes attacks from anywhere in the world.

However, SMS authentication schemes may be vulnerable to delay and unreli-able mobile SMS delivery. Availability is a fundamental security goal which meansthat data and resources must be accessible when needed by an authorized user.The SMS authentication scheme may violate the availability principle. For exam-ple, since SMS messages traveling across different mobile networks may not arrivein a timely fashion, this could cause service denial [82]. The problem is amplifiedmanifold when SMS messages travel between different mobile network operators

Page 71: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

2.12. One-Time Password Solutions 49

in different countries.

Security Usability Considerations

Security systems for online banking need to provide adequate security usabilityand should have a simple and intuitive user interface.

While the mental load of verifying the correct amount and destination accountspecified by the SMS message is probably acceptable for a single transaction, therepeated process of verifying the same can be quite tedious leading to user apathy,thereby violating security usability principle 2d described in Section 2.4.1.

It has been noted that when faced with a frustrating security task, users maybypass or ignore that task [13, 138, 4]. Below is a real life example about a cyber-attack incident that supports the argument regarding the practices that peopletend to adopt when faced with a provoking task.

Court case: Baidu, Inc. v. Register.com, Inc.

A US court case [2] about a cyber-attack on Baidu10 where the intrudergained unauthorized access to Baidu’s account at Register.com11. Asa consequence, Internet traffic intended for Baidu’s web site was re-directed to a web page of the intruder. In this case, Baidu sued Reg-ister.com for damages resulting from the attack.

The facts alleged in the complaint are summarized as follows: On Jan-uary 11, 2010, an unauthorized individual claimed to be an agent ofBaidu (the “intruder”) contacted Register using its “technical support”Internet chat service. The intruder requested an email address changeon file for Baidu. The Register service representative asked the in-truder to provide security authenticating information. Even though,the intruder provided the representative with a false verification infor-mation, the representative emailed a security code to the email addressthat Baidu had on file. The representative then asked the intruder to

10Baidu, Inc. and Beijing Baidu Netcom Science & Technology Co., Ltd. (together, “Baidu”)operate an Internet search engine service in China. Baidu is the third largest search engine in theworld and the largest in China. Baidu owns the domain name baidu.com. It generates revenuethrough the public’s use of its search engine service on its web site.

11Register is an accredited domain name registrar that provides domain name registration,Internet traffic routing, and related services for its customers.

Page 72: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

50 Chapter 2. Background

repeat the security code back via the Internet chat and since the in-truder cannot access Baidu’s email account where the security code issent, he gave a completely different and false code. The representativebypassed the company’s authentication procedure again and did notcompare the two security codes and changed the email address on filefor Baidu to the new email address provided by the intruder. Changingthe email address allowed the intruder to access Baidu’s account withRegister. The intruder then tried to gain access to the Baidu accountand the Register’s system asked the intruder to provide Baidu’s username and password. The intruder clicked on the “forgot password”link and Baidu’s user name was then sent to the intruder’s email ad-dress and gave him the option to change Baidu’s account password.In the end, the intruder successfully gained unauthorized access to theaccount. After gaining full control over Baidu’s account, the intruderre-routed Internet traffic from Baidu’s web site to his site. Any Internetusers attempting to use the Baidu search engine were routed insteadto the fake web site. As a result, Baidu’s operations were denied forfive hours and did not fully resume until a couple of days. As a con-sequence, Baidu claimed to suffer serious and substantial injury to itsreputation and business.

This is a classic instance of a company that had procedures to authenticateand verify an identity, but failed to use them when an intruder sought access to acustomer’s account.

The authentication numbers provided by the intruder and verified and approvedby the Register’s representative were substantially different. It is possible that therepeated process of verifying the same for each customer can be considered as amonotonous task leading to Register’s representative lack of concern. People preferto have their work done in a convenient way and as mentioned before they mayusually avoid or disregard frustrating security tasks.

In order to determine the usability of SMS-based authentication scheme aninvestigation was needed. Chapter 4 describes an experiment which is conductedto evaluate the usability of the SMS-based authentication scheme.

Page 73: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

2.12. One-Time Password Solutions 51

2.12.2 One-Time Password Tokens

There are two types of OTP generator tokens, hardware tokens and software to-kens. An OTP hardware token is a dedicated password generator device with anLCD screen which displays a pseudo-random number consisting of 6 or more al-phanumeric characters. Software tokens are OTP’s generating functions that arestored on a general-purpose device such as a desktop PC, laptop, PDA, or mobilephone.

Also, tokens can either be time based or event based. With the time-basedtokens, OTPs change at a specific time interval such as every 30 or 60 seconds.They require some sort of synchronization between the user’s token and the au-thentication server. On the other hand, event based tokens work on the principlethat when one OTP has been used, the next OTP in sequence is generated. Thepseudo-random number changes when clicking a button on the token. The tokendevice is synchronized with a peer OTP generator on the service provider sideand both tokens generate the same sequence of numbers. The main weakness withtime-based tokens is that they may become unsynchronized. This requires the userto resynchronize the token with the server.

The simplest and most common tokens do not need any connection to a com-puter and the OTP must be copied manually from the token to the client terminal.In fact, this separation gives this type of token its security strength.

Tokens come in other forms as well. They can be smart card or USB stick tokensthat can be physically connected to the client computer. Other types of tokensconnect to the client computer using wireless techniques, such as Bluetooth tokens.Connected tokens have the advantage of transmitting the OTP automatically tothe client computer. This feature can enhance usability by removing the need forthe user to manually copy and submit the OTP.

Another type of physical token is the contactless token. This category doesnot require a physical connection making them more convenient than both con-nected and disconnected tokens. Contactless tokens use RFID (Radio-frequencyidentification) to transmit authentication information.

In general, software tokens are considered to be weaker than hardware tokensbecause of the vulnerable nature of software compared to the security of hardwaretokens, thereby making hardware tokens less vulnerable to attacks; for example,with time-based software tokens, valid future passwords can be generated by simplyforwarding the clock on the platform where the software token is installed.

Page 74: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

52 Chapter 2. Background

The main disadvantage of hardware tokens is their usability. With an increas-ing number of hardware tokens needed by one user to authenticate to differentservice providers, the more inconvenient it becomes to manage all the different to-kens. On the other hand, since software tokens are installed in the devices whereauthentication is needed, this will eliminate the need for carrying separate physicaltokens for each service provider no matter how many tokens are required. This willmake software tokens more usable and will also make them cheaper than hardwaretokens.

A complex mathematical algorithm known as a hash function is usually usedto generate the series of OTPs due to the one-way nature of the hash function.Each password is unpredictable, even when previous passwords are known. Withsoftware tokens, OTPs are typically generated using a shared secret key. In thismanner, an administrator will normally create and then submit a shared secretkey to each user. The shared secret key will then be seeded to the software tokento generate the series of OTPs.

The shared secret key should be under the service provider control and beyondthe user control. This is because users often are the weakest link in the securitychain which is reflected by the relatively high success rate of social engineeringattacks to compromise security systems, whereby the attacker manipulates thevictim user to divulge confidential information that can be used to defeat thesystem’s security. Implementing this feature (i.e. service provider controlling theshared secret key) will enhance the security of shared secret key tokens. Unlessthe shared secret key is known to the attacker, such scheme will make a stolensoftware token useless.

Some mobile phone can be configured to work as security tokens. Mobile phonetokens can reduce costs and eliminate the need for separate token device for eachservice provider. In the next section, Trusted Computing Technology is introducedthen later in Chapter 7, a description of how to adopt this new technology todevelop more secure tokens using mobile phones is presented.

2.13 Trusted Computing (TC)

Trusted Computing (TC) is a general term used to describe security systems thatare based on secure hardware. The Trusted Platform Module (TPM) is standard-ized chip that can provide support for TC. The TPM standard is developed and

Page 75: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

2.13. Trusted Computing (TC) 53

promoted by the Trusted Computing Group (TCG) an initiative led by IBM, Intel,Microsoft, AMD and others12. The purpose of the TPM standard is to supportstrong security functions as well as Digital Rights Management (DRM). With TC,certain aspects of a computer’s behavior can be enforced by hardware combinedwith software. TC functions of the TPM are based on verifying that software hashvalues (so-called measurements) are equal to predefined values, which in turn canbe used to provide assurance of the authenticity and integrity of software modules.The TPM is currently integrated into and shipped with many hardware platformssuch as PCs and servers. While the TPM is rarely used in current systems, its rel-atively large penetration provides a basis for implementing identity managementsolutions with strong security. Figure 2.10 shows an example of a TPM chip.

Figure 2.10: A sample of an Infineon TPM chip

The TPM security requirements are defined and may be evaluated according tothe so called Common Criteria. The TPM provides the components of a subsystemused to assure integrity, confidentiality and authenticity within a Trusted Com-puting Platform. The TPM provides cryptographic functionality such as [28, 62]:

• Random number generator.

• Asymmetric key generation.

• Asymmetric encryption/decryption.

• Generation/verification of digital signature.

• Hash algorithms.12See: http://www.trustedcomputinggroup.org

Page 76: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

54 Chapter 2. Background

• Identification and authentication mechanisms.

• Secure storage.

Tampering is the deliberate act of altering or corrupting a product, device, orsystem. Three levels of security requirement are defined with tampering. Theseare tamper-detection, tamper-evidence, and tamper-response. The FIPS PUB140-2 [118] defines these tampering security requirements as the following. Tam-per detection is “the automatic determination by a cryptographic module thatan attempt has been made to compromise the physical security of the module”.Tamper evidence is “the external indication that an attempt has been made tocompromise the physical security of a cryptographic module. (The evidence of thetamper attempt should be observable by an operator subsequent to the attempt)”.Tamper response is “the automatic action taken by a cryptographic module whena tamper detection has occurred (the minimum response action is the zeroizationof plaintext keys and CSPs)”.

According to the TCG standards, the TPM is required to have a physicalprotection from tampering [64]. More specifically, the TPM module is requiredto be physically bound to the other physical parts of the platform such as themotherboard in which the TPM cannot be easily disassembled and transferred toother platforms. It is a requirement by the TCG’s standards for the TPM to betamper-evident. The TPM module should employ tamper-evidence measures toenable the indication of any attempt to compromise the physical security of themodule [64]. Tempering with the TPM module should be detected upon physicalinspection.

2.13.1 TPM Cryptographic Keys

The TPM offers facilities for secure generation of cryptographic keys, and for con-trolling their use. The usage of some cryptographic keys of the TPM is restricted.For example, the owner of a computer is denied from knowing or accessing thesekeys in general. The usage of the keys inside the TPM is controlled according topolicies specified in the TPM standard, and enforced by the TPM chip.

Every TPM comes with a unique key called the Endorsement Key (EK) whichis embedded in the TPM at the manufacturing time [28]. The EK is an RSA pairkey consisting of a private key (EKpr) and a public key (EKpu) that are 2048-bitRSA. The private key of the EK key pair (EKpr) is stored within the TPM’s secure

Page 77: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

2.13. Trusted Computing (TC) 55

hardware boundaries and is only used inside the TPM and cannot be accessedoutside the TPM. The uniqueness of the EK pair represents the individuality ofevery TPM and the trusted platform based on it and can be used to facilitate theencryption of sensitive information in such a way that only the TPM can decryptit.

Upon activating the TPM a special 2048-bit RSA key is generated and is guar-anteed to always be present in the TPM. This key is called the Storage Root Key(SRK) and is in fact the root for all keys generated by the TPM [28].

Keys generated by the TPM can be either migratable or non-migratable [28,62]. Migratable keys can move from one platform to another to provide the capa-bility of more than one system to use a key while non-migratable keys are usedwhen the private portion of the key needs to be guaranteed to only be available toa particular TPM. Also, keys generated by the TPM can be classified accordingto their usage [28, 62]. Storage keys are used to store other keys or data. Bindingkeys can be used to encrypt symmetric keys and bind them to a particular TPM.Identity keys or Attestation Identity Keys (AIK) are used to sign other TPM keys.AIK are also used to sign PCR13 values (representing the software state of a plat-form). The AIK is an RSA 2048-bit private/public key pair (AIKpr, AIKpu) usedto identify the TPM to a local or remote entity. An AIK pair can only be used instrictly controlled ways, and only ever for generating and verifying signatures. Themain intended use for an AIK is for attestation [28]. That is, the AIK private key(AIKpr) can be used by a TPM to sign PCR values and the public key (AIKpu)can hence be used for verifying signatures on PCR values. More generally, anAIKpr can only be used for signing values generated by the TPM itself and theAIKpu is then used to verify these digital signatures. An example of a TPM’shierarchy key is shown in Figure 2.11

2.13.2 Key Certification

The TPM uses a number of certificates. The certificates are classified in a treeor hierarchical chain, which ensures that every certificate can be validated by itspredecessor [28, 19]. The validation process continues up to the root certificatewhich is assumed to be known and trusted. This arrangement allows externalentities to authenticate the origins of a given certificate and track its ancestor

13A PCR is a Platform Configuration Register in the TPM that stores a cumulatively updatedhash of the platform configuration values commonly known as measurements.

Page 78: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

56 Chapter 2. Background

Figure 2.11: TPM’s Key Hierarchy Example

certificates in the hierarchy. The root or the starting point of this certificate treeis the TPM’s EK Certificate. The EK is loaded to the TPM with a certificatefrom the TPM manufacturer and/or the platform’s vendor (where it is embeddedin) and can prove to a secondary party that a key generated in the TPM wasgenerated in a genuine TPM [28].

The TPM manufacturer keeps an RSA key pair (MKpr, MKpu) for that pur-pose. The private key part (MKpr) is used to issue the Endorsement Certificateof the EK public key (EKpu) of each TPM. Assuming that the manufacturer andits public key are known, the existence of this certificate proves that the TPMis genuine and manufactured by a trusted manufacturer according to the TCGspecifications. A TPM with an Endorsement Certificate that does not chain to aknown and trusted root should not be trusted.

The private key (MKpr) of the TPM manufacturer certification authority (CA)key pair is stored in a highly secure environment at the manufacturer’s site. Itis only used to sign EK public key (EKpu) after production while the public key

Page 79: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

2.13. Trusted Computing (TC) 57

(MKpu) of the manufacturer CA key pair is made publicly available to be usedfor the verification of signed EK. As an example, the manufacturing certificate ofInfineon (a market leader in TPM chips and solutions) is published in the Infineonweb page for the purpose of verification of the Infineon TPM [153].

To add another level of trust and make the TPM’s internal certificates morerecognizable and trusted, the TPM root certificate (i.e. TPM’s EK certificate) canbe digitally signed by an external Trusted Third Party. For example, the InfineonTPM EK Root certificate is chained to the Trusted Platform Module Root Cer-tificate Authority of VeriSign (the acknowledged market leader in highly securecertificate technology) [153]. This extended signature chain enhances security andraises the level of trust of the entire TPM certificate chain by relying the manufac-turer root verification process to the worldwide trusted infrastructure of VeriSign’sPKI, certificates and signatures in addition to the Infineon website. The VeriSigncertificate will be safely stored in the Infineon TPM in addition to the already ex-isted certificates [153]. This could allow the owner of a TPM with an Infineon EKcertificate to perform path-validation for any given EK certificate from Infineon.

2.13.3 Mobile Trusted Module

Many industry players are planning to include TC in the coming generation ofdevices such as mobile phones and PDAs where the TPM’s functions could beemployed [65]. The TPM specification provides security services common to allplatforms and allows them to be implemented for specific platforms. The TCGprovided a security specification for a trusted module similar to the TPM but isintended for mobile phones. The Mobile Trusted Module (MTM) specification [66]builds on the TPM security specification and trust model. The MTM specificationidentifies multiple owners of a mobile phone and defines two types of MTMs [66,63]: the Mobile Local-Owner Trusted Module (MLTM) and the Mobile Remote-Owner Trusted Module (MRTM). The MTM is used to refer to both MLTM andMRTM. The MTM and TPM are compatible except for minor differences. TheMLTM is defined in terms of capabilities and commands that are defined in theTCG TPM specifications [66]. The MRTM can provide similar services (but notnecessarily all) to the MLTM with extra functions to enable remote owners (e.g.the phone vendor and the cellular network provider) to control services such asaccess to the IMEI14 and the cellular network [66, 63]. More information about

14International Mobile Equipment Identity is a number unique to every mobile phone

Page 80: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

58 Chapter 2. Background

TC can be found in [28, 108, 123]Encryption is an important feature of trusted computing technology. Data can

be securely encrypted using binding or sealing functionality provided by the TPMwhereby data is encrypted in such a way that it may be decrypted only underTPM control. “Binding” encrypts data using a TPM generated non-migratablebinding key while “Sealing” encrypts data similar to binding, but specifies a statein which the TPM should be for the data to be unsealed (i.e. decrypted).

An RSA key pair can be generated by the MLTM to protect sensitive infor-mation. Information can be encrypted using the generated public key so only theMLTM installed in a mobile phone (where the private key is stored) can decryptit. Using this method, the clear text data can be read only by a particular mobilephone application where the software hash value is equal to a predefined hash valuethat is stored in the MLTM. Attempts to read the data by any application otherthan the predefined one will be refused by the MLTM. This feature can be used toutilize mobile phones to work as security tokens. An application can be installedon the mobile phone to perform similar functions normally provided by dedicatedtokens. Chapter 7 describes an enhanced solution that uses trusted computingtechnology to configure the mobile phone as a multi OTP generator device.

2.14 Conclusion

The common objectives of identity management systems are protecting the confi-dentiality, integrity and availability of personal identity credentials and providingadequate authentication methods. Many solutions have been developed to pre-serve these objectives and to facilitate users’ access to systems and to deal withand avoid expected threats. Unfortunately, most of these solutions do not considerthe security usability factor and consequentially do not provide convenient ways ofmanaging identities. If usability is not considered when designing a new identitymanagement system, complex systems may result and the user may become theweakest link in the security chain and the overall solution may have inadequatesecurity.

In this chapter, the problem of identity management as well as importantconcepts and features of identity management in addition to the major expectedthreats and attacks on identity systems have been reviewed. The chapter alsoillustrated current identity management models in detail and provided security

Page 81: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

2.14. Conclusion 59

and usability analysis of these models. Since passwords are the most commonused credential, they have been covered in more detail. The chapter presented one-time password solutions and focused on the two common solutions used in onlineauthentication systems: the SMS-based and token-based authentication schemes.The chapter provided a detailed security and usability analysis of the two systemsand identified some security and usability issues of these schemes that needed moreanalysis and experimentation which will be covered in the next chapters.

Finally, the concept of trusted computing technology was explained since itis used as a basis to a proposed solution aimed at enhancing the usability of thetoken-based authentication scheme.

Page 82: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

60 Chapter 2. Background

Page 83: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

Chapter 3

Research Approach and Design

3.1 Introduction

The chapter presents the research approach of the architectures and authenticationsolutions presented in this thesis. The solutions are based on the user centricidentity management concept which is believed to provide adequate usability andenhance user privacy. The chapter also discusses the research design in whichthe research project was undertaken. The “cyclic research process” method andother methods used in this research are explained in some detail. In addition, adetailed explanation of the research plan for each task of the project research isgiven according to the “cyclic research process”.

3.2 Research Approach

It is strongly argued that any identity management solution that is not user centricby definition will have limited usability. It is submitted that federated identitysolutions require a high level of trust between entities in the federation and infact, it is expected that the circle of trust in the federated domain will not expandto include the desired number of entities which will eventually lead to multiplefederated identity domains. By assuming that multiple federated identity domainswill exist, a user will most likely access service providers from different domains,and will therefore have to authenticate with the respective identity providers fromeach domain. The problem of usability and scalability will thus remain. The

61

Page 84: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

62 Chapter 3. Research Approach and Design

centralized SSO identity model has the same circle of trust problem as the federatedidentity model. The Silo identity model has usability and scalability issues whilethe common identity model is impractical.

User Centric Identity Management is an approach intend to make identitymanagement user friendly and cost effective from the users’ perspective. Thisresearch aims to propose secure identity management architectures that provide agood user experience by enhancing usability and solving the scalability problem.These architectures involve the integration of hardware and software on the userside in order to assist users with identity management. User Centric IdentityManagement systems will not only provide adequate usability but will also enhanceuser privacy [32].

3.3 Research Design

The research project was structured to be a Design Research. The project followedthe research method suggested by Vaishnavi and Kuechler [156]. The researchmethod considers the process of such research as a cyclic research process consistingof a number of steps or stages namely, awareness of problem, solution suggestion,artifact development, evaluation and finally conclusion or result. Figure 3.1 showsa diagram of the the research cyclic process.

At the awareness of problem stage, the research problem was identified anddescribed. During the suggestion stage, proposed solutions or tentative designs tothe acknowledged problem were presented. In the development stage an artifactfor the tentative design was developed. The performance of the developed artifactwas evaluated and measured during the evaluation stage. From evaluation stageit was always possible to go back to any previous step (awareness, suggestion anddevelopment) to make necessary changes that may appear during the evaluationstage. The last stage in the research process was the conclusion in which a finalaccepted result was reached.

Experiment was another appropriate research method that was used in thisresearch. One way to define experiments is that they are scientific approachesthat arbitrate between competing hypotheses [35]. Experimentation can also bedefined as a scientific method used to test existing theories or new hypotheses inorder to support them or disprove them [61]. The aim of an experiment is generallyto answer a question or investigate a problem to be able to predict phenomenon

Page 85: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

3.3. Research Design 63

Figure 3.1: The Proposed Research Design [156]

or explain causation. An experiment is usually carried out when an observation ismade, a question is asked and a hypothesis is formed. The experiment is then usedto test that hypothesis and from the experiments’ results, conclusions are drawnthrough analysis.

In a wide definition, experiment is a study in which the experimenter ma-nipulates something to observe the consequences [24]. Investigation of currentauthentication schemes was part of this research. Experiment was a useful toolfor such investigation since it allows researchers a certain amount of control inmanipulating variables under tight conditions [16].

An experiment can never prove a hypothesis, but it can support its correctness.However, an experiment with a counterexample can disprove a hypothesis. Bothconcepts (i.e. supporting the hypothesis correctness and disapproving a hypoth-esis) were used in this research. The experiment explained in Chapter 4 is basedon the second concept while the experiment explained in Chapter 5 is based onthe first concept.

Next, a detailed explanation of the research plan for each research task accord-ing to the research methods mentioned above is given.

Page 86: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

64 Chapter 3. Research Approach and Design

Research Task 1

Description: Investigating the usability of SMS-based authentication protocolcurrently in use.

Research method:

1. Awareness of problem: Authentication and identity management of theearly implementations were found to be vulnerable to various attacks such asphishing. Current state-of-the art solutions include methods for authenticat-ing users via out-of-band channels. The SMS-based authentication schemeis one of these solutions aimed at enhancing the security of online authenti-cation; however some arguments suggested that the scheme is vulnerable tosecurity attacks due to poor usability.

2. Suggestions: Security of such solution needs to be investigated. The us-ability of SMS-based authentication in online banking needs to be examined.

3. Development: An experiment is conducted by developing a model thatsimulated online bank financial transactions and tested how participants in-teract when using authorization codes in such online services.

4. Evaluation: The behavior of participating users was evaluated while inter-acting with SMS-based authentication scheme by manipulating experimentvariables and conditions [16].

5. Conclusion: The findings and outcome of the experiment were published.

This research task is described in Chapter 4.

Research Task 2

Description: Design enhanced SMS-based authentication architecture.Research method:

1. Awareness of problem: SMS-based authentication scheme is vulnerableto security attacks due to poor usability.

2. Suggestions: Improve the SMS-based authentication security by enhancingthe scheme usability.

Page 87: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

3.3. Research Design 65

3. Development: A practical solution aimed at improving security of onlinebank SMS-based authentication by enhancing scheme usability is designedand described. In this solution, the transaction details validation processis automated to simplify the burden caused by the extra task of validatingevery transaction.

4. Evaluation: The developed authentication architecture was tested to exam-ine whether or not it eliminates known attacks. The solution was examinedto check whether or not it satisfied principles of usability mentioned in Sec-tion 2.4.1. Also, the experiment described in the previous task was repeatedon the new proposed solution and the experiment results were compared withthe results of the experiment of research task 1.

5. Conclusion: This task resulted in an architecture that strengthens thesecurity of SMS-based authentication scheme.

This research task is illustrated in Chapter 5.

Research Task 3

Description: Design a display security assurance solution for SMS-based authen-tication to strengthen online transaction authorization.

Research method:

1. Awareness of problem: Secure online transactions with human users nor-mally require visual display for verifying the correctness of central elementsof the transaction before it is submitted. When commodity computer plat-forms get exposed to the Internet, even for a short period, there is a realand substantial risk that they become infected with malware that can mod-ify anything on the computer, including what is displayed to the user andwhat is being sent over the Internet. This threat makes visual verification oftransaction data unreliable and undermines other security mechanisms usedto protect online transactions.

2. Suggestions: Improve the verification process of displayed data in the SMS-based authentication scheme to protect against the threat of compromisedplatforms.

Page 88: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

66 Chapter 3. Research Approach and Design

3. Development: A method for assuring the correctness of displayed data inonline transactions was designed. The solution aimed at ensuring that whatis displayed on the computer screen corresponds to what is being transmittedto other parties in online transactions. The method is based on using aportable PDA/camera (e.g. mobile phone) to capture the data from thescreen, recovering the data from the image through OCR, and using anout-of-band channel for matching this data with the data received by thetransaction partner.

4. Evaluation: The security and usability of the new method were analysed.In addition, a practical experiment was conducted to examine the integrity ofusing mobile phones, equipped with camera and OCR application, to convertthe transaction details displayed on the screen to text data.

5. Conclusion: A display assurance architecture which strengthens the secu-rity of SMS-based authentication scheme was the output of this task.

Full description of this task is presented in Chapter 6.

Research Task 4

Description: Design a token-based authentication solution that combines scala-bility and security features.

Research method:

1. Awareness of problem: Hardware and software tokens are used to gen-erate passwords that are used only once for user authentication or for theuser to authorize a transaction. The main disadvantage of hardware tokensis their scalability problem. With the increasing number of hardware tokensneeded by one user to be authenticated to different service providers, themore inconvenient it becomes to manage all the different tokens. On theother hand, since software tokens are installed in the devices where authen-tication is needed, this will eliminate the need for carrying separate physicaltokens for each service provider no matter how many tokens are required.Software tokens however are considered to be weaker than hardware tokensand more vulnerable to attacks.

2. Suggestions: Enhance the scalability of hardware tokens without compro-mising their security strength.

Page 89: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

3.4. Conclusion 67

3. Development: A scalable one-time password solution using mobile phonesand based on trusted computing technology that combines enhanced usabil-ity with strong security was designed. The solution combined the scalabilityfeature of using the mobile phone as a single device and the security strengthof physical protection provided by trusted computing technology.

4. Evaluation: The proposed solution was analysed from the security perspec-tive. The usability of the solution was also analysed according to the securityprinciples listed in Section 2.4.1

5. Conclusion: The output of this task was a scalable one-time passwordprototype with adequate security.

This task is illustrated in Chapter 7.

3.4 Conclusion

An outline of the research approach and design methodology of the architecturesand authentication solutions proposed in this thesis has been presented. Theresearch methods used in this project and the research plan for each task of theresearch have been explained.

In the next chapters, the SMS-based and token-based authentication schemesare examined and analysed. In addition, the proposed architectures and authen-tication solutions are described, examined, analysed and discussed in detail.

The next chapter describes a practical experiment that tested the security ofthe SMS-based authentication scheme by examining its usability.

Page 90: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

68 Chapter 3. Research Approach and Design

Page 91: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

Chapter 4

Investigating the Usability ofSMS-based Authentication

4.1 Introduction

Security for online banking has changed considerably during the relatively short pe-riod that online banking has been in use. In particular, authentication in the earlyimplementations were, and sometimes still are, vulnerable to various attacks suchas password sniffing, phishing and malware man-in-the-browser attacks. Currentstate-of-the art solutions include methods for re-authenticating users via out-of-band channels for each transaction.

Online bank systems usually implement special methods for authentication.These methods allow the authentication process at the transaction level by involv-ing the user more in the security system, having him/her confirm every transaction.

A common method for data origin authentication used by online bank systemsis based on sending an OTP with SMS messages to the user’s mobile phone foreach financial transaction. See Section 2.12.1 for a description of this method.

The term “authorization code” is often used by online banks to denote theOTP, because it is required to “authorize” transactions. This term will be usedinstead of OTP when discussing online bank security below.

The security strength of the SMS authorization scheme relies on the fact thatSMS messages sent from the bank to the user’s mobile phone pass through thecellular network, which is separate and independent from the Internet. By verifying

69

Page 92: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

70 Chapter 4. Investigating the Usability of SMS-based Authentication

the authorization code received from the client terminal, the bank can concludethat the user received the SMS message through the cellular network, read itand submitted it through the Internet. This is then interpreted as a genuinecommitment by the user to execute the transaction.

Assuming that the user verifies the correctness of the amount and of the bankaccount number in the SMS message, this scheme is secure against attacks onthe client terminal such as man-in-the-browser attacks, and is in fact indepen-dent of the security of the client terminal. This represents a considerable securityimprovement.

The process of verifying the correct amount and destination account specifiedby the SMS message is probably acceptable for a single transaction, however therepeated process of verifying can be quite tedious leading to user apathy.

This chapter describes a practical experiment aimed at investigating the secu-rity and usability of SMS-based data origin authentication for authorizing onlinebanking transactions.

The experiment simulated an online bank and tested if participants in the ex-periment were able to correctly use the SMS authorization scheme for authorizingfunds transfer transactions.

Section 4.2 gives a description of the experimental design which covers theexperiment objectives, ethical considerations and participants’ recruitment. InSection 4.3 the simulated online bank system design and implementation are de-scribed in detail. Section 4.4 talks about the participants’ role in the experimentand the task they had to perform. Section 4.5 illustrates the types of securityattacks implemented in the experiment. In Section 4.6 the participants’ demo-graphics are provided. The experiment’s results are presented in Section 4.7 whileSection 4.8 includes the discussion. Finally, Section 4.9 concludes.

4.2 Experiment Design

4.2.1 Objectives

The goal of the experiment was to examine the security usability of the SMS au-thentication scheme. In other words, the goal was to investigate whether users areable to perform the extra tasks in a satisfactory manner, and that executing thesetasks does not introduce new security vulnerabilities. It is important to knowwhether users are able to fulfill these tasks, because it shows whether it is reason-

Page 93: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

4.2. Experiment Design 71

able to make users liable for transactions based on this security technique. Bankswould normally assume that users are responsible for transactions authorized withthe authorization code. However, if a significant proportion of users are unable touse the method correctly, this assumption would be unreasonable and should bereassessed by the banks.

The experiment studied customer’s interaction with an online bank that usesthe SMS authorization code scheme described in Section 2.12.1. Participants wereasked to play the role of customers and perform a number of financial transactionsusing the simulated virtual online bank. Their reaction to security attacks wasmonitored and analyzed. The analysis would show whether it is reasonable tomake customers liable for errors made when using the system.

4.2.2 Ethical Considerations

The experiment was conducted during June and July 2007 at QUT (QueenslandUniversity of Technology) and involved human participation. The experiment wasreviewed and approved by the QUT Research Ethics Committee with approvalnumber 0700000373. There was a low risk associated with participation in theexperiment. A Web page with a consent form was presented to participants be-fore starting the experiment. Participants were asked to click a button labeled“Participate” to confirm their agreement to participate. The participants’ emailaddresses were required as part of the experiment. The participants were informedthat it would be kept confidential and would be deleted after completion of theexperiment.

4.2.3 Participant Recruitment

The participants were recruited by sending out invitation emails. Permissions touse several email distribution lists for sending out the invitations were obtained.The subject field in the invitation email said: “Invitation: Online banking securityexperiment”. The email body had the following content:

The Information Security Institute at QUT is running an experimenton the usability of online banking security, and you are invited to par-ticipate. You will find it fun and interesting to play with our simulatedonline bank. It will only take a few minutes. We would like you totransfer virtual money to different bank accounts imagining that you

Page 94: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

72 Chapter 4. Investigating the Usability of SMS-based Authentication

are using your real bank account and money. We hope you can makeat least 10 transactions. It is important that you take the same secu-rity precautions as you would with your real online bank account. Thismeans that you should cancel any transaction where you notice some-thing suspicious, because it could indicate a security attack. The list ofbank accounts is provided below.

For each transaction, you will do the following:

1. Start a new transaction by filling in the “New Transaction” webpage and clicking “Submit”. You will receive an authorization codeby email.

2. Fetch the email and verify that the transaction details are correct.

3. Confirm the transaction in case the details are correct. To con-firm, copy the authorization code from the email to the Web page,and click “Confirm”. Alternatively cancel the transaction if youthink there is something wrong. To cancel, simply click “Cancel”.

Please visit the URL below to start the experiment.

http://www.isi.qut.edu.au/people/alzomaim/bank/consent.htm

List of destination accounts to be used

Destination accounts: Suggested amounts:(only these possible) (other amounts possible)30263142 $500030263155 $50030263157 $550030263143 $5500030263158 $5000030263145 $440030263149 $4400030263150 $44030263144 $4440030263156 $400

Page 95: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

4.3. System Design 73

We ask you to execute at least 10 transactions. Multiple transfers tothe same account are possible.

Thank you,Note: Approval from the QUT ethics committee has been obtained.Your email address will be kept confidential and will be deleted aftercompletion of the experiment.

Other participants were recruited by personal contact providing them with a hardcopy of a document identical to the above email.

4.3 System Design

The simulated online bank was developed and participants were asked to executea number of financial transactions. Some of the transactions were corrupted tosimulate attacks. The transaction records showed whether participants were ableto notice the attacks and cancel these transactions.

It was expected that the average participants would not be willing to providetheir mobile phone numbers. Email messages provides similar functionality asSMS messages for the purpose of transaction authorisation. Also, the goal wasnot investigating the technical security aspects of SMS-based authentication. Forthese reasons it was decided to base the authorization of transactions on emailmessages instead of SMS messages.

A real Web system that simulated a virtual online bank was developed. Thevirtual bank consisted of two parts, the server front end that provides the httpinterface, and the server back end that handles the database (see Figure 4.1).

Both the front end and the back end were implemented using PHP (a program-ming language designed to build dynamic websites). The Bank database at theback end was a relational database designed, implemented and accessed using theMySQL relational database system.

4.3.1 Server Front End

The server front end was hosted on the Internet server of the Information Secu-rity Institute (ISI) at Queensland University of Technology (QUT). This serverpresented the simulated online bank interface where users could execute financial

Page 96: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

74 Chapter 4. Investigating the Usability of SMS-based Authentication

Figure 4.1: Simulated Online bank Model

transactions. The user interface consisted of two web pages entitled “New trans-action web page” and “Confirmation web page” that are described in more detailbelow.

New Transaction Web Page

The “New Transaction” web page (see Figure 4.2) allowed users to initiate newtransactions. The web page was designed to perform the following functions:

• Display the web page content in the browser window allowing users to entertransaction information.

• Validate entered data format which included account number, amount andemail address.

• Send entered transaction information to the bank server.

This page contained the following fields:

• Destination Account: An eight digit destination account number.

• Amount: Amount to be transferred

• E-Mail address: Where the authorization code is to be sent.

A “Submit” button triggered the transfer of the entered information to the virtualbank server and took the user to the Confirmation Web Page.

Page 97: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

4.3. System Design 75

Figure 4.2: New Transaction Web Page

Confirmation Web Page

The “Confirmation” web page (see Figure 4.3) allowed users to confirm and com-plete an initiated transaction. It was designed to do the following:

• Display the web page content in the browser window allowing users to enterthe authorization code.

• Send the entered authorization code to the bank server.

• Display the transaction confirmation information.

The page displayed the transaction information and contained a single field forthe authorization code to be entered. The page contained a ’Confirm’ button usedto confirm the transaction by sending the authorization code to the virtual bankserver and a button labeled “Cancel” to cancel the transaction. If the user chose toconfirm the transaction, a link to the ’New Transaction web page’ was displayedallowing him or her to do another transaction. If the user chose to cancel thetransaction, two links were displayed; one to do another transaction and anotherto return the user back to the confirmation page.

Page 98: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

76 Chapter 4. Investigating the Usability of SMS-based Authentication

Figure 4.3: Confirmation Web Page

4.3.2 Server Back End

Most of the functionality of the simulated online bank model was executed in theserver back end which was designed to do the following main functions:

• Generate authorization codes in the format of six-digit hex numbers. Eachcode resulted from applying the hash function SHA11 to the transactioninformation and a random number.

• Send transaction information to the “Confirmation” web page.

• Email the authorization code and transaction information to the user emailaddress.

• Verify received authorization code for a particular transaction.

• Generate security attacks by alteration of the transaction details in selectedtransactions.

The Bank database connected to the back end was a relational database whichwas designed, implemented and accessed using the MySQL relational databasesystem. All user interactions with simulated online bank when executing financialtransactions were stored in the bank database.

1Secure Hash Algorithm. A function that produces a fixed-length digital representation(known as a digest) of an input data sequence of any length.

Page 99: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

4.4. Participant Tasks 77

4.4 Participant Tasks

Participants were provided with instructions to complete a number of bank trans-actions using the simulated online bank. To complete each transaction, each par-ticipant had to do the following steps:

• Start a new transaction by filling the fields in the ’New Transaction’ webpage and then clicking the “Submit” button.

• Check email sent by the virtual bank server to validate transaction infor-mation and copy authorization code. See Figure 4.4 for an email messageexample.

• Complete the transaction by entering the authorization code in the “Confir-mation” web page and clicking the “Confirm” button or alternatively cancelthe transaction by clicking the “Cancel” button.

Figure 4.4: A sample of a confirmation email message

Participants were provided with a list of acceptable destination accounts andsuggested amounts to be used. Participants were also asked to complete at least10 transactions. All transactions and data collected from user interactions withthis experiment were recorded and stored in the database on the server back endside. The scenario of the experiment is illustrated in Figure 4.5 and Table 4.1.

Page 100: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

78 Chapter 4. Investigating the Usability of SMS-based Authentication

Figure 4.5: Authorising bank transactions via Email

Step � Description1 Present “New Transaction” Web page.2 Enter transaction information.3 Transmit transaction information.4 Generate authorisation code.5 Email trans. info and authorisation code.6 Transmit Confirmation Web page.7 Present Confirmation Web page.8 Verify received transaction information.9 Enter authorisation code/cancel transaction.10 Transmit authorisation code.11 Verify authorisation code.12 Transmit transaction confirmation13 Present transaction confirmation

Table 4.1: Virtual online bank scenario

4.5 Simulated Security Attacks

Transaction authorization with SMS messages has been introduced by online banksin response to various security attacks such as phishing and man-in-the-middleattacks. While technically elegant, it puts extra cognitive burden on users becausethey have to handle two devices, and relate information between them. In theexperiment, simulated attacks were executed during online bank transactions, andit was observed whether users were able to notice that they were being attacked.

To conduct the test, participants were asked to execute a number of financialtransactions. Some of those transactions were attacked by alteration of the des-

Page 101: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

4.5. Simulated Security Attacks 79

tination account. The destination account was altered after the participant hadsubmitted the initial transaction request. This resulted in an email containing thealtered transaction information together with authorization code being sent to theparticipant’s email address.

Two types of security attacks were implemented; the “obvious attack” whichwas easy to discover, and the “stealthy attack” which was difficult to discover.

• Obvious Attack TypeThe obvious attack was designed so that it would be easy for participantsto notice the alteration in the transaction details. This was done by alteringfive out of eight digits of the destination account number.

• Stealthy Attack TypeThe stealthy attack was designed such that it would be difficult for partic-ipants to notice the alteration in the transaction details. This was done byaltering only one digit in the destination account number.

By observing whether participants canceled the attacked transactions it couldbe determined whether participants noticed the obvious and the stealthy alter-ations to the destination account number.

4.5.1 Phase Shift of Attacks

To execute the security attacks equally over transactions, each participant wasassigned an attack phase in the following manner: Participant nr. 1 was assignedattack phase 1, participant nr. 2 was assigned attack phase 2, etc. until the tenthparticipant was assigned attack phase 10. Then participant nr. 11 was assignedattack phase 1 and so on.

Attack phases determined when the stealthy attack was going to occur. Forexample, if attack phase for a particular participant was 7, then the stealthyattack would occur on the seventh transaction for that particular participant. Theobvious attack occurs on a transaction number calculated by ((attack phase + 5)mod 10). For example, if a participant was assigned an attack phase 7, then theobvious attack would occur on his or her second transaction (i.e. (7 + 5) mod 10= 2).

Participants with attack phases 1-5 would face stealthy attack first while thosewith attack phases 6-10 would face obvious attack first. Table 4.2 shows whenboth types of attacks would occur for each attack phase.

Page 102: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

80 Chapter 4. Investigating the Usability of SMS-based Authentication

Phase Transaction # attackedshift Stealthy ObviousP.s. 1 #1 #6P.s. 2 #2 #7P.s. 3 #3 #8P.s. 4 #4 #9P.s. 5 #5 #10P.s. 6 #6 #1P.s. 7 #7 #2P.s. 8 #8 #3P.s. 9 #9 #4P.s.10 #10 #5

Table 4.2: Phase shift of attacks

4.6 Participant Demographics

The majority of participants in the experiment were staff and students at Queens-land University of Technology. The participant recruitment process was to senda participation invitation email to a certain distribution list and start receivingresponses from participants and collecting data. After a period when no new par-ticipants had been observed, another email to another distribution list was sentout and so on.

From the recruitment procedure that was followed, participants can be classi-fied into the following groups:

• QUT Participants

– 10 participants (11%) were PhD research students at Information Se-curity Institute (ISI).

– 5 participants (5%) were staff at the Faculty of Information Technology.

– 58 participants (64%) were undergraduate and master students at theFaculty of Information Technology.

– 5 participants (5%) were students at the Faculty of Education.

– 4 participants (4%) were researchers at Faculty of Law.

• Non-QUT Participants 10 non-QUT participants (11%) were contactedpersonally and none of them has a degree in Information Technology.

Page 103: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

4.7. Results 81

The actual number of people who responded to the invitation email andstarted working on the experiment was 116, but 24 participants were ex-cluded for different reasons:

– 3 participants with invalid email addresses.

– 12 participants executed few transactions without being attacked.

– 9 participants initiated transactions but never completed the confirma-tion process. It has been noticed that some email servers, like HOT-MAIL, directed the invitation email to a spam folder.

Figure 4.6 summarizes the participant demographics.

Figure 4.6: Participant Demographics

4.7 Results

As a result of the experiment, 92 participants executed a total of 734 transactions.When a participant interacted with the system, each transaction could be in oneof two states:

1. An initiated transaction which was a funds transfer transaction a participanthad started but not confirmed.

2. A complete transaction which was a financial transaction a participant hadstarted and confirmed.

Experiment transactions were classified into the following:

Page 104: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

82 Chapter 4. Investigating the Usability of SMS-based Authentication

• Normal transaction: This was a completed normal unaltered transaction.

• Incomplete or error transaction: This was a normal unaltered transactionthat participant initiated but did not complete.

• Successfully attacked transaction: This was a completed transaction wherethe participant failed to notice the altered destination account number.

• Unsuccessfully attacked transactions (avoided attack): This was an alteredtransaction that was canceled by the participant.

There were 557 normal transactions, 49 incomplete transactions and 128 attackedtransactions where 57 transactions were successfully attacked and 71 transactionswere unsuccessfully attacked. See Table 4.3, Table 4.4 and Figure 4.7.

Transaction type CountNormal 557Incomplete 49Successful attacks 57Avoided attacks 71Total 734

Table 4.3: Overview of recorded transactions

Attack type Avoided Successful TotalObvious 42 11 53Stealthy 29 46 75Total 71 57 128

Table 4.4: Overall attack response

4.7.1 Observations of Obvious Attacks

The total number of transactions attacked by the obvious attack was 53. Partici-pants were able to discover and cancel 42 attacked transactions of this type. Thismeans that participants were able to avoid 79% of the obvious attacks. Only 11out of 53 attacked transactions of this type were successful, which translated into21% successful obvious attacks. See Table 4.4 and Figure 4.7.

Page 105: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

4.7. Results 83

Figure 4.7: Overall attack response

4.7.2 Observations of Stealthy Attacks

The total number of transactions attacked by the stealthy attack was 75. Partici-pants were able to discover and cancel only 29 attacked transactions of this type.This means that participants were able to avoid 39% of the stealthy attacks. 46out 75 attacked transactions of this type were successful which translates into 61%successful stealthy attacks. See Table 4.4 and Figure 4.7.

4.7.3 Attack Phases and Attack Type

Some of the participants had been attacked first by obvious attack while othersfaced the stealthy attack first. It was found that the number of successful andavoided attacks varied depending on which type of attack occurred first.

With an obvious attack occurring first, the number of successful obvious attackwas 9 out of 32 while there were 17 out of 29 successful stealthy attacks. See Table4.5 and Figure 4.8.

Attack type Avoided Successful TotalObvious 23 9 32Stealthy 12 17 29Total 35 26 61

Table 4.5: Obvious attack first

Page 106: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

84 Chapter 4. Investigating the Usability of SMS-based Authentication

Figure 4.8: Obvious attack first

On the other hand, when stealthy attack occurred first the number of successfulstealthy attack was 29 out of 46 and the number of successful obvious attacks was2 out of 21. See Table 4.6 and Figure 4.9.

Attack type Avoided Successful TotalObvious 19 2 21Stealthy 17 29 46Total 36 31 67

Table 4.6: Stealthy attack first

4.8 Discussion

The observations show that a significant proportion of users are unable to detectthe attacks. As predicted, the obvious attacks were detected more frequently thanthe stealthy attacks. The detection rate of stealthy attacks depends to a certaindegree on whether it was preceded by an obvious attack or not.

An interesting observation is that attacks are avoided significantly more oftenwhen occurring late in the users experience with the online bank.

For example obvious attacks were avoided in 72% of cases when occurring beforestealthy attacks, and in 90% of the cases when occurring after stealthy attacks.

Similarly, stealthy attacks were avoided in 37% of the cases when occurring

Page 107: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

4.8. Discussion 85

Figure 4.9: Stealthy attack first

before obvious attacks, and in 41% of the cases when occurring after obviousattacks.

A possible explanation for this trend can be that users need to get a degreeof experience with the system before they become sufficiently alert to detect andavoid attacks. In other words, it is possible that the novelty of the system has theeffect of diverting peoples attention.

Realistic attacks may require alteration of about half the digits in the desti-nation account number, which translates into the obvious attacks. Therefore, thediscussion of security is based on the observed statistics of obvious attacks. Disre-garding the order in which obvious and stealthy attacks occurred, it is worrisometo observe that obvious attacks were successful in 21% of the cases in general.The conclusion to be drawn from this, which is also the main conclusion of theexperiment, is that this system is very insecure against attacks where the amountand destination account are changed in the authorization message. It is easy toimagine attack scenarios where this could happen.

Client Malware Attack Scenario

Attackers can send out spam email which invites users to access a website thatwill install a malicious program on users client computer. This malicious programwill observe activities on the client computer and get into action when the userstarts an online bank session. When the user specifies a funds transfer transaction,

Page 108: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

86 Chapter 4. Investigating the Usability of SMS-based Authentication

the program will alter the amount and destination account without displaying thealteration on the screen. The online bank will thus receive a transaction requestwith the false amount and destination account. Even when the transaction requiresauthorization via an SMS message, a significant percentage of users will fail tonotice that the transaction details have been altered.

Man-In-the-Middle Attack Scenario

It is possible for an attacker to intercept the communication between the customerand the bank server and impersonate them both. The attacker could trick the cus-tomer into logging into the attacker’s website, and masquerade as the real bank.This can for example happen through the attack commonly known as pharmingwhich is described in Section 2.6.2. With pharming attack, the browser will con-nect to the attacker’s server even though the customer manually types the correctdomain name of the bank.

By obtaining customer’s authentication details, the attacker can login to thelegitimate bank website and act as a man-in-the-middle between the customerand the online bank. When the customer sends a transfer transaction request tothe attacker website, the attacker can relay the similar altered transaction request(i.e. by changing the destination account number) to the real online bank. Uponreceiving the altered transaction request, the online bank will then send an SMSmessage containing the authorization code and the false transaction details to thecustomer. The observation shows that a considerable percentage of customers willnot notice the alteration and will complete the confirmation process by sending theauthorization code to the attacker; in this case, the attacker can relays the receivedauthorisation code to the bank which will execute the altered transaction. Theattack has succeeded!

4.8.1 Experimental Environment Considerations

When judging the results of the experiment it is worth considering that the envi-ronment for the experiment was not a real environment. An important question istherefore to what degree the conclusions from the experiment can be extrapolatedto real environments. It would have been practically impossible to conduct thisexperiment in a real environment, so the experimental environment was designedto be as close as possible to the real environment. Some of the differences, their

Page 109: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

4.8. Discussion 87

potential effects and the mitigation against them, were for example:

1. The group of participants might not be representative for average onlinebank user. A difference in security awareness and in the skill of using emailand SMS could have caused a bias in the statistical results. The majority ofparticipants were students and staff of QUT. It is probably correct to say thatthe participants had higher skill level and security awareness than the averageonline bank user. It is likely that this difference contributed significantly toa lower percentage of successful attacks that would have been the case witha representative group of participants.

2. Email messages were used instead of SMS messages. This could have affectedthe way participants would verify that the transaction details were correct.We judge email messages to be at least as easy to read as SMS messages,so this should not have affected in a negative way the ability of verifyingthe transaction details. We therefore believe that using email instead ofSMS could have caused a moderate reduction in the percentage of successfulattacks, at least not increase it.

3. The money was imaginary, not real. This could have affected the perceivedrisk of being attacked, and thereby the effort put into verifying the correct-ness of the transaction details. The instructions given to the participantsasked them to behave as if it was real money and take the same securityprecautions as for their real online bank. Still it is possible that reducedsecurity motivation could moderately have amplified the percentage of suc-cessful attacks.

Differences 1 and 2 could to a moderate or significant degree have contributedto a reduction in the percentage of successful attacks, while difference 3 couldin a moderate way have contributed to an increase. On the other hand, theHawthorn effect could compensate for any increase caused by difference 3. TheHawthorne effect [3] is a psychological phenomenon whereby human subjects im-prove or change their behaviour simply caused by their awareness of being studiedin experiments. The Hawthorne effect normally reduces the strength of conclusionsfrom experiments involving humans, but in this case it may paradoxically increasesthe strength of the conclusion because what is being investigated is the inabilityof participants to do the correct thing. In general, the experimental environment

Page 110: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

88 Chapter 4. Investigating the Usability of SMS-based Authentication

therefore probably did not cause an artificial increase in the number of success-ful attacks. The high percentage of successful attacks observed in the experimenttherefore gives a strong indication that the SMS transaction authorization methodis relatively vulnerable to the attacks that have been described.

4.9 Conclusion

The transaction authorization method based on SMS messages was introducedby banks in response to the now traditional phishing attacks, and this methodis indeed effective in stopping such attacks. Unfortunately, it is expected that itis only a matter of time before the attacks get more sophisticated, such as forexample through smart Trojans installed on the users client computers or throughMan-In-the-Middle attacks. In fact, advanced Trojan man-in-the-browser attackshave already started to emerge e.g. with the recent Zeus Trojan which has beenused to attack a number of online bank transactions in the UK and elsewhere in theworld. Online banks that have not implemented strong authentication solutionssuch as the SMS-based scheme could be defenseless against such attacks.

It is worth considering that from the point of view of the participants, thereis no risk attached with performing the experiment whereas there are real risksinvolved in conducting transactions through their online bank. Actually, it wouldbe impossible to create an environment with real risk so this was an unavoidablelimitation in the experiment. However, the study has given a strong indicationthat the SMS transaction authorization method is vulnerable to the attacks thathave been described. According to the observations users would be able to avoidonly about 79% of realistic attacks which means that 21% of realistic attacks wassuccessful. Based on the many millions of transactions that occur globally in adaily basis this is far too high from a trusted security position and represents aninadequate level of security for online banking. It is predicted that online bankswill need to develop improved methods for ensuring the security and integrity ofonline banking when such attacks start occurring.

The security problem caused by the failure to notice that transaction detailshave been altered has more to do with usability than with technical security.The experiment output assured what has been discussed earlier; if an identitymanagement system does not provide adequate usability with simple and intuitiveinterface it is highly possible that it will result in a system with inadequate security

Page 111: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

4.9. Conclusion 89

[161, 162, 160, 110, 137, 50].A possible solution should therefore be based on an improvement in usability,

and not necessarily on improving security mechanisms. In the next chapter apossible solution to the discovered security problem is proposed. The solution isbased on improving the usability of SMS-based authentication scheme in order tostrengthening its security.

Page 112: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

90 Chapter 4. Investigating the Usability of SMS-based Authentication

Page 113: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

Chapter 5

Strengthening SMS-basedAuthentication through Usability

5.1 Introduction

In Chapter 4 the usability of the SMS-based authentication scheme was examinedby investigating whether users are able to perform the extra tasks of verifyingthe details of each transaction in a satisfactory manner, and whether executingthese tasks does not introduce new security vulnerabilities. Banks would normallyassume that users are responsible for transactions authenticated with the autho-rization code. However, if a significant proportion of users are unable to use themethod correctly, this assumption would be unreasonable and should be reassessedby the banks.

According to the study observations users would be able to avoid only about79% of realistic attacks. Clearly, this represents an inadequate level of security foronline banking. The study also concluded that the failure to notice that transac-tion details have been altered has more to do with usability of security than withtechnical security. A possible solution should therefore be based on an improve-ment in usability, and not necessarily on improving security mechanisms.

Some banks use SMS-based authentication to authenticate only the first trans-action made to a new account but never authenticate subsequent transactions. Ofcourse, it is true that this mechanism will enhance the usability of the SMS-basedauthentication scheme by reducing the mental load caused by the repeated process

91

Page 114: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

92 Chapter 5. Strengthening SMS-based Authentication through Usability

of validating each transaction before confirming it however this action will weakenthe scheme by increasing attack possibilities. It is easy to imagine attack scenarioswhere this could happen as shown in the following two examples:

Trojan Attack Scenario

A possible scenario for an attack could happen when an attacker targets the victimby sending a spam message email with a genuinely good offer in order to attracthim/her to access the attacker’s website. The website will install a Trojan (e.g.the Zeus virus [55] or the Sinowal virus [14]) on the victim’s client computer whileselling him/her a product that requires a bank transaction. The attacker will thensend the product as expected to gain the victim’s trust and ask him/her to transferthe money to his account. In this manner, the victim will send the money to theattacker’s account by performing a transaction that will be authenticated by thebank and confirmed by the victim. The installed Trojan will observe activitieson the victim’s client computer and get into action when the victim starts anonline bank session. When the victim specifies a funds transfer transaction, theTrojan will alter the amount and change the destination account to the attacker’saccount without displaying the alteration on the screen. The online bank will thusreceive a transaction request with attacker’s account, (which has been alreadyauthenticated) as destination account and will execute the transaction withoutauthenticating it. The attack has succeeded.

Man-In-the-Middle Attack Scenario

It is also possible for the attacker, after an initial legitimate transaction withthe victim as described in the previous scenario, to intercept the communicationbetween the victim and the bank server and impersonate them both. The attackercould trick the victim into logging into the attacker’s website, and masquerade asthe real bank. Hence there is a double impersonation. The attacker impersonatesthe Bank so that the victim believes they are accessing the Bank’s legitimateWebsite. The attacker then impersonates the victim to the Bank.

As shown in Figure 5.1, by obtaining victim’s authentication details, the at-tacker can login to the legitimate bank website and act as a man-in-the-middlebetween the victim and the online bank. When the victim sends a transfer trans-action request to the attacker’s website, the attacker can relay the similar alteredtransaction request (i.e. by changing the destination account number to his ac-

Page 115: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

5.2. Improved SMS-Based Authentication scheme 93

count number) to the real online bank. Upon receiving the altered transactionrequest and since a previous legitimate transaction to the attacker’s account hasbeen authenticated, the online bank will execute the transaction without authen-ticating it. Again, the attack has succeeded.

Figure 5.1: Man-In-the-Middle Attack Scenario

To make the scheme more robust against attacks each transaction should beauthenticated, not just the first transaction. This chapter describes a methodfor improving the usability of typical SMS-based authentication schemes whichthereby will improve their overall security.

The chapter is organised as follows. Section 5.2 describes the new proposedscheme in detail and Section 5.3 presents analysis of the scheme. In Sections 5.4to 5.10, a description and analysis of an experiment to evaluate the practicality ofthe new scheme is presented. The chapter concludes in Section 5.11.

5.2 Improved SMS-Based Authentication scheme

To enhance the usability aspect of the scheme without compromising the strong au-thentication process of validating every transaction, a white list of trusted accountnumbers can be used to automate the validation process. The White Account List(WAL) is stored in the mobile phone and contains a number of financial accountsthe user has decided to trust. The basic idea of the new enhanced scheme is tocheck the account number in the SMS against the trusted account numbers storedin the WAL. So, when the user starts a transaction to an account and receives

Page 116: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

94 Chapter 5. Strengthening SMS-based Authentication through Usability

a confirmation SMS from the bank, an application checker on the mobile phonewill be activated to validate the transaction details. The checker will compare thereceived account number with the account numbers in the WAL. Upon comparisonresult, the mobile phone will either display a message indicating a trusted accountnumber or display a message informing the user that this is a new account number.

A blacklist called BAL (Black Account List) can be used to keep records ofdestination accounts that the user suspects as being malicious. The mobile phonewill use the BAL to capture any future transaction to these malicious accountnumbers and warn the user about the attack.

A third list called KAL (Known Account List) can also be used to register allaccount numbers that have been used as a destination account but have never beenadded either to the WAL or the BAL. The KAL is important in order to have ahistory of all decisions made by the phone. The logging of account usage shouldbe part of the phone functions to track errors when they occur.

The flowchart in Figure 5.2 describes the logical control flow of the addedenhancement to the scheme.

Figure 5.2: Auto-validation of transaction details

As illustrated in the flowchart, when the user starts a new transaction to anaccount and receives the confirmation SMS from the bank, the checker applicationon the mobile phone will be triggered to start the validation process of the trans-

Page 117: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

5.3. Analysis of the New Scheme 95

action. The checker will compare the account number in the SMS with the trustedaccount numbers in the WAL. If there is a match, the mobile phone will display amessage to indicate this match and show the account number and a name assignedto it; the mobile phone will then ask if the user wants to confirm the transactionby passing the authorization code to the PC terminal.

If the account number is not in the WAL, the checker will search for it in theBAL and if it is found, the checker will display a message to warn the user aboutthis malicious account and terminate.

If the account number is not blacklisted, the checker will look for it in the KALto check if it has been used before. One of two messages will be displayed:

• If the account number is found in the KAL, a message will inform the userabout a transaction to a previously used account.

• If the account number does not belong to the KAL, the checker will show amessage indicating a transfer to a new account.

In both cases, the checker will ask if the user wants to add this account numberto the WAL:

• If the user believes this is a trusted account and chooses to add it to the WAL,he/she will be asked to enter a name to be assigned to this new account anda record of the new account will be added to the WAL; the user will havethe choice to confirm the transaction.

• Alternatively, if the user decides not to trust the account number, he/she willhave the choice to add it to the BAL; if he/she chooses to add it to the BAL(i.e. the user believes this is an attack), the account number will be addedand the checker will terminate; otherwise if the user chooses not to add theaccount number to the BAL (i.e. the user believes the new account numberis correct but can not be trusted), the account number will be added to theKAL and the user will be asked if he/she wants to confirm the transaction.

By default, any account number will be added to the KAL unless the user decidesto insert it into WAL or BAL. Each account can only be in one list.

5.3 Analysis of the New Scheme

The security usability principles mentioned in Section 2.4.1 will be applied to thenew enhanced scheme in order to evaluate its usability.

Page 118: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

96 Chapter 5. Strengthening SMS-based Authentication through Usability

Using the new proposed SMS-based authentication scheme, the burden causedby the extra task of validating every transaction in a sufficient manner has beensimplified by the mobile phone. For the majority of transactions, the user will notneed to verify the correctness of the account number to validate the transaction,instead he/she will only need to glance at the output message resulting from theverification process executed via the mobile phone. The user will only need tocheck and validate the correctness of the account number when a transaction ismade to a new account and will never need to repeat the verification processfor any subsequent transaction. In this manner, the scheme usability is greatlyimproved where security usability principles 1d and 2d mentioned in Section 2.4.1are satisfied.

The design of the output messages resulting from the transaction validationprocess should enable the user to make conclusions about the authenticity andsecurity state of every transaction in a convenient way (i.e. security usabilityprinciples 2b and 2c). For example, when a transaction to a trusted accountis authenticated by the mobile phone, the output message will show the nameassigned by the user to the account and since the bank sends only the accountnumber in the SMS, when the user sees the account name, he/she can reliablyconclude that the transaction is going to the intended destination account. Also,the messages should be designed to give the user the practical ability to make thecorrect security action (i.e. security usability principles 1b and 1c). For example,the mobile phone should stop any account in the BAL to be used as a destinationaccount. Practically, this can be done by not showing the authorization code tothe user.

To enhance the usability even more the output messages should be formattedto have a simple and intuitive interface (i.e. security usability principles 2b and2c). Using colors, logos and/or special sounds can make messages more readable.

Authorizing a transaction requires a validation and a decision to be made bythe user. To analyze the new scheme’s security, all possible scenarios that couldoccur when a transaction is initiated by the user were tracked. Some simulatedsample screen shots will be used for illustrative purposes and to show the feasibilityof the new scheme usability.

Clearly, when the user starts a new transaction to an account and receives anSMS from the bank, there are two possibilities, either the account number will befound in one of the three lists or not. All cases related to the two possibilities will

Page 119: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

5.3. Analysis of the New Scheme 97

be discussed below:

Case 1 (Trusted Account):

If the mobile phone finds the account number in the WAL, a message similar tothe one illustrated in Figure 5.3 will be shown. The message will inform the userthat the account is trusted and will show the name assigned to the account as wellas the account number and transfer amount. Also, the message will ask if the userwants to confirm the transaction.

Figure 5.3: Simulated sample message

When the user sees that the destination account is trusted, he/she should alsocheck the name of the destination account. In case the name of the destinationaccount is the intended name, the user will click “YES” to confirm the transactionafter also verifying the amount. Alternatively, if the name of the destinationaccount is different from the intended name e.g. in error, the user will decline thetransaction by clicking “NO”. This should also prompt the user to investigate whatwent wrong, and possibly consider to move the specified destination account fromthe WAL to the BAL.

Case 2 (New or Not Trusted Account):

If the account number is not in the WAL, a message similar to the one illustrated inFigure 5.4.(a) or (b) will be shown. In the first message, the user will be advised

Page 120: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

98 Chapter 5. Strengthening SMS-based Authentication through Usability

that a transaction is initiated to a known account that has been used before;while the second message will inform the user that the transaction is initiated toa completely new account. Both messages will show the account number, urge theuser to verify it and ask if the user wants to add it to the white list (WAL).

Figure 5.4: Simulated sample message

From the two messages the user can conclude that the transaction is madeto an account that was not previously trusted and that he/she should verify thecorrectness of the account number.

If the user verifies that the account number is the intended one, he/she willeither click “YES” to add it to the WAL if he/she trusts the account or click “NO”if he/she does not and then can still confirm the transaction.

On the contrary, if the user finds that the account number is not the intendeddestination account, he/she must not choose to add it to the WAL and shouldclick “NO” where another message similar to the one illustrated in Figure 5.5 willbe shown. The new message will ask if the user wants to add the account numberto the black list of malicious accounts (BAL). If the user believes this is an attack(e.g. by a Trojan) he/she should click “YES” to add this malicious account to theBAL but if he/she believes that it was an error then he/she should click “NO” andof course should not confirm the transaction in both cases.

Note that when the user verifies that the account number is legitimate and theintended one but does not trust it and clicks “NO” choosing not to add it to the

Page 121: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

5.3. Analysis of the New Scheme 99

Figure 5.5: Simulated sample message

WAL (Figure 5.4.(a) and (b)), he/she will be shown the message in Figure 5.5where he/she also should not choose to add the account number to the BAL.

Using the new scheme described above, attack scenarios introduced in Section5.1 (Trojan Attack) and (Man-In-the-Middle Attack) will be detected and avoidedby the mobile phone.

The attacks are avoided since the user had the choice not to add the accountnumber of the attacker to the WAL during the first legitimate transaction; so, ifthe attacker forges any future transaction the message in Figure 5.3 will not beshown. Actually, the mobile phone will show a message similar to the one in Figure5.4.(a) which will cause the user to verify the transaction details and discover theattack.

Furthermore, assuming the user behaved insecurely and added the attacker’saccount number to the WAL during the first legitimate transaction, any futureattack from the same account will be detected since the message in Figure 5.3 -which will be displayed in this case- will show the name assigned to the attacker’saccount instead of the intended account name.

Case 3 (Malicious Account):

The new scheme provides a feature to detect previously captured malicious accountnumbers. If the account number in the received SMS is found in the BAL, themobile phone will show a message similar to the one illustrated in Figure 5.6 which

Page 122: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

100 Chapter 5. Strengthening SMS-based Authentication through Usability

will warn the user that a transaction to an earlier detected malicious account hasbeen found. Obviously, the only option provided to the user in this case is toterminate the transaction without confirming it. If the user insists to confirm thetransaction he/she will need to do an extra work by getting the authorization codefrom the SMS.

Finally, the user should be able to manage the three lists. Besides adding newrecords to the lists, the user should have the ability to delete and update existingrecords. For example, when a trusted account becomes no longer trusted the usershould be able to move it from the WAL to the KAL or BAL.

Figure 5.6: Simulated sample message

The security of the SMS-based authentication scheme is gained from the sepa-ration of the mobile phone from the user client terminal but this separation limitsthe scheme usability, which requires the user to manually copy the authorizationcode from the mobile phone to the client terminal in order to confirm each trans-action.

The usability can be improved by automating the copying process. This is canbe done by securely connecting the mobile phone to the client terminal withoutcompromising the scheme strength. The applications and data on the mobile phonemust be protected from unauthorized access. Attackers must not have the abilityto access the three lists (i.e. WAL, BAL and KAL) and the SMS sent by the bank.

Finally, in order to examine the performance of the new proposed scheme aninvestigation was needed. Such a study is potentially important because it will

Page 123: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

5.4. Experiment Design 101

determine whether the overall security of the SMS-based authentication schemeis improved when using the new system. The following sections describe an ex-periment to evaluate the usability of the proposed solution. The experiment wasdeveloped based on a similar design to the experiment illustrated in Chapter 4 butwith some variations to implement the new usability features.

5.4 Experiment Design

5.4.1 Objectives

The experiment aim was to examine the enhanced usability of the new proposedSMS-based authentication scheme. In other words, the purpose of the experimentwas to investigate whether minimizing the effort needed to validate each transac-tion sufficiently reduces new security vulnerabilities of the scheme currently in use.The experiment studied customer’s interaction with the new solution to the onlinebank that uses the SMS authorization code. As before participants were askedto act as customers and perform a number of financial transactions using the newsimulated virtual online bank. Their reaction to security attacks was observed andstudied.

5.4.2 Ethical Considerations

The experiment was conducted during August 2010 at QUT (Queensland Uni-versity of Technology) and involved human participation. The experiment wasreviewed and approved by the QUT Research Ethics Committee with approvalnumber 1000000463. There was a low risk associated with participation in theexperiment. As with the previous experiment, a web page with a consent formwas presented to participants before starting the experiment where they askedto click a button labeled “Participate” to confirm their agreement to participate.The participants’ email addresses were also required as part of the experiment andthey were notified that it would be kept confidential and would be deleted afterthe experiment is completed.

5.4.3 Participant Recruitment

The participants were recruited by sending out invitation emails. Permissions wereobtained to use several email distribution lists for sending out the invitations. The

Page 124: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

102 Chapter 5. Strengthening SMS-based Authentication through Usability

invitation emails were meant to be similar to the ones used in the experimentdescribed in Chapter 4 with additional information required for performing thenew tasks of the proposed scheme. The subject in the invitation email was thesame: “Invitation: Online banking security experiment”. The email body had thefollowing content:

The Information Security Institute at QUT is running an experimenton the usability of online banking security, and you are invited to par-ticipate. It will only take a few minutes. We would like you to transfervirtual money to different bank accounts imagining that you are us-ing your real bank account and money. We hope that you can makeat least 10 transactions. It is important that you take the same secu-rity precautions as you would with your real online bank account. Thismeans that you should cancel any transaction where you notice some-thing suspicious, because it could indicate a security attack. The listof bank accounts and amount to transfer is provided below. For eachtransaction, please do the following:

1. Start a new transaction by filling in the “New Transaction” webpage and clicking “Submit”. You will receive an authorization codeby email.

2. Fetch the email and verify that the transaction details are correct.

3. Confirm the transaction in case the details are correct. To con-firm, copy the authorization code from the email to the Web page,and click “Confirm”. Alternatively cancel the transaction if youthink there is something wrong. To cancel, simply click “Cancel”.

While using the system, you will be asked whether to add the accountnumbers with assigned names to a list of trusted accounts or not. Youmay also be asked to add an account number to a list of maliciousaccounts.

Please visit the URL below to start the experiment.

http://www.isi.qut.edu.au/people/alzomaim/bank/consent.htm

List of destination accounts to be used

Page 125: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

5.5. System Design 103

Assigned name: Destination accounts: Suggested amounts:(assigned name) (only these possible) (other amounts possible)Jane 30263142 $5000Ali 30263115 $500Lee 30263158 $5500Ali 30263115 $55000Sami 30263190 $50000Ali 30263115 $4400Lee 30263158 $44000Lee 30263158 $440Ali 30263115 $2205Jane 30263142 $400

We ask you to execute at least 10 transactions. Multiple transfers tothe same account are possible.

Thank you,Note: Approval from the QUT ethics committee has been obtained.Your email address will be kept confidential and will be deleted aftercompletion of the experiment.

Other participants were recruited by personal contact providing them with a hardcopy of a document identical to the above email.

5.5 System Design

A simulated online bank similar to the one described in Section 4.3 was developed.As before, participants were asked to execute a number of financial transactionswhere some of the transactions were corrupted to simulate attacks. It was alsodecided to base the authorization of transactions on email messages instead ofSMS messages for the same reasons mentioned in Section 4.3.

The developed web system which simulates a virtual online bank consists oftwo parts, the server front end that provides the http interface, and the serverback end that handles the database (see Figure 4.1).

Both the front end and the back end were implemented using PHP. The Bankdatabase at the back end was a relational database designed, implemented andaccessed using the MySQL relational database system.

Page 126: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

104 Chapter 5. Strengthening SMS-based Authentication through Usability

5.5.1 Server Front End

As described in Section 4.3.1, the server front end presented the interface andwas hosted on an Internet server at Queensland University of Technology. Theserver front end also consisted of two web pages entitled “New transaction webpage” and “Confirmation web page”. Both web pages are similar to the onesdescribed in Section 4.3.1 with the exception that the “Confirmation web page”gives participants the option to add an account number with assigned name to alist of trusted accounts or a list of malicious accounts.

5.5.2 Server Back End

The server back end is the core of the simulated online bank model where most ofthe functionality was executed. In addition to the functions described in Section4.3.2, the server was designed to do the following tasks:

• Manages three lists of accounts:

1. White Account List (WAN)

2. Known Account List (KAL)

3. Black Account List (BAL)

The participants have the choice to add the account numbers to any one ofthe three lists. The account number is added to KAL by default unless theparticipant chosen to add it either to WAL or BAL.

• Emails the authorization code and transaction information to the user emailaddress. The email message is sent in one of the following four formats:

1. A “NEW ACCOUNT” label with the transaction details and authoriza-tion code in addition to a message urging the participant to verify thetransaction details.

2. A “TRUSTED ACCOUNT” label highlighted in green color with thetransaction details, account name and authorization code. See Figure5.7

3. A “KNOWN ACCOUNT” label with the transaction details and autho-rization code in addition to a message urging the participant to verifythe transaction details.

Page 127: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

5.5. System Design 105

Figure 5.7: Email message of a trusted account

4. A “MALICIOUS ACCOUNT” label highlighted in red color with thetransaction details but without authorization code. See Figure 5.8

Figure 5.8: Email message of a malicious account

As with the previous experiment, all participants’ interactions with simulatedonline bank when executing financial transactions were stored in the bank MySQLrelational database.

Page 128: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

106 Chapter 5. Strengthening SMS-based Authentication through Usability

5.6 Participant Tasks

In the invitation emails instructions were provided to participants to complete anumber of bank transactions using the simulated online bank. For each transac-tion, participants had to carry out the following steps:

• Start a new transaction by filling the fields in the “New Transaction” webpage and then clicking the “Submit” button.

• Check the email sent by the virtual bank server to validate transaction in-formation and copy authorization code. The email message layout can beone of the four formats illustrated in Section 5.5.2.

• Complete the transaction by entering the authorization code in the “Con-firmation” web page and clicking the “Confirm” button then if asked theparticipant can choose to add the account number with a provided name tothe list of trusted accounts; otherwise the account number will be added toa list of known account.

• Alternatively, the participant can cancel the transaction by clicking the“Cancel” button. By default the account number will be added to the listof known accounts unless the participant chooses to add it to the list ofmalicious accounts when asked.

Participants are provided with a list of acceptable destination accounts withassigned names and suggested amounts to be transferred. Participants were re-quested to complete at least 10 transactions. The scenario of the experiment isillustrated in Figure 4.5 and Table 4.1.

5.7 Simulated Security Attacks

Simulated attacks were executed during online bank transactions. Some of thetransactions executed by participants were attacked by modification of the des-tination account. Consequentially, an email containing the altered transactiondetails together with authorization code was sent to the participant’s email ad-dress. Participants behavior was observed to determine whether they were able tonotice relevant attacks.

Page 129: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

5.8. Participant Demographics 107

The same two types of security attacks described in Section 4.5 were imple-mented; the “obvious attack” which was easy to notice, and the “stealthy attack”which was difficult to discover. Also the same attack phase to each participantwas followed as described in Section 4.5.1 to execute the security attacks equallyover transactions. By observing whether participants canceled the attacked trans-actions it could be determined whether participants noticed the obvious and thestealthy alterations to the destination account number.

5.8 Participant Demographics

The participants in the experiment were students at Queensland University ofTechnology. The same participants’ recruitment procedure illustrated in Section4.6 was followed. The participants can be classified into the following groups:

• 67 participants (83%) were undergraduate and master degree students at theFaculty of Science and Technology.

• 7 participants (9%) were PhD research students at Information Security In-stitute (ISI).

• 4 participants (5%) were PhD research students at Faculty of Law.

• 3 participants (4%) were students at the Faculty of Education.

The number of people responded to the experiment’s invitations and startedworking on the experiment was in fact 102, but 21 participants were excluded fordifferent reasons:

• 9 participants executed few transactions without being attacked.

• 8 participants initiated transactions but never completed the confirmationprocess.

• 4 participants with invalid email addresses.

Figure 5.9 summarizes the participant demographics.

Page 130: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

108 Chapter 5. Strengthening SMS-based Authentication through Usability

Figure 5.9: Participant Demographics

5.9 Results

As a result of the experiment, 81 participants executed a total of 643 transactions.When a participant interacted with the system, each transaction could be in oneof two states:

1. An initiated transaction which was a funds transfer transaction a participanthad started but not confirmed.

2. A complete transaction which was a financial transaction a participant hadstarted and confirmed.

The experiment transactions are classified into the following:

• Normal transaction: This was a completed normal unaltered transaction.

• Incomplete or error transaction: This was a normal unaltered transactionthat the participant initiated but did not complete.

• Successfully attacked transaction: This was a completed transaction wherethe participant failed to notice the altered destination account number.

• Unsuccessfully attacked transactions (avoided attack): This was an alteredtransaction that was canceled by the participant.

There were 492 normal transactions, 39 incomplete transactions and 112 at-tacked transactions where 14 transactions were successfully attacked and 98 trans-actions were unsuccessfully attacked. See Table 5.1, Table 5.2 and Figure 5.10.

Page 131: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

5.9. Results 109

Transaction type CountNormal 492Incomplete 39Successful attacks 14Avoided attacks 98Total 643

Table 5.1: Overview of recorded transactions

Attack type Avoided Successful TotalObvious 45 4 49Stealthy 53 10 63Total 98 14 112

Table 5.2: Overall attack response

Figure 5.10: Overall attack response

5.9.1 Observations of Obvious Attacks

The total number of transactions attacked by the obvious attack was 49. Partici-pants were able to discover and cancel 45 attacked transactions of this type. Thismeans that participants were able to avoid 92% of the obvious attacks. Only 4out of 49 attacked transactions of this type were successful, which translated into8% successful obvious attacks. See Table 5.2 and Figure 5.10.

Page 132: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

110 Chapter 5. Strengthening SMS-based Authentication through Usability

5.9.2 Observations of Stealthy Attacks

The total number of transactions attacked by the stealthy attack was 63. Partici-pants were able to discover and cancel only 53 attacked transactions of this type.This means that participants were able to avoid 87% of the stealthy attacks. 10out 63 attacked transactions of this type were successful which translates into 16%successful stealthy attacks. See Table 5.2 and Figure 5.10.

5.9.3 Attack Phases and Attack Type

Some of the participants had been attacked first by obvious attack while othersfaced the stealthy attack first. It was found that the number of successful andavoided attacks varied depending on which type of attack occurred first.

With obvious attack occurring first, the number of successful obvious attackswas 4 out of 28 while there was only one successful stealthy attack out of 26 attacks.See Table 5.3 and Figure 5.11.

Attack type Avoided Successful TotalObvious 24 4 28Stealthy 25 1 26Total 49 5 54

Table 5.3: Obvious attack first

Figure 5.11: Obvious attack first

On the other hand, when stealthy attack occurred first the number of successful

Page 133: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

5.10. Data Analysis 111

stealthy attacks was 9 out of 37 and there was no successful attacks out of 21obvious attacks. See Table 5.4 and Figure 5.12.

Attack type Avoided Successful TotalObvious 21 0 21Stealthy 28 9 37Total 49 9 58

Table 5.4: Stealthy attack first

Figure 5.12: Stealthy attack first

5.10 Data Analysis

The observations show a significant improvement for participants to detect theattacks when using the new simulated online bank system. Participants in thisexperiment were able to detect and avoid 92 % of obvious attacks as compared to79% in the previous experiment presented in Chapter 4. The significant improve-ment is actually observed with stealthy attacks. Participants in this experimentmanaged to detect and stop 87% of stealthy attacks while participants in theprevious experiment were able to discover and circumvent only 39%.

An attention-grabbing observation is that attacks are avoided significantly moreoften when occurring late in the users experience with the online bank.

For example obvious attacks were avoided in 86% of cases when occurringbefore stealthy attacks, and in 100% of the cases when occurring after stealthy

Page 134: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

112 Chapter 5. Strengthening SMS-based Authentication through Usability

attacks.Similarly, stealthy attacks were avoided in 75% of the cases when occurring

before obvious attacks, and in 96% of the cases when occurring after obviousattacks.

A possible explanation for this trend can be that the system begins to takeadvantage of the white list of trusted accounts which was built from previouslyexecuted transactions. In addition users need to get a degree of experience withthe system before they become sufficiently alert to detect and avoid attacks.

This expected improvement to the security of the SMS-based authenticationresulted from enhancing the scheme usability in which the process of verifying thedetails of each transaction adequately is simplified by the new system.

The experiment was conducted with the same experimental environment con-siderations of the first experiment as described in Section 4.8.1 and yet the ex-periment conclusion showed a security improvement as a result of the enhancedusability.

The study showed that the rate of successful attacks dramatically increasedwhen the validation of transaction details was done manually. The increased rateis evidently noticeable with the stealthy attack. This shows that as the numberof altered digits decreases the success rate of attacks increases. The validationprocess will even be more difficult with the trends to use the new internationalstandards for account numbers in which the account number can consist of morethan 20 digits.

In general this reflects a fundamental limitation in the user’s ability to reliablyverify long strings of characters; therefore, the validation process has to be auto-mated. The burden of the manual validation can be shifted to the mobile phone.The next chapter presents a proposed display security solution to the SMS-basedauthentication in which the user will never need to manually revalidate the correct-ness of the transaction details after they have been typed on the client terminal;instead the verification process can be executed by the mobile phone.

5.11 Conclusion

The transaction authentication method based on SMS messages was introducedby banks in response to the now common place phishing attacks, and this methodis indeed effective in impeding such attacks. The security of this scheme is based

Page 135: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

5.11. Conclusion 113

on the assumption that it is difficult for an attacker to control the user’s personalmobile phone and also that the user will verify the correctness of the destinationaccount number and transfer amount before confirming the transaction.

Obviously, while the mental load of verifying the correct amount and desti-nation account specified by the SMS message is probably acceptable for a singletransaction, the repeated process of verifying the same can be quite tedious leadingto user apathy.

This represents a usability difficulty which may lead to a security problem.Complicated and demanding authentication methods will always be misused orprobably bypassed by some users.

This chapter has described a practical solution aimed at improving securityof online bank SMS-based authentication by enhancing scheme usability. In thissolution the burden caused by the extra task of validating every transaction in asufficient manner has been simplified.

The mobile phone performs the verification process by keeping a record ofaccounts of previously executed transactions and categorising those accounts intotrusted or non trustworthy accounts. Most of the transactions are automaticallyverified by the mobile phone and the user needs only to glance at the outputmessage resulting from the verification process. The output message is formattedin a manner that eases and extends its readability.

The proposed solution was analysed and investigated through experimentationand the results show that the overall security of the SMS-based scheme was in factimproved.

For some transactions to new accounts that have never been transferred to be-fore, the user needs to verify them manually. In the next chapter, another solutionis proposed to automate the verification process of these remaining transactions.

Page 136: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

114 Chapter 5. Strengthening SMS-based Authentication through Usability

Page 137: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

Chapter 6

Display Security for OnlineTransactions

6.1 Introduction

Secure online transactions with human users normally require visual display forverifying the correctness of central elements of the transaction before it is submit-ted. When commodity computer platforms get exposed to the Internet, even fora short period, there is a real and substantial risk that they become infected withmalware that can modify anything on the computer, including what is displayedto the user and what is being sent over the Internet. This threat makes visual ver-ification of transaction data unreliable and undermines other security mechanismsused to protect online transactions.

Users generally rely on what they see on a computer display to read the outputof transactions, to verify that they type correctly, and to ensure that the databeing sent through online interface is according to their intentions. In general,all this depends on the integrity of the computing platform to which the VDU(Visual Display Unit) is connected. In practice it is extremely difficult to assessthe integrity of a general purpose computing platform, and thereby to ensure thatwhat the VDU displays is correct [11, 88, 89, 140, 149, 159].

The prospect that the computer display can lie to users is both frighteningand real. This problem is amplified by the fact that people often read data fromplatforms that are not under their control, and that there are financial incentives

115

Page 138: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

116 Chapter 6. Display Security for Online Transactions

for trying to manipulate the systems and the way data is displayed.

This chapter proposes a method for display security to make the verificationof displayed data in the SMS-based authentication scheme more robust againstthe threat of compromised platforms. It is a method for assuring the correctnessof displayed data in online transactions, i.e. to ensure that what is displayedon the VDU corresponds to what is being transmitted to other parties in onlinetransactions. It assumes that the user has a PDA (Personal Digital Assistant) withan integrated camera, OCR (Optical Character Recognition) and communicationfunctions. The method is based on using a portable PDA/camera (e.g. mobilephone) to capture the data from the VDU, recovering the data from the imagethrough OCR, and using an out-of-band channel for matching this data with thedata received by the transaction partner. In order to successfully falsify data byattacking the platform integrity, the attacker needs to have compromised both theclient platform and the PDA, which is more difficult than to only compromise oneof them. The proposal therefore provides a robust method for verifying displayeddata because it is considered harder to compromise both platforms.

The study in the previous chapter found that even with the enhanced usabilityof the new solution of SMS-based authentication, the stealthy attack was successfulin 16% of the attacked transactions. A high proportion of those attacks resultedfrom the manual validation of transactions details. The study also shows that asthe number of altered digits in the account number decreases the success rate ofattacks increases which reflects a limitation in the user’s ability to reliably verifylong strings of data.

The IBAN (International Bank Account Number) is an international standardfor identifying bank accounts aiming at minimizing the risk of propagating tran-scription errors. In some cases the IBAN can consist of up to 30 digits. Thevalidation process of the transaction details is expected to even be more difficultwith the trends to use the IBAN.

The SMS-based authentication scheme can be enhanced without compromisingthe strong authentication process of validating every transaction by automatingthe validation process. The basic idea is to shift the burden caused by the extratask of validating every transaction to the mobile phone. The user will never needto manually revalidate the correctness of the transaction details after they havebeen typed on the client terminal; instead the verification process can be executedby the mobile phone.

Page 139: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

6.2. The Cronto System 117

The rest of this chapter is outlined as follows. In Section 6.2, a system similarto the proposed solution in terms of using a camera to extract some kind of in-formation from a display screen is introduced. Section 6.3 describes the proposedsolution in detail. The section begins with a description of the system architectureand scenario followed by the practical aspects of the system. A security analysisof the system is presented in Section 6.3.3 and a usability analysis is introducedin Section 6.3.4. The system is discussed in Section 6.4 and then the chapterconcludes in Section 6.5.

6.2 The Cronto System

A system with a display security assurance concept developed by Cronto Lim-ited [101] already exist in the marketplace. Cronto system is based on displayingencrypted data rather than clear text data.

The Cronto system, which is based on research undertaken at the Universityof Cambridge, provides a transaction authentication solution for online bankingthat takes advantage of the camera in customers’ mobile phones. The Crontosolution is based on capturing a visual cryptogram sent by the online bank serverand extracting the transaction details from it [51].

The scheme starts when the customer initiates a new transaction with the on-line bank. Upon receiving the transaction request, a Cronto server-based softwaremodule in the online bank side takes the requested transaction details from thebanking application and generates a unique visual cryptogram challenge whichhides the transaction details and then passes the cryptogram to the customer forauthentication. The server then validates the client’s response and determineswhether the transaction should be authorized or not.

At the user side, the customer uses the camera of his/her mobile equipped withthe Cronto client software to capture the visual cryptogram provided by the bank,extract the transaction details from it, verify the transaction details and confirmthe transaction by entering a generated code into the client browser. See Figure6.1.

6.2.1 System Architecture

The system comprises an access terminal which can be a network connected com-puter, a remote authentication device such as a network server and a mobile device

Page 140: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

118 Chapter 6. Display Security for Online Transactions

Figure 6.1: Cronto security system

such as a mobile telephone or a Personal Digital Assistant (PDA).As shown in Figure 6.2, the user starts the authentication process in order

to initiate a specific transaction by entering his/her personal credentials such asa user name and a password into the access terminal (step 1). Next, the usercredentials are sent by the access terminal to the remote authentication devicethrough Internet channel (step 2) along with transaction details which the userwishes to perform.

Figure 6.2: Scenario for the Cronto security system

The remote authentication device then validates the user credentials. If theuser credentials are successfully validated, the remote authentication device thengenerates a message which is encrypted. The message may be partially based on arandomly generated code, such as a numeric code as well as transactional details.

Page 141: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

6.3. The Display Security Architecture 119

Adding transactional details provides a transaction integrity measure which aimsat protecting against attacks such as a “man-in-the middle” where attackers areprevented from modifying the content of the transaction without being detected.This is in contrast to a system relying only on dynamic passwords (e.g. One-TimePasswords) which do not carry any form of transaction details and are independentof the transaction.

The encrypted message is embedded into a cover image signal so that theoriginal signal and modified signal are perceptually indistinguishable. The en-crypted signal can be embedded into a cover image signal using any known formof steganography1 or digital watermarking [51].

The modified signal is then sent via Internet to the access terminal (step 3) andis displayed on its screen. The user then uses the camera on his/her mobile deviceto capture the image from the access terminal (step 4). An application installed onthe mobile device will process the image in order to extract the encrypted message.The extracted message is then decrypted and the generated code and transactiondetails are then displayed to the user (step 5). If the user verifies the transactiondetails and is satisfied with the correctness of the transaction, he/she may confirmthe transaction by entering the code into the access terminal (step 6). The codeis then sent to the remote authentication device for the purpose of comparing itto the code which was originally generated by the remote authentication device.If the two codes match, the transaction is successfully authenticated.

6.3 The Display Security Architecture

The main idea of the new enhanced scheme is to use a personal portable platformthat is able to convert a picture of the text-based representation of transactiontaken from the VDU into its character-based representation using OCR (OpticalCharacter Recognition) software. The conversion from picture to characters firstrequires the optical image emitted from the VDU to be captured by a digitalcamera. The bitmap representation of the image produced by the digital camerais then translated to a digital data representation by an OCR process.

To be more precise, the idea is to check the transaction data received throughe.g. an SMS message against the trusted transaction data extracted from the vi-

1Steganography is a form of security through obscurity science where a hidden message iswritten in a mode that no one other than the sender and recipient suspects its existence. Themessage may be concealed in forms such as images or text.

Page 142: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

120 Chapter 6. Display Security for Online Transactions

sual representation of a transaction data on the VDU. So, when the user starts atransaction involving a bank account and receives a confirmation SMS from thebank, a validation application on the PDA will be activated to validate the trans-action details. The validation application will compare the received transactiondata in the SMS against the data extracted from the photo. As a result of thecomparison, the PDA will either display a message confirming validity or displaya message warning the user about an invalid transaction data.

6.3.1 Scenario

The proposed scenario is a modified version of the SMS-based authenticationscheme illustrated in Figure 2.8 and Table 2.2 in Chapter 2. In the new sce-nario, steps 5 and 6 were substituted with the new steps 5, 6, 7, 8, 9, and 10 toallow the auto validation process of the transaction data. In the new steps, thePDA checks the transaction data received in the SMS against the transaction dataextracted from the analogue visual representation of the transaction data in thedisplay of the client platform. Also, the PDA will signal the success or failure ofthe comparison to the user who can then make a conclusion about the integrity ofthe transaction data.

As illustrated in Figure 6.3 where the numbered circles indicate the sequenceof messages and actions, the scenario is initiated when the user starts a new trans-action and enters the transaction details and at the same time inspects the entereddata displayed on the client’s VDU (steps 1 and 2). The transaction request andthe transaction data are then sent to the bank server (step 3). Upon receivingthe transaction request, the bank server will send the assumed transaction detailswith an authorization code to the user. The data will be sent as an SMS messageto the user’s mobile phone through the cellular network (step 4).

Figure 6.3: Scenario for the display security architecture

Page 143: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

6.3. The Display Security Architecture 121

� Message/Action description1. The user types and inspects the transaction data displayed on

the client VDU2. The user initiates the transaction from the client platform3. The transaction data are sent by the client to the server4. The assumed transaction data with authorization code are sent

as SMS from the server to the user’s mobile phone5. The user activates the camera function on the PDA6. A photo is taken of the text displayed on the VDU7. The OCR function in the PDA recovers the text from the photo8. The PDA compares the data from photo and from server9. The PDA signals the success/failure of the comparison

10. The user receives the signal from the PDA and can concludeabout the integrity of the displayed/transmitted transactiondata

Table 6.1: Messages and actions in the display security architecture

After receiving the SMS from the bank, the user will activate the mobile phone’scamera and capture the transaction details displayed on the client VDU (steps 5and 6). Next, an OCR function on the user’s mobile phone will convert the imageof the transaction data into a readable character format (step 7). The mobilephone will then compare the transaction details extracted from the image withthe transaction data in the received SMS message (step 8).

Finally, the mobile phone will either signal a successful match and presentthe authorization code to the user or display a warning message about a failurecomparison (step 9). At this point the user can make a conclusion about thesecurity and integrity of the displayed and transmitted data (step 10).

The scenario is illustrated in Figure 6.3 and summarized in Table 6.1.

6.3.2 Practical Aspects

Mobile phones commonly have integrated digital cameras, so they already havethe necessary functional basis for the proposed method. The inclusion of softwarefor the OCR and for comparing transaction data is all that is needed.

Commercial and open source OCR software packages are available. In itssimplest form, OCR software takes scanned documents and converts them into textfiles. More advanced graphical layout of digital documents will require a standard

Page 144: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

122 Chapter 6. Display Security for Online Transactions

for geometrically formatting documents so that the translation from graphicalbitmap format to digital character format is unambiguous.

With current technology, many mobile phones are equipped with OCR capa-bilities. An example of using one of the existing mobile phone’s OCR functionsto convert the data displayed on the client’s VDU to an editable text format isillustrated below.

Example: Image of transaction data to transaction text data

Figure 6.4 shows a screen shot of a sample transaction taken from a simulatedWeb page of a real bank (The commonwealth bank, Australia). It displays thetransaction details of a funds transfer to be transmitted to the online bank.

Figure 6.4: A screen shot of a transaction data

Figure 6.5 shows a snapshot photo of a simulated portion of the bank Webpage that shows the transaction details to be verified. The photo is taken by aniPhone 3GS mobile with OS version 3.1.2 and is equipped with an auto focus 3mega pixels camera [77].

The transaction details were shown in a browser default font size of the webpage with black font color and white background. The display unit was a 22" DellWidescreen LCD Monitor model no. 2208WFPt. The resolution was 1280 by 768pixels. The display brightness and contrast setting were %60. The person whotook the photo was setting on a chair in front of the display and was holding themobile phone camera in a straight angle to the centre of the display. The distancebetween the display and the mobile phone camera was about 20cm.

Page 145: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

6.3. The Display Security Architecture 123

Figure 6.5: A photo of a transaction data

Figure 6.6 shows the transaction text data resulting from applying an OCRfunction on the photo of Figure 6.5 executed by one of the iPhone’s OCR appli-cations called ocrNow! that converts images photographed on the iPhone camerainto text [80]. Many other mobile applications with built in OCR capabilities arealso available.

Figure 6.6: Text data resulting from converting a transaction image

Because taking a good photo of the visual display could easily become a non-trivial task, the integrity of the proposed solution was examined. Participants wereinvited to carry out the tasks of the practical example presented above. There were

Page 146: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

124 Chapter 6. Display Security for Online Transactions

24 participants who are categorized into four groups. The first group consists ofseven participants aged 20 to 30 years. The second group includes six participantsaged 31 to 40 years. The third group contains six participants as well but theywere aged 41 to 50 years. The last group comprises five participants aged 51 yearsand older; see Table 6.2 and Figure 6.7.

Group Age participantsG1 20-30 7G2 31-40 6G3 41-50 6G4 51+ 5

Total 24

Table 6.2: Participants groups

Figure 6.7: Participants groups

The experiment was conducted in two stages. In the first stage, each participantused an iPhone 3GS mobile phone camera and undertook five trials of the aboveexample. As a result, the total number of trials was 120 and the success rate ofconverting the transaction data from the graphical format to a valid text formatwas around 81% (97 out of 120). See Table 6.3 and Figure 6.8.

In the second stage, each participant was asked to repeat the trial five timesusing an iPhone 4 auto focus 5-megapixel still image camera [78]. The secondstage experiment resulted also in 120 trials where the success rate of convertingthe transaction data from the graphical format to a valid text format was around86% (103 out of 120). See Table 6.4 and Figure 6.9.

Page 147: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

6.3. The Display Security Architecture 125

Group Photos Success conv. % Failure conv. %G1 35 30 86 5 14G2 30 26 87 4 13G3 30 23 77 7 23G4 25 18 72 7 28

Total 120 97 23

Table 6.3: Results using iPhone 3GS camera

Figure 6.8: Results using iPhone 3GS camera

6.3.3 Security Analysis

The security of the proposed system requires that the client platform and the PDAare not both compromised concurrently. Assuming that the client platform andthe PDA have not both been compromised concurrently, it is possible to verifythat the PDA indeed provides the necessary elements for a robust transactiondata verification process.

Assuming that the client platform has been compromised; for example, aninterjected Man-in-the-Browser malware can alter the data between the user andthe web browser’s security mechanism in a completely surreptitious way. Whenthe user sends a transaction request to the online bank, the malware can modifythe transaction details and pass the altered transaction to the online bank withoutthe user’s knowledge. The online bank will receive the request with the alteredtransaction and cannot differentiate between the original transaction and the fakeone. The online bank then sends the fake transaction details as an SMS to theuser’s mobile. In this case the wrong transaction data is sent in message (3) and

Page 148: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

126 Chapter 6. Display Security for Online Transactions

Group Photos Success conv. % Failure conv. %G1 35 32 91 3 9G2 30 27 90 3 10G3 30 25 83 5 17G4 25 19 76 6 24

Total 120 103 17

Table 6.4: Results using iPhone 4 camera

Figure 6.9: Results using iPhone 4 camera

consequentially in message (4). However, the comparison between the receivedtransaction data in the SMS and the digital data converted from the image by thePDA in step (8) will fail, so that the PDA will signal that the transaction datahave been altered.

If the PDA is compromised alone, this will not affect the system security sincethe client platform will transmit the correct transaction data. However, it is pos-sible that the PDA generates a false alarm.

Considering now the possible consequence of a double compromise, i.e. thatthe client platform has been compromised so that it sends the wrong transactiondata to the server in (3), and that the PDA has been compromised so that itwrongfully validates the transaction data in step (9); in this case, the user willinstruct the client platform to confirm the altered transaction, so that the attackwill succeed.

It thus requires compromise of both the client platform and the PDA in orderto break the security of the proposed system.

The strength of the proposed system is based on minimizing attack possibilities

Page 149: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

6.3. The Display Security Architecture 127

and managing the risk. Attacks are reduced by separating the transaction valida-tion process (executed in the PDA) from the transaction creation and executionprocess which is performed in the client platform.

The advantage of the proposed method is that the visual comparison of trans-action data intended by the user and assumed by the server is automated, and thatthis validation process is separated from the client platform where the transactionis managed. Commodity client platforms are typically designed with priority onflexibility and functionality, which unavoidably results in security vulnerabilities.

The security property is based on using a digital camera which “sees” thetransaction data to be transmitted exactly as the user sees it. The bitmap imageis then converted to the character format using OCR techniques. This bridges thesemantic distance between the digital data in its binary form and the analoguevisualisation of the data that the user perceives. It basically guarantees that whatyou see is what you intend to transfer.

6.3.4 Usability Analysis

The usability of the proposed system is tested against the set of security usabilityprinciples defined in Section 2.4.1

In the SMS-based authentication scheme described in Section 2.12.1 the mentalload of repeatedly verifying several account numbers may violate principle 1d andrepresent a usability concern. As the experiment described in Chapter 4 showed,users were vulnerable to attacks due to this usability problem.

In the proposed system, usability is improved by delegating the account-numberverification task to the PDA. The user only has to interpret the result of thecomparison between the OCR generated file and the SMS received from the server.Clearly, this is an easier task to perform than comparing lengthy alpha-numericnumbers.

If the user performs repeated transactions which will require taking many snap-shots of the VDU, this may become a usability issue but to a lesser extent thanthe issue associated with the SMS-based transaction authorization scheme. Tak-ing several snapshots is less of a mental load than several comparisons of lengthyalpha-numeric numbers.

Usability can be enhanced by minimizing the number of transactions the userneeds to validate. As an example, a combined system of this proposed solutionand the scheme proposed in Chapter 5 can enhance the usability. As described in

Page 150: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

128 Chapter 6. Display Security for Online Transactions

Chapter 5, the scheme works by maintaining several lists of accounts in the mobilephone generated from previous transactions. The PDA would look into these listsfirst for comparison with the server’s SMS before looking for a new OCR file. Asthe user continues to use the system, this can significantly reduce the number ofsnapshots a user needs to take and will not undermine the concept of verifyingtransaction data on an individual basis as every transaction data is checked by thePDA either against the trusted accounts list (which is separate and independentfrom the client terminal) or by a new OCR. The combined system of the twoproposed solutions is illustrated below:

1. The user types and inspects the transaction data displayed on the clientVDU.

2. The user initiates the transaction from the client platform.

3. The transaction data are sent by the client to the server.

4. The assumed transaction data with an authorization code are sent as anSMS from the server to the user’s mobile phone.

5. The mobile phone checks the account number in the SMS against the accountlists.

If the account number is found in the trusted list, the mobile phone:

• Signals a message of a trusted account, and

• Shows the transaction details and the authorization code.

If the account is not in the trusted list, it will be searched in the maliciousaccounts list; if the account is found, the mobile phone:

• Signals a warning message, and

• Shows the transaction data without the authorization code.

If the account number is not in the two lists:

• The user activates the camera function on the mobile phone.

• A photo of the text displayed on the VDU is taken.

• The OCR function in the mobile phone recovers the ASCII text fromthe photo.

Page 151: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

6.4. Discussion 129

• The mobile phone compares the data from the photo and from theserver.

• The mobile phone signals the success/failure of the comparison andshows the transaction data and the authorization code.

6. The user receives one of the above signals from the mobile phone and candraw a conclusion about the integrity of the displayed/transmitted transac-tion data.

7. The user either confirms or cancels the transaction and if asked, may addthe account number to either the trusted or malicious list.

6.4 Discussion

The practicality of the proposed solution depends extensively on the capabilityof the mobile phone scale camera to take good images of the transaction datadisplayed in the client VDU as well as the integrity of the OCR system thatconverts these images into text format.

The successful rate of converting the transaction data from the graphical formatto a valid text format was around 86% when using iPhone 4 mobile phone camera.This indicates that about one out of seven attempts to take a snapshot of thetransaction details displayed in the client VDU will result in an image that willnot convert to a valid transaction data text. However, with advancing technology,it is expected that the successful conversion rate will continue to increase. As anexample, the successful conversion rate increased from 81% to 86% after switchingfrom iPhne 3GS to iPhone 4 camera which can take more quality photos.

In addition to the camera capabilities, the photo quality is also affected byother factors related to the photo source and the person who takes the photo. Thephoto source is the transaction data displayed on the client’s VDU. Factors suchas the VDU’s brightness, screen background and font size of the transaction datacan impact the photo quality. The factors related to the user who takes the photomay include the manner in which the user holds the camera and the angle anddistance between the camera and the VDU. The experiment described in Section6.3.2 gave indication that the age of the user who takes the photo may also havean effect on the photo quality.

Page 152: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

130 Chapter 6. Display Security for Online Transactions

The Cronto system described in Section 6.2 requires that both parties involvedin the authentication process (i.e. the costumer and bank server) be equipped withproprietary cryptographic tools in order for the system to work. In contrast tothe Cronto system, the proposed solution enhances the SMS-based authenticationwithout the use of additional cryptography and can be applied directly at thecostumer side without making any changes at the server side.

The security of Cronto system relies on the client platform not being com-promised. If an attacker accesses the encrypted transaction data in the clientplatform, Cronto system will fail. On the other hand, the security of the proposedmethod only depends on either the client platform or the PDA being secure. Infact, one of them can be compromised without causing a risk of tricking the userinto confirming online transactions to the fake accounts, so the security of the pro-posed method is independent of the security of the client platform. The PDA canbe designed with priority on security, and with limited functionality and flexibility.The PDA is controlled by the user, so he does not have to rely on systems outsidehis control when conducting financial transactions. This feature will allow mobil-ity where users can apply the new method to any system anywhere as long as thesystem is able to connect to the online bank and execute financial transactions.

From a usability perspective, the user of Cronto system will still need to man-ually verify the transaction details in the user device and the client platform. Theverification may involve a comparison of long strings of characters. The studiesin chapters 4 and 5 show that as the number of altered digits in the attackedaccount number decreases the success rate of attacks increases. This reflects alimitation in the user’s ability to reliably verify long strings of characters. Usingthe proposed solution however, the length of the account number has no effect onthe verification process; no matter how long or short the account number is, themobile phone verifies it automatically.

6.5 Conclusion

People usually rely on what they see on a computer display to ensure that thedata being sent through online transactions is consistent with their intentions.Generally, this depends on the integrity of the computing platform to which theVDU (Visual Display Unit) is connected. Practically, ensuring platform integrityis very difficult. To date, it is almost impossible to validate the integrity of a

Page 153: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

6.5. Conclusion 131

general purpose computing platform, and thereby to ensure that what the VDUdisplays is correct. The validation task is difficult because people regularly readdata from platforms that are not under their control and because of the complexityof general purpose computing platforms.

Secure online transactions with human users require visual display for verifyingthe correctness of the transaction details before submission. When executing onlinetransactions, there is a real risk that computer platforms become infected withmalicious software that can alter what is displayed to the user and what is beingsent online. This threat makes visual verification of transaction data unreliableand weakens other security mechanisms used to protect online transactions.

In this chapter a new solution aimed at improving the overall security of onlinetransactions by providing display security has been proposed. This removes thecognitive burden of e.g. manually validating every transaction by visual compari-son of transaction data in SMS-based authentication schemes.

Current display security technologies are not able to provide high assuranceof the integrity of displayed data. This chapter has shown that it is possibleto make the security of displayed data independent of the security of the clientplatform. This is achieved by using a mobile phone equipped with a camera inparallel with the client platform when executing online transactions. The displaysecurity is based on using a digital camera which “sees” the displayed transactiondata exactly as the user sees it. The bitmap image of the transaction data isthen converted back to the original digital form using OCR techniques, so thatthe displayed transaction data can be automatically compared with those receivedthrough SMS from the bank.

The security of the proposed solution is gained from the fact that it wouldrequire compromise of both the client platform and the PDA in order to break thesecurity of the proposed system. The solution’s strength is based on minimizingattack possibilities by separating the transaction validation process, which is exe-cuted in the PDA, from the transaction execution process which is performed inthe client platform.

This chapter as well as the previous two chapters investigated SMS-based trans-action authentication and illustrated two proposed solutions to enhance the schemeusability. The next chapter discusses the token-based authentication and describesa proposed solution to strengthen the scheme by improving its usability.

Page 154: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

132 Chapter 6. Display Security for Online Transactions

Page 155: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

Chapter 7

A Robust Scalable Token-basedAuthentication Solution

7.1 Introduction

The widespread adoption of the Internet has benefited people by delivering servicesat a level of ease and speed never experienced before. However, the growth ofonline services has also led to one major problem: as the number of online servicesincreases the number of different digital identities each user holds increases as well.As a result, many people feel overloaded with credentials, which in turn negativelyimpacts their ability to manage them securely.

Passwords are the most common type of credential used for accessing onlineservices today. The traditional requirements which dictate that passwords shallbe difficult to guess and be different for different online services put a considerablemental burden on users. With such burden, it is obvious that users may sufferfrom identity overload and password fatigue. As described earlier in Chapter 2,various studies [111] show that people use heuristic strategies to reduce the mentalload. Unfortunately, these strategies also make passwords vulnerable to attack.As an example, users often behave less securely by using low entropy and weakpasswords. A common strategy involves reusing few passwords for all the servicesa user accesses. This means that the number of passwords is constant while thenumber of services increases. Users may also reserve a single password for serviceswith the highest risk.

133

Page 156: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

134 Chapter 7. A Robust Scalable Token-based Authentication Solution

Weak passwords and bad password habits are serious security risks that threatenonline services. This threat makes systems vulnerable to all variants of passwordattacks.

Special password management methods have been developed to protect againstbad password habits. Some of those solutions have been developed to eliminatethe need for users to create and manage passwords. A typical solution is basedon giving the user a special hardware token that generates OTPs. An OTP is 6to 8 alphanumeric password that is used only once for user authentication or forthe user to authorize a transaction. By effectively eliminating the need for usersto create and manage passwords, these solutions consequently reduce passwordattacks.

As was noted in Chapter 2, there are two types of OTP generator tokens,hardware tokens and software tokens. A hardware token is a dedicated passwordgenerator device with an LCD screen which displays a passcode consisting of 6 ormore alphanumeric digits. Software tokens are password generating functions thatare stored on a general-purpose device such as a desktop PC or a PDA.

Generally, hardware tokens are considered to be more secure than software to-kens due to the vulnerable state of software on general purpose computers. How-ever, hardware tokens have usability problem. The number of hardware tokensneeded by one user may increase causing inconvenience for the user to managethem; see Figure 7.1. Software tokens can eliminate the need for separate tokendevice for each service provider.

Software tokens are usually based on shared secret keys. An administrator willnormally create and then allocate a shared secret key for each user. The sharedsecret key is seeded to the software token to generate unique series of OTPs.

The confidentiality and uniqueness of the shared key gives every token its in-dividuality. The shared secret key should always be under the service providercontrol and beyond the user control. Rather than other entities such as applica-tions, the user of the token should not even have access to the shared secret key;see Section 2.12.2.

Unfortunately, most of the existing OTP token-based solutions do not sat-isfy scalability and/or usability requirements, or they are simply insecure. Theprevious two chapters described proposed solutions to strengthen the SMS-basedauthentication through improving the scheme usability. In this chapter, a scalableOTP solution using mobile phones and based on trusted computing technology

Page 157: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

7.2. OTP Token Using Trusted Computing 135

Figure 7.1: Many tokens for a single user

is proposed. The solution combines enhanced usability of software tokens withstrong physical security of hardware tokens. Many industry players are planningto include trusted computing technology in the coming generation of devices suchas mobile phones and PDAs where TPM’s functions could be employed. Trustedcomputing can provide strong physical protection to the sensitive data such asshared secret keys. Mobile phone tokens can reduce costs and eliminate the needfor carrying separate hardware token for each service provider; see Figure 7.2.

This chapter is organised as follows. Section 7.2 describes the proposed OTPtoken-based solution. The section begins by introducing the new solution and thenillustrating the scheme architecture in depth. A detailed security analysis of thenew solution is given in Section 7.3. In Section 7.4 the solution is discussed. Thechapter concludes in Section 7.5.

7.2 OTP Token Using Trusted Computing

The basic idea of the OTP authentication scheme is that a user device (such asan OTP token) uses a mechanism to authenticate the user to the service providerby sending the user’s credentials and then connect to the service provider’s server.The service provider grants access to its services by verifying the OTP credential.The user device can be configured to facilitate the generation and management ofthe OTP credentials. The user side and the service provider side can be configuredto use the same function to generate the exact series of OTPs. In this manner,

Page 158: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

136 Chapter 7. A Robust Scalable Token-based Authentication Solution

Figure 7.2: One token for a single user

as the two functions at both sides are fed with the same inputs, both sides willgenerate the same output.

Upon receiving the expected OTP from the user, the service provider can verifythe authenticity of the user and may then grant him access to its services. Thisis done by comparing the OTP generated by the verification server on the serviceprovider side with the OTP received from the user. For practical reasons, thecomparison is often done against a window of expected (and unused) OTP values.Figure 7.3 illustrates an example scenario of an OTP token-based authenticationscheme which uses an OTP in addition to a user-id and a constant password fora two-factor authentication, i.e. the claimant user controls the token device andknows the password at the same time. The scenario is described in Table 7.1.

The security of the OTP authentication scheme is based on the properties that1) each OTP has high entropy, and 2) each OTP can only be used once. Thismeans that OTPs can not be guessed in advance, and an intercepted OTP isworthless to an attacker once it has been used. OTP schemes can be used for userauthentication or to authorize specific transactions initiated by the user.

The service provider verifies the OTPs sent by different users by keeping arecord of the algorithm and related parameters for each user.

In typical implementations, the OTP function is actually a hash-based algo-rithm that uses specific parameters such as a seed value, a key, a time value and/ora counter to generate the OTP series.

The proposed solution suggests using a mobile phone as a user device to au-

Page 159: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

7.2. OTP Token Using Trusted Computing 137

Figure 7.3: Token-based authentication scenario

� Message/Action description1. The user requests access to the online bank website and enter

the login user-id and password2. The login request and user’s credentials are transmitted to the

bank server3. The online bank verifies the user’s login credentials4. A request for a new OTP is transmitted to the user5. The bank’s OTP request is presented to the user6. The user generates a new OTP using his token7. The user types the new OTP in the login page8. The user’s OTP is transmitted9. The bank verifies the user’s OTP and transmits the service op-

tions if authenticated

Table 7.1: Messages in the token-based authentication scenario

thenticate the user to the service provider. The phone is equipped with an MLTMmanufactured to satisfy the specifications of the Trusted Computing Group; seeSection 2.13.3. The MLTM is used as a secure processor to generate OTPs.

The MLTM can provide secure processing functionality to generate the OTPs.Having this capability, the MLTM can perform the OTP operations within its se-cure boundary. Also, the MLTM cryptographic functionality can provide physicalprotection of the sensitive parameters needed to generate the OTPs. The param-eters (e.g. shared secret key) can be securely stored outside the boundary of theMLTM in the external memory in such a way that it is only accessible under thecontrol of the MLTM. In other words, the OTP related parameters can be bound tothe MLTM where only the MLTM can unbind them. Given this, when the MLTMneeds to generate an OTP, it will load the required bound parameter data frommemory, unbind it and then seed it to the OTP generation function (i.e. hash

Page 160: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

138 Chapter 7. A Robust Scalable Token-based Authentication Solution

function) within its secure boundary. The MLTM only outputs the data whichwill be converted to an OTP and does not release any OTP related parameters.This proposed solution will strengthen the OTP scheme by taking the securitylevel down to the hardware and combining it with software to make the process ofgenerating OTPs highly secure.

In order to securely generate the same sequence of OTPs, the MLTM and theservice provider should generate and maintain a shared secret key to be fed to theOTP algorithms at both sides.

The OTP algorithm supported by the MLTM is actually an HMAC (e.g.,HMAC-SHA-1) function [28, 62]. In the proposed solution, the parameters that arefed to the SHA-1 function to generate the OTP are the shared secret key and eithera counter (for transaction-based method) or time value (for time-based method).In the transaction-based method, the MLTM and the service provider incrementthe counter every time they generate a new OTP while in the time-based methodthe clocks in both sides should be synchronized.

Finally, before the device can display the generated OTP to a user, it needs tobe truncated and converted to human readable form.

7.2.1 Architecture Description

Assume that User-A has a business relationship with service provider SP-i. User-Aneeds to use their MLTM equipped mobile phone as an OTP token. To implementthis, a special middleware application (referred to henceforth as “OTP Generator”)can be installed on the user mobile phone. The OTP Generator consists of twoparts: the OTP token configuration and OTP generation. The first part is neededto initialize and configure the OTP token by managing the secure exchange of theshared secret key between the user’s mobile phone and SP-i in addition to thesecure storage of the shared secret key on the mobile phone. The OTP generationpart handles the process of generating the OTPs. Both parts are explained inmore detail below.

The key management part is processed only once at the beginning when con-figuring the OTP token while the OTP generation is executed every time a newOTP is needed.

A user can configure their mobile phone as a multi OTP generator token byrequesting the service from the service provider. For example, the user can call theservice provider or login to their account with the service provider to request the

Page 161: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

7.2. OTP Token Using Trusted Computing 139

service (similar to the way of ordering physical OTP tokens currently used by somebank customers), the service provider may then send a CD containing the OTPGenerator software to the user through the normal mail or the user may downloadthe application from the service provider’s website. The user then installs the OTPGenerator on their mobile phone.

7.2.1.1 OTP Token Configuration

The security of the proposed scheme rests on the trust established between SP-iand the MLTM equipped mobile phone. The trust will be assured if the sharedsecret key - which will be seeded to the OTP function - is created, encrypted andsubmitted to the intended mobile by SP-i in a way that guarantees that the keycan not be tampered with, and will only be used by the mobile’s MLTM of theintended user.

To establish a new shared secret key SKi-A, the steps (indicated by numberedcircles) illustrated in Figure 7.4 are required. The user first requests the sharedsecret key from SP-i (step1), then uses the OTP Generator to instruct the MLTMto generate a non-migratable binding key pair (Kpu-A, Kpr-A) (e.g. using thecommand TPM_CreateWrapKey) and obtains the resulting public key (e.g. usingthe command TPM_GetPubKey) (step 4). Steps 2 and 3 will be discussed later.

Figure 7.4: OTP Token Configuration

The public key Kpu-A will be then sent to SP-i to use it to encrypt SKi-A soonly the MLTM, where Kpr-A exists, can decrypt it. However, if Kpu-A alone is

Page 162: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

140 Chapter 7. A Robust Scalable Token-based Authentication Solution

sent to SP-i there is no way for SP-i to validate that it has indeed came fromthe intended genuine MLTM. The mobile phone, where the shared secret key isintended to be migrated to, must be first identified to SP-i. The identificationprocess involves two parts:

I. validating that the MLTM which generated Kpu-A is genuine.

II. verifying that the mobile phone, where the MLTM is installed, belongs tothe intended user (i.e. user-A).

The first identification part is the validation that the MLTM which generatedKpu-A is genuine. To achieve this, Kpu-A is sent to SP-i with the required certificateto validate it. This is where Kpu-A is signed. The user could be required to obtaina hash of Kpu-A and then sign it (e.g. using the command TPM_CertifyKey)with an AIK. The signed public key (Kpu-A) with its certificate can then be sentelectronically to SP-i (part of step 5) which can verify that the key has beengenerated by a genuine MLTM.

SP-i performs the validation, using the same certificate path-validation processdescribed in Section 2.13, before sending the shared secret key to the user. SP-ihas access to the certificate associated with the MLTM’s identity key though athird party certification authority. Consequently, SP-i can be assured that Kpu-Abelongs to a trusted MLTM and can then send the shared secret key to it.

The second part is the authentication of the user in which SP-i needs to knowthe identity of User-A who owns the mobile phone where the specific MLTM isinstalled. That will be achieved by the following tasks:

a. When receiving a request for a shared secret key, the SP-i’s server will gen-erate a nonce Na (step 2) and SP-i will send it to the user’s mobile phone asan SMS through the cellular network (an out of band channel (step 3)).

b. The OTP Generator on the user mobile phone will then generate a hashvalue of both the public key (Kpu-A) and the received Na (i.e. public keyand Na being the input to the hash function) and then send the hash valuetogether with Kpu-A certificate to SP-i through the Internet channel. (step5)

c. Upon receiving the data, SP-i will authenticate the user by generating a hashof Na and the received public key (Kpu-A) and verifying that the generatedhash value and the received hash value are equal.

Page 163: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

7.2. OTP Token Using Trusted Computing 141

The cryptographic association between the common secret Na (i.e. known onlyto SP-i and User-A) and Kpu-A enables SP-i to know the identity of the customerwho sends Kpu-A.

The Man-In-The-Browser attack will be avoided because of the assumptionthat it is difficult for the attacker to obtain Na. The Cellular network is used toexchange the value Na and the hash function is irreversible which means that theattacker can not get Na out of the hash value. The attack is avoided because theattacker can not regenerate another hash value of Na and his public key. Thisallows the user to prove to SP-i his knowledge of the common secret (i.e. Na)without revealing it. Na should be long enough to avoid an attacker who triesall hashes of possible Na values and the Kpu-A to match the hash sent to SP-i instep 5. However, the risk of obtaining Na is low because the number of guessesin a time period (i.e. the time of requesting SKi-A which can be instant) can becontrolled.

Sending the hash value and the certificate (including public key) to SP-i couldbe done, for example, by the user logging in normally to their account with SP-i and uploading the data. An example of an XML file generated by an InfineonTPM Security Platform which identifies the computer platform where the InfineonTPM is installed is illustrated in Figure 7.5.

At the SP-i side, Kpu-A will be subsequently used to associate the shared se-cret key to the user’s mobile phone. Practically, this process is implemented bybinding the shared secret key to the MLTM of the user’s mobile phone by thenon-migratable binding public key Kpu-A. When SKi-A is bound by the pub-lic key (Kpu-A) to the MLTM of the user’s mobile phone, only the private key(Kpr-A) which is protected by the MLTM of the mobile phone, can unbind it.The encrypted shared secret key EKpu_A(SKi-A) together with an initial counter(Counti-A) value will then be sent to the user’s mobile phone (step 7). Again, toavoid the Man-In-The-Browser attack, a hash value of EKpu_A(SKi-A), Counti-Aand Na will be sent to the user.

At the user side, EKpu_A(SKi-A) and Counti-A can be stored in the mobilephone’s external memory. When OTP generation is needed, the OTP Generatorinstructs the MLTM to unbind the stored value EKpu_A(SKi-A) to get the sharedsecret key. To do this, the private key Kpr-A corresponding to the public keyKpu-A that was used to encrypt the shared secret key must first be loaded into themobile phone’s MLTM (e.g. using the command TPM_LoadKey) and then decrypt

Page 164: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

142 Chapter 7. A Robust Scalable Token-based Authentication Solution

Figure 7.5: A sample of an XML file identifying the computer where the InfineonTPM is installed

the value EKpu_A(SKi-A) (e.g. using the command TPM_Unbind). The decryptionwill be executed entirely on board the MLTM and within its secure boundaries.The OTP Generator is now ready for operation to generate OTPs.

The steps of Figure 7.4 are summarized in sequential order below:

1. User-A, known by SP-i requests a shared secret key SKi-A.

2. A nonce Na is generated by the SP-i’s server.

3. SP-i sends Na as an SMS to User-A.

4. The OTP Generator uses the MLTM to generate a non-migratable bindingRSA key pair (Kpu-A, Kpr-A).

5. The public key Kpu-A is certified by the MLTM under an AIK. The OTPGenerator sends the public key certificate (including Kpu-A) to the SP-i’s

Page 165: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

7.2. OTP Token Using Trusted Computing 143

server. Also, the OTP Generator generates a hash of Kpu-A and Na andsends the hash value to the SP-i’s server.

6. The SP-i’s server:

(a) generates a hash value of Na and the received Kpu-A,

(b) verifies that the received hash and the generated hash are equal in orderto authenticate the user,

(c) validates that the MLTM is genuine using the received certificate and

(d) generates the shared secret key SKi-A.

7. The server sends SKi-A encrypted with Kpu-A, Counti-A and a hash of bothvalues and Na to the user mobile phone.

8. The OTP Generator stores Counti-A and the value EKpu_A(SKi-A) in themobile phone securely and uses the MLTM to decrypt it when needed.

This procedure enhances the system security by creating a root of trust wherethe service provider (e.g. a bank) can ensure that only the mobile phone of theintended user can access the sensitive shared secret key.

The procedure described above can be repeated for an arbitrary number of ser-vice providers. This turns the mobile phone into a general purpose OTP generatortoken. The user will no longer need to carry separate hardware tokens for differentservice providers. The OTP tokens can be virtualized and loaded into the samehardware device.

7.2.1.2 OTP Generation

As discussed earlier, the proposed OTP function to generate the OTPs is the SHA-1 function implemented by the MLTM. Also, two main classes of OTP generationmethods were introduced. The first is the transaction-based where a new passwordis generated every time the user sends an OTP to SP-i. This method is based ona counter that requires synchronization between User-A and SP-i. The secondclass is the time-based where a new OTP is generated at specific time or timeintervals. This method also requires synchronization of timing in the user side andSP-i side. The OTP generation is based on multiple inputs. The transaction-basedmethod which uses a counter and a shared secret key, as illustrated in Figure 7.6 is

Page 166: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

144 Chapter 7. A Robust Scalable Token-based Authentication Solution

Figure 7.6: Input parameters to the OTP generation function

suggested to be used. This will provide strong security against attempts to imitatethe OTP function by attackers.

For this to work, the key needed to unbind the shared secret key (i.e. Kpr-A)must be first loaded to the MLTM. The MLTM will then use the loaded keyto unbind the shared secret key to obtain SKi-A . SKi-A and other parameterswill be fed to the SHA-1 function (e.g. using the commands TPM-SHA1Start,TPM-SHA1Update and TPM-SHA1Complete). The MLTM will output a 160-bitdigest. All these operations will be executed within the secure boundaries of theMLTM. Finally, the OTP Generator application will convert the resulting digestto a human readable value (a.k.a. the OTP.)

If the OTPs run out of order, the OTP Generator can request a new Counti-Avalue from SP-i to resynchronize the OTP generation.

7.2.1.3 Protecting OTP Generation

Malicious applications installed on the mobile phone could use the private keyKpr-A on the MLTM to generate the OTPs, so a protection method is needed toensure that malicious applications cannot use the private key.

The MLTM can provide the capability to protect private keys from being ac-cessed by malicious applications using the integrity measurement functions [28].This is when the MLTM securely reports the environment when a system isbooted1. The trusted boot sequence is a feature supported by the MLTM todetermine the trusted status of a platform. In this method, the MLTM hashes con-figuration information throughout the secure boot sequence and stores the hashvalues in Platform Configuration Registers (PCRs). Sensitive data such as theprivate key can be“sealed” under a PCR. The only way to unseal the data is if thePCR has the same hash value as at the time of sealing. Therefore, if an attempt ismade to boot a compromised operating system with a malicious application, the

1Booting is a process that starts an operating system when a computer is switched on. Aboot sequence is the initial set of operations that the computer performs while booting.

Page 167: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

7.2. OTP Token Using Trusted Computing 145

PCR value of the compromised operating system and the stored hash value of thetrusted operating system will not match and the unseal process will fail. This willprovide a strong mechanism to protect the private key from being accessed by anymalicious application to generate the OTPs.

As described above, malicious programs, such as viruses and Trojans, are dis-covered by changes in the PCR measurement. In addition, if vulnerable mobilephone programs are exploited, any alteration to the mobile phone environmentthey make can also be detected in the same manner.

Data encrypted under keys sealed by the MLTM (e.g. the shared secret key)is much harder to access. The attacker would need to possess the mobile phone toopen up the chip and get the storage root key to unseal the protected keys [28].

7.2.2 Access to the Mobile Phone

Access to generating an OTP is secured by a PIN as usual which could be the PINused to access the mobile phone.

Another option to secure access to the mobile phone is biometrics. Biomet-ric authentication methods are used for human recognition based upon intrinsicunique physical (e.g. fingerprint, iris recognition, and DNA) or behavioral (e.g.voice, gait, and typing rhythm) traits. Biometrics is usually used for identity accessmanagement and control. In this manner, the verification process is carried out ina one to one comparison of a scanned biometric with a stored template to authen-ticate a person identity. The uniqueness characteristic of biometrics representsthe individuality of one person compared to others. Unlike passwords, biometricscannot be re-issued. If a password is lost another password can replace it, howeverbiometrics cannot be replaced. For example, if someone’s iris is compromised, noone other than “God” can reissue it. For this reason, biometrics are considered ashighly sensitive data that require a very strong protection.

Biometrics can be used to protect the mobile phone and prevent unauthorizedaccess to its content. However, this would require storing a biometric templateof the mobile phone’s owner in the device. As mentioned above, due to the highcost of a compromised biometric, the template requires a very strong protectionmechanism. Trusted computing can provide strong physical protection to thebiometric template. Biometric data can be protected using the sealed storagefeature. In this method, the data can be read only to a particular mobile phoneapplication where the software hash value is equal to a predefined hash value that

Page 168: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

146 Chapter 7. A Robust Scalable Token-based Authentication Solution

is stored in the MLTM. Attempts to read the data by any other than the predefinedapplication will be refused by the MLTM.

7.3 Security Analysis

The proposed scheme combines the advantages of both the physical and the soft-ware based OTP tokens. More specifically, the scheme’s security is rooted inhardware, and it allows OTP generation for multiple service providers while stillonly requiring one single hardware device.

The scheme is aimed at enhancing the system security by creating a root oftrust where the service provider (e.g. a bank) can ensure that only the intendeduser’s hardware device, e.g. mobile phone with MLTM, can access the sensitiveshared secret key. To gain service provider trust, the scheme needs to satisfy twoconditions:

1. The shared secret key must be distributed securely.

2. Every service provider needs assurance that the shared secret key will notbe compromised and will only be used by the genuine MLTM embedded inthe intended user’s mobile phone.

To achieve that, every service provider should be able to validate the MLTM’ssource. The service provider must be able to verify that the MLTM is manufac-tured by a known and trusted manufacturer according to the TCG specifications,and to verify that the validated MLTM indeed belongs to the intended user.

Standard key management and secret exchanging protocols like Diffie-Hellmanand Needham-Schroeder are by themselves unable to accomplish the above re-quirements. The scheme needs not only to allow the service provider and theuser to securely create and exchange the shared secret key, but the scheme has tolink the shared secret key physically to the user’s mobile phone and establish anassociation between the user identity and his/her mobile phone’s MLTM.

Binding the shared secret key to the private key which is protected by theMLTM of the user’s mobile phone, and performing the OTP calculation withinthe secure boundaries of the MLTM in addition to securely distributing the sharedsecret key between the involved entities makes it difficult for attackers to com-promise the shared secret key. If the encrypted value of the shared secret key isintercepted and read by an attacker (e.g. Man-In-the-Browser), it will be of no

Page 169: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

7.3. Security Analysis 147

value to the attacker unless he can obtain the private key to decrypt it. The schemealso reduces the attack opportunities to a negotiable risk level by distributing theshared secret key securely using two separate channels. A brief security analysisis outlined below.

The cost of compromising the shared secret key involves the cost of compro-mising the private key or the cost of simultaneously controlling the two separatechannels (i.e. Internet and cellular network) to the same user. Once inside themobile phone, the shared secret key is protected by the MLTM, and it is assumedthat the MLTM is secure. It is also assumed that it is difficult for an attacker totake over the control of the user’s personal mobile phone and obtain the PIN toactivate it.

Controlling the two separate channels simultaneously would be costly since it isassumed that it is difficult for attackers to control the cellular network or the SMSmessages sent from the service provider to the users while in transit through themobile network at the time of requesting the shared secret key. Even if interceptionand cryptanalysis of SMS messages sent over the air were possible, it requires thatthe attacker is physically present in the same base station coverage area, and thisexcludes attacks from anywhere in the world. This added constraint of using thecellular network which is separate from the Internet, where the public key is to besent, will increase the cost of any attempt to attack the distribution of the sharedsecret key.

The solution provides security protection against the Man-in-the-Middle andMan-in-the-Browser attacks. The attacks will not only require the interception ofthe Internet connection and replacing the public key of the user by the public keyof the attacker, but it would also require the attacker to intercept the SMS sentfrom the service provider to the user to get the value Na and then generate a hashvalue of attacker’s public key and Na. Below, a discussion of the two attacks isgiven.

Man-in-the-Browser

Assuming that the common secret value Na does not exist. An interjected Man-in-the-Browser malware can modify the data between the user and the web browser’ssecurity mechanism in a completely stealthy way. If the user sends a request forthe shared secret key SKi-A to the service provider and attaches the certificate ofthe public key Kpu-A, the malware can replace this certificate with a certificate of

Page 170: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

148 Chapter 7. A Robust Scalable Token-based Authentication Solution

a genuine MLTM’s public key of the attacker (call it Kpu-X) without the user’sknowledge. The service provider will receive the request with the attacker’s publickey and cannot differentiate between the original data and the modified data. Theservice provider verifies the source of the public key, generates the shared secret keySKi-A, encrypts SKi-A with attacker’s public key and then sends the encryptedvalue EKpu_X (SKi-A) to the user.

The web browser at the user side will receive the encrypted value of the sharedsecret key where the MITB malware replaces it with another fake shared secretkey encrypted using the user’s public key. The user believes that the encryptedvalue he received is of the original shared secret key SKi-A that was sent bythe service provider. As a result, the MLTM of the user’s mobile phone willgenerate invalid OTPs. On the other hand, the attacker can use the encryptedvalue EKpu_X (SKi-A) to generate valid OTPs using his mobile phone’s genuineMLTM. Later, when the user sends invalid OTP for authentication, the MITBmalware replaces this invalid OTP with a valid OTP and relays it to the serviceprovider. The user and the service provider will not notice the attack.

Now, considering the existence of the common secret value Na. When request-ing the shared secret key SKi-A from the service provider, the user will attach ahash value of the public key Kpu-A and the value Na to allow the service provider toverify that the key is coming from the user. The MITB attack is avoided becausethe malware cannot get access to the common secret value Na and regenerate an-other hash value of the attacker’s public key “Kpu-X” and the value Na and thenrelays the hash to the service provider. The value Na is sent over an out-of-bandchannel which is separate from the web browser.

Man-in-the-Middle

Again, assuming the common secret value Na does not exist. It is also possiblefor an attacker to intercept the communication between the user and the serviceprovider’s server and impersonate them both. The attacker can act as a Man-In-The-Middle between the user and the service provider. When the user sends arequest for a shared secret key to the attacker’s website and attaches the publickey Kpu-A, the attacker can relay a similar altered request but with his public key(i.e. “Kpu-X”) to the service provider. Upon receiving the altered request, theservice provider will execute the request and send the value EKpu_X (SKi-A) to theattacker.

Page 171: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

7.4. Discussion 149

The attacker will receive the encrypted value of the shared secret key where hereplaces it with another false shared secret key encrypted with user’s public key.The user thinks that he received the encrypted value of the original shared secretkey SKi-A from the service provider. Again, the MLTM of the user’s mobile phonewill not generate valid OTPs. The attacker though can feed the encrypted valueEKpu_X (SKi-A) to his mobile phone’s genuine MLTM to generate valid OTPs. Aswith the MITB Trojan, when the user sends invalid OTP for authentication, theMITM replaces the invalid OTP with a valid OTP and relays it to the serviceprovider. Both the user and the service provider will not detect the attack.

However, when the user requests the shared secret key SKi-A and attaches ahash value of the public key Kpu-A and the value Na, the MITM attacker cannotobtain the value Na which is sent in a separate channel and cannot generate ahash value of his public key “Kpu-X” and the value Na.

As mentioned before, the mobile phone should be protected by a PIN and/orpossibly also biometrics to prevent unauthorized entities from accessing its contentin cases where the mobile phone is lost or stolen. In case a user fears that astolen phone could be compromised, the user should prevent unauthorized entitiesfrom using it to generate valid OTPs by remotely locking it. Remote locking is aservice provided by some mobile phone manufacturers and/or carriers to preventunauthorized access of lost mobile phones [38, 75]. In addition, the user can use azeroization service provided by some manufacturers. The zeroization of a device isa method of electronically wiping out the data stored in that device in a mannerthat prevents the recovery of deleted data. For an example of this service, see[76]. The user must also contact the service provider to deactivate the OTP token.Deactivating the token will invalidate the OTPs generated by the lost mobile phoneand guarantee that it cannot be used for authentication with that service providereven if the locking service is not available.

7.4 Discussion

The value Na is assumed to be a common secret between User-A and SP-i at thetime of OTP configuration because of the assumptions that:

• The service provider knows the mobile phone number of User-A.

• User-A controls his mobile at the time of requesting the shared secret keyand receiving Na.

Page 172: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

150 Chapter 7. A Robust Scalable Token-based Authentication Solution

• There is no other mobile phone with the same phone number.

• It is difficult for an attacker to control both the Internet and the mobilenetwork at the time of OTP configuration.

However, the user can not be certain that Na is coming from the serviceprovider. An attacker can intercept the request for shared secret key from the user(Step 1 in Figure 7.4) and send a false Na masquerading as the service provider.It is possible for anyone to use the SMS services provided on some Internet sitesto send a message to any mobile phone number and spoof any originating phonenumber. The attack could establish an OTP scheme between the user and theattacker, but this would not allow the attacker to masquerade as the user and gainaccess to the service provider’s services. The attack would normally be discoveredby the user when he is unable to generate valid OTPs and consequentially becomesunable to execute transaction requests.

According to the TCG standardization, the TPM (as well as the MLM) onlyprovides support for hashing data using the SHA-1 algorithm. Although SHA-1still can provide secure hashes, it is considered marginal. Among the features underconsideration for the next generation of TPM, TCG has indicated that SHA-1 isbeing phased out [67], which in practice means that it may be replaced by oneof the SHA-2 family hash algorithms, or by the future SHA-3. A stronger MultiOTP solution can be deployed using one of the SHA-2 family functions which canhave hash blocks sizes of 224, 256, 384 or 512 bits if they are supported by thefuture TPM.

The separation of the mobile phone from the user client terminal gives theOTP authentication scheme added security strength. However, with the trend ofmalware attacks migrating from the Internet to mobile networks it would also bepossible for attackers to control the mobile phone and gain access to the OTPGenerator.

Also, this separation limits the scheme’s usability, which requires the user tomanually copy the OTP from the mobile phone to the client terminal. To enhancethe scheme’s usability, the process of copying the OTP can be automated by se-curely connecting the mobile phone to the client terminal without compromisingthe security strength. However, care must be taken with this type of implementa-tion, making sure that the OTP Generator application and the shared secret keyon the mobile phone are protected from unauthorized access.

Page 173: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

7.5. Conclusion 151

One major limitation of systems and devices that combine many services in asingle location or an individual component is their vulnerability to the single pointof failure. The single point of failure is a state where if a system or a device fails,all the services that rely on that system or device become unavailable. The singletoken device solution proposed in this chapter is vulnerable to the single pointof failure problem. If the mobile phone stops functioning or in cases where it islost or stolen, the user cannot use the OTP authentication scheme to any serviceprovider defined in that mobile phone.

However, users can always go back to the old authentication procedure in suchcases. As an example, with current online banking systems, if a customer cannotaccess his OTP hardware token or the token stops functioning he can contactthe bank and go back to old authentication methods such as the use of cognitivepasswords2 until the hardware token resumes functioning or a new token arrives.

When the user wants to replace the mobile phone, the OTP Generator appli-cation must be installed in the new telephone and then the procedure of Figure7.4 must be repeated for each service provider.

To date there are no mobile phones with MTM, so this is not a solution thatcan be deployed quickly, however the increasing level of risk related to identitytheft when using Internet services requires us to be well prepared.

7.5 Conclusion

The traditional requirements which dictate that passwords shall be difficult toguess and be different for different services put a considerable mental burden onusers. Various studies [111] show that people use heuristic strategies to reducethe mental load. Unfortunately, these strategies also make passwords vulnerableto attack. This represents a serious threat to the security of user authentication,making systems vulnerable to all variants of password cracking attacks.

As a response to the growing threats to online services security, special pass-word management methods that use an OTP (One-Time Password) have beendeveloped. This is implemented by issuing special tokens that can generate OTPs.OTP tokens can be hardware tokens or software tokens.

A fundamental problem with introducing software modules for identity man-

2A cognitive password is an authentication method based on something the user intrinsicallyknow. It requires the users to answer a number of questions to verify their identity

Page 174: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

152 Chapter 7. A Robust Scalable Token-based Authentication Solution

agement such as software tokens on the client platform is that its security relies onthe inherent security of the platform. By storing shared secrets on the platform,the risk caused by a compromised platform is amplified dramatically.

Although hardware tokens are considered to be stronger than software tokens,however they have a usability problem. With the increasing number of hardwaretokens needed by one user to be authenticated to different service providers, themore inconvenient it becomes to manage all the different tokens. On the otherhand software tokens can eliminate the need for carrying separate physical tokensfor each service provider no matter how many tokens are required.

The solution proposed in this chapter involves the integration of hardware andsoftware in order to assist users with identity management. In particular, a solutionwhere it is possible to install multiple virtual one-time password generators in amobile phone that is equipped with the hardware Mobile Trusted Module has beendescribed.

A situation where users are forced to have multiple physical OTP Generationdevices results in usability problems and does not scale. In general, since poorusability leads to poor security, the proposed approach which allows multiple OTPgenerators on a single device will improve security by improving the usability andsolving the scalability problem from the user perspective.

Page 175: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

Chapter 8

Conclusion and Future Work

8.1 Conclusion

Identity management is the process of identifying and authenticating people andentities across computer and network systems and controlling their access to theservices provided by those systems. It involves the secure management of theincreasing number of digital identities each individual requires, and the protectionof personal data and credentials against various attacks. Identity managementsystems need to provide adequate security usability and should have a simple andintuitive interface, otherwise it will lead to inconvenience for users when managingtheir digital identities. Poor interface design leads to inconvenience which is highlylikely to result in systems with weak security.

Unfortunately, when designing new identity management systems, the needsand limitations of users are not usually given enough attention at the design phase.The design should not only consider the service provider’s perspective but shouldalways reflect user’s perspectives. System developers should always consider theuser’s capabilities and experience and how they need or want to use the systeminstead of forcing them to adapt their behavior to accommodate the new system.

More than 120 years ago, the Belgian cryptographer Auguste Kerckhoffs indi-cated in his security principles [93]:

“regarding the circumstances in which a system is applied, it must beeasy to use and must neither require stress of mind nor the knowledgeof a long series of rules.”

153

Page 176: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

154 Chapter 8. Conclusion and Future Work

This represents an important usability principle that is particularly relevanttoday, but that unfortunately has been mostly overlooked [135]. Complex systemsdesigned with strong technical security but poor usability may end up being in-secure. Generally, the strength of a security system is determined by the weakestlink in the system. In many cases it is the human operator who may represent theweakest link [141]. Service providers typically attribute system security failures tohuman errors. They blame users for violating security measures and for not cor-rectly handling complex technical systems [70]. However, some researchers arguethat what is often viewed as human error is in fact the result of design flaws thatmay be overcome [110]. It is recognized that security systems will only be able toprovide the intended protection when people actually understand and are able touse them correctly.

In this research, the security usability of actual identity management systemsused in online banking was examined. In particular the usability aspect of theSMS-based and token-based authentication schemes was investigated through ex-perimentation and analysis.

Experimentation was used in this research to investigate the security of theSMS-based authentication scheme which is widely used by online banking systems.The study has given a strong indication that the SMS transaction authorizationmethod is vulnerable to the attacks that have been described in the experiment.According to the study observations users would be able to avoid only about 79%of realistic attacks, which arguably represents an inadequate level of security foronline banking. The study concluded that the security failure has more to dowith usability than with technical security. The system design overestimates thevigilance of users. The experiment findings confirmed what has been outlined anddiscussed by security usability researchers: if an identity management system doesnot provide adequate security usability with a simple and intuitive interface it ishighly likely that it will result in a system with inadequate security [161, 162, 160,110, 137, 50]. The study also concluded that a possible solution should thereforebe based on an improvement in usability, and not necessarily on improving securitymechanisms.

The thesis described two proposed practical solutions with improved usabil-ity to strengthen the security of the SMS-based authentication scheme. In thesesolutions the burden caused by the extra task of validating every transaction ina rigorous manner has been simplified. The first solution enhances the scheme

Page 177: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

8.1. Conclusion 155

usability by minimizing the number of manual verifications of the transaction de-tails while the second solution uses the display security assurance to automate thetransaction verification process. The first solution works by maintaining severallists of accounts (e.g. a list of trusted accounts) in the mobile phone generatedfrom previous transactions. The mobile phone verifies the transaction details bycomparing the data in the SMS against the data in the account lists. The displaysecurity solution is based on using a digital camera which “sees” the displayedtransaction data exactly as the user sees it. The bitmap image of the transactiondata is then converted back to the original digital form using OCR techniques,so that the displayed transaction data can be automatically compared with thosereceived through SMS from the bank.

The two solutions complement each other: the mobile phone first looks intothe lists of accounts for comparison with the server’s SMS before looking for anew OCR file. As the user continues to use the system, the number of snapshotsa user needs to take is reduced without undermining the protection offered byverifying transaction data on an individual basis as every transaction is checkedby the mobile phone either against the trusted accounts list (which is separate andindependent from the client terminal) or by a new OCR.

The two solutions were analysed and examined through experimentation andthe results showed that the overall security of the new enhanced SMS-based au-thentication scheme was improved. The improvement to the security resultedfrom enhancing the scheme usability in which the burden of manually verifyingeach transaction’s details adequately is shifted to the mobile phone by the newsystem. A significant improvement was observed with stealthy attacks where itwould be otherwise difficult for participants to notice the minor alteration in thetransaction’s details involving only one digit in the destination account number.From the user’s perspective, as the number of altered digits decreases the difficultylevel of the validation process increases. On the other hand, the number of altereddigits has no effect on the automatic validation executed by the mobile phone.

Finally, the token-based authentication solutions were analysed from the secu-rity and usability perspectives. As the number of hardware tokens needed by oneuser to be authenticated to different service providers increases, the more inconve-nient it becomes to manage all the different tokens. Forcing users to have severalphysical OTP generation devices for different service providers results in usabilityproblems and does not scale. On the other hand, the presumed less secure software

Page 178: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

156 Chapter 8. Conclusion and Future Work

tokens can eliminate the need for carrying separate physical tokens for each serviceprovider no matter how many tokens are required.

This research proposed the integration of hardware and software in order toassist users with more secure tokens. A solution is described where it is possibleto install multiple virtual one-time password generators in a single device i.e. amobile phone that is equipped with the hardware Mobile Trusted Module.

8.2 Future Work

Most authentication systems ignore that it is often equally important for users tobe able to identify service providers as it is for service providers to authenticateusers. Mutual authentication is the practice where the two parties involved in theauthentication process can verify each other’s identity.

The OTP token-based and SMS-based authentication schemes may be re-designed to implement mutual authentication. These mutual authentication schemesneed investigation and analysis considering various types of security threats suchas the Man-in-the-Middle and the Man-in-the-Browser attacks.

The separation of the mobile phone from the user client terminal gives theSMS-based and the token-based authentication schemes its security strength butwith current technology it would also be possible for attackers to control the mobilephone and gain access to valuable information such as the SMS sent by the bankor the OTP generated by the token. For example, attackers can get access tothe mobile phone if it is connected to the Internet or if the phone’s Bluetooth isenabled i.e. making it available for a connection. The relatively new attack knownas snarfing, for example, allows intruders to gain access to Bluetooth enabledphones by exploiting a security flaw in the wireless protocol [126].

Separation of mobile device and user client terminal limits the scheme usability,because the user is required to manually copy the authorization code or the OTPfrom the mobile phone to the client terminal in order to confirm a transactionor to complete an authentication process. To enhance the schemes’ usability, themanual process of copying the authorization code or the OTP can be automated bysecurely connecting the mobile phone to the client terminal without compromisingthe schemes’ strength.

However, care must be taken with this type of implementation, making surethat the applications and data on the mobile phone, such as the OTP generator and

Page 179: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

8.2. Future Work 157

the SMS sent by the bank, are protected from unauthorized access. One possibleway to implement this is by using the emerging Trusted Computing technologywhich is planned to be included in the coming generation of devices such as mobilesand PDAs. Features like sealed storage can be applied such that only verifiedsoftware will have access to certain data and functions. This can be used toprevent malware attacks on mobile phones.

One major limitation of using the mobile phone as a single token device toauthenticate the user to different service providers is its vulnerability to the singlepoint of failure. The single point of failure is a state where if a system or a devicefails, all services that rely on that system or device become unavailable. If themobile phone stops functioning or in cases where it is lost or stolen, the usercannot use the OTP authentication scheme to any service provider defined in thatmobile phone. One method to overcome this limitation is possibly by reconfiguringthe system to use cryptographic migratable keys instead of non-migratable keys(see Section 2.13.1 for descriptions of these keys) and design backup proceduresto restore a state following a disaster or to restore lost data after they have beenaccidentally deleted or corrupted.

Finally, it is worth remembering that a perfectly secure system will never ex-ist. Security vulnerabilities will always remain and there will always be humanfailures to follow policies. The key consideration is managing risk within accept-able bounds. Estimating the risk and implementing solutions to reduce it to anacceptable level is what really matters.

There is always a trade-off between different goals when designing identity man-agement solutions, and it is natural that the service and infrastructure providerswill promote solutions that are cost effective relative to the assumed risk. However,as the threat environment changes, the solutions need to be adapted.

Page 180: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

158 Chapter 8. Conclusion and Future Work

Page 181: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

Appendix A

PHP Source Code of the VirtualOnline Bank

The PHP source code which was used to implement the simulated online bankin the two experiments that were described in chapters 4 and 5 is given in thisappendix.

A.1 New Transaction Web Page (ch.4)

The following script was used to print the “New Transaction” web page and handleall the functionality of entering, creating, validating and sending the transactiondata in the experiment described in Chapter 4 which was conducted on the SMS-based authentication scheme:

<?php // This line MUST be at the top of the page,// or else cookies and session variables will not work.

session_start();?><html><head><style>body {

font-family: verdana,arial,helvetica;color : #006699;

}h1 { color: #003366;

}h2 { color: #006699; }

159

Page 182: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

160 Appendix A. PHP Source Code of the Virtual Online Bank

h3 { color: #006699; }</style></head><body>

<?phprequire_once("confirm-inc.php");if (!isset($_SESSION[’counter’])) { $_SESSION[’counter’]=0; }# on "shannon", login with your details, but then execute:# mysql -u webuser -p# and enter the password found in $sqlpass to get the sql console.$sqluser="webuser";$sqlpass="********";$accstart=30263142;$numaccounts=20;$link = mysql_connect("localhost",$sqluser,$sqlpass) or die("Can’t connect to database!");mysql_select_db("alzomaim", $link) or die("Can’t select database!");$email="";$account=0;$amount=0;//Check if the e-mail is in the session variableif (isset($_SESSION[’email’])) { $email=$_SESSION[’email’]; }// but don’t give it precedence over what’s in the request fieldif (isset($_REQUEST[’email’])) { $email=$_REQUEST[’email’]; }if (isset($_REQUEST[’account’])) { $account=$_REQUEST[’account’]; }if (isset($_REQUEST[’amount’])) { $amount=$_REQUEST[’amount’]; }function countEmailTransactions($email) {

$result=mysql_query("select count(email) from bank where email=’$email’;");if ($row=mysql_fetch_row($result)) {

return $row[0];} else{

return 0;}

}

function createBadAccount1($account) {srand(time());$uh=substr($account,0,5);$mid=substr($account,5,1);$lh=substr($account,6,2);$new=$mid;while ($new==$mid) {

$new=(rand() % 8) + 1;}return $uh.$new.$lh;

}

function createBadAccount5($account) {srand(time());$acc=substr($account,0,3);for ($i=3; $i<=7; $i++) {

$mid=substr($account,$i,1);$new=$mid;

Page 183: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

A.1. New Transaction Web Page (ch.4) 161

while ($new==$mid) {$new=(rand() % 9) + 1;

}$acc=$acc.$new;

}return $acc;

}

// sets a random ID for this e-mail addressfunction addNewRandomID($email) {

$newid=1;$result=mysql_query("select count(random_id) from users;");if ($row=mysql_fetch_row($result)) {

$newid=($row[0]%10)+1;}$result=mysql_query("insert into users values(’$email’,$newid);");return $newid;

}

// gets the assigned random ID for this e-mail addressfunction getRandomID($email) {

$result=mysql_query("select random_id from users where email=’$email’;");if ($row=mysql_fetch_assoc($result)) {

return $row[’random_id’];} else {

return addNewRandomID($email);}

}

function addEntry($email,$account,$amount) {$mod=0;$writeacc=$account;//Init our counter from the database$_SESSION[’counter’]=countEmailTransactions($email);//Add the e-mail address to the session$_SESSION[’email’]=$email;$modvalue=getRandomID($email);//work out if we need to flip the account numberif ((($_SESSION[’counter’]+1) % 10) == ($modvalue % 10)) {

$writeacc=createBadAccount1($account);$mod=1;

}if ((($_SESSION[’counter’]+1) % 10) == (($modvalue + 5) % 10)) {

$writeacc=createBadAccount5($account);$mod=4;

}$confirm=strtoupper(substr(sha1($email.$amount.$account),10,6));$result=mysql_query("insert into bank values(0,’$email’,$writeacc,$amount,’$confirm’,$mod,0);");if ($result==1) {

print "<h1>Example Bank (Confirmation)</h1>";print "Transaction queued.<br />";// get the id, and mail the user$id=mysql_insert_id();if (!sendEmail($id,$email,$writeacc,$amount,$confirm)) {

Page 184: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

162 Appendix A. PHP Source Code of the Virtual Online Bank

mysql_query("delete from bank where id=$id;");} else { //Success

printConfirmDialog($writeacc,$amount,$id);}

} else {print mysql_error();}

}

function printInputForm() {global $account, $amount, $email;print "<h1>Example Bank (New Transaction)</h1>";print "<p><hr> Please enter the following details:";print "<form action=\"".$_SERVER[’SCRIPT_NAME’]."\" method=\"POST\">";print "<table>";print "<tr><td>E-Mail Address:</td><td><input type=\"text\" name=\"email\" value=\"$email\"></td></tr>";print "<tr><td>To Account:</td><td><input type=\"text\" name=\"account\" value=\"$account\"></td></tr>";print "<tr><td>Amount: $</td><td><input type=\"text\" name=\"amount\" value=\"$amount\"></td></tr>";print "<tr><td></td><td><input type=\"submit\" name=\"transact\" value=\"Submit\"></td></tr>";print "</table></form>";

}function checkForm() {

global $account, $amount, $email,$accstart,$numaccounts;if (($account < $accstart) or ($account > ($accstart+$numaccounts))) {

print "<font color=\"#A00000\">Invalid Account number.</font><br /><br />";return false;

} elseif ($amount <= 0 ) {print "<font color=\"#A00000\">Invalid Amount.</font><br /><br />";return false;

} elseif (!eregi("^[_a-z0-9-]+(\.[_a-z0-9-]+)*@[a-z0-9-]+(\.[a-z0-9-]+)*(\.[a-z]{2,3})$", $email)) {print "<font color=\"#A00000\">Invalid E-Mail.</font><br /><br />";return false;

} elsereturn true;

}

function sendEmail($id,$email,$account,$amount,$conf) {$msg=<<<EOT

(This e-mail is part of an experiment - it is not a phishing scam)

Account Number: $accountAmount: $amount

CONFIRMATION CODE: $conf

EOT;$result=mail($email,"(EXPERIMENT) Bank Transaction - Confirmation Code",$msg);if ($result) {

print "Mail has been sent to $email with your confirmation code.<hr />";//print "To make another transaction click <a href=\"".$_SERVER[’SCRIPT_NAME’]."\">here</a>";return true;

} else {print "Sorry, your e-mail could not be sent at this time. <br />";

Page 185: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

A.2. Confirmation Web Page (ch.4) 163

print "Your transaction has been aborted.";return false;

}}if (isset($_REQUEST[’transact’])) {

if (checkForm()) {addEntry($email,$account,$amount);

} else {printInputForm();

}} else {

printInputForm();}

print "<font color=\"#FFFFFF\" size=\"1\">".$_SESSION[’counter’]."</font>";print "<br /><hr size=1>Note: Please do not use \"Refresh\" or your browser’s back and forward buttons.<br /><font size=\"1\">This website is not a legitimate banking website and is used for experimentation only.</font>";mysql_close($link);

?>

A.2 Confirmation Web Page (ch.4)

The following script was used to print the “Confirmation” web page and displaythe transaction details in the experiment described in Chapter 4. The script wasalso used to handle the process of confirming the transaction and displaying theconfirmation information.

<html><head><style>

body {font-family: verdana,arial,helvetica;color : #006699;

}h1 { color: #003366; }h2 { color: #006699; }h3 { color: #006699; }

</style></head><body>

<?phprequire_once("confirm-inc.php");print ’<html><head>’;print "</head><body>";print "<h1>Example Bank (Confirmation)</h1><hr>";$sqluser="webuser";$sqlpass="********";$link = mysql_connect("localhost",$sqluser,$sqlpass) or die("Can’t connect to database!");mysql_select_db("alzomaim", $link) or die("Can’t select database!");if (!isset($_REQUEST[’id’])) {

Page 186: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

164 Appendix A. PHP Source Code of the Virtual Online Bank

die("<p>Please type the link exactly as found in the e-mail (no ID found)<br />");}$result=mysql_query("select * from bank where id=${_REQUEST[’id’]};");if ($row=mysql_fetch_assoc($result)) { // ID is valid

if (isset($_REQUEST[’confirm’])) { //user is trying to confirmif (strcmp($_REQUEST[’authcode’],$row[’authorization’])==0) {

$result=mysql_query("update bank set approved=1 where id=${_REQUEST[’id’]};");if ($result==1) {

print "Transaction has been authorized.<br />";//print "Database updated.";

} else {print "Database update failed!";

}print "<br />";

} else {print "Transaction has not been authorized. No valid Authorization code has been submitted.<br />";print "<ul>";print "<li />To try again, click <a href=\"".$_SERVER[’SCRIPT_NAME’]."?id=".$_REQUEST[’id’]."\">here</a>, or"print "<li />";

}print "To make another transaction click <a href=\"index.php\">here</a>";print "</ul>";

} else { // print confirm diaglogprintConfirmDialog($row[’account’],$row[’amount’],$_REQUEST[’id’]);

}} else {

die("<p>Invalid transaction!</p>");}print "<br /><hr size=1>Note: Please do not use \"Refresh\" or your browser’s back and forward buttons.<br /><font size=\"1\">This website is not a legitimate banking website and is used for experimentation only.</font>";mysql_close($link);

?>

// print the confirmation dialog<?

function printConfirmDialog($account,$amount,$id) {print "Do you wish to confirm this transaction?";print "<form action=\"confirm.php\" method=\"POST\"><table>";print "<tr><td>Account Number:</td><td>$account</td></tr>";print "<tr><td>Amount:</td><td>$amount</td></tr>";print "<tr><td>Enter Authorization Code:</td><td><input type=text name=\"authcode\" value=\"\"></td></tr>";print "<tr><td><input type=\"hidden\" name=\"id\" value=\"$id\"></td><td><input type=submit name=\"confirm\"value=\"Confirm\"></td>";

print "<td><input type=submit name=\"confirm\" value=\"Cancel\"></td></tr>";print "</table></form>";

}?>

Page 187: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

A.3. New Transaction Web Page (ch.5) 165

A.3 New Transaction Web Page (ch.5)

The following script was used to print the “New Transaction” web page and handleall the functionality of entering, creating, validating and sending the transactiondata in the experiment described in Chapter 5 which was conducted on the pro-posed solution to enhance the usability of the SMS-based authentication scheme:

<?php // This line MUST be at the top of the page,// or else cookies and session variables will not work.

session_start();?><html><head><style>body {

font-family: verdana,arial,helvetica;color : #006699;

}h1 { color: #003366;

}h2 { color: #006699; }h3 { color: #006699; }

</style></head><body>

<?phprequire_once("confirm-inc.php");if (!isset($_SESSION[’counter’])) { $_SESSION[’counter’]=0; }# on "shannon", login with your details, but then execute:# mysql -u webuser -p# and enter the password found in $sqlpass to get the sql console.$sqluser="webuser";$sqlpass="********";$accstart=30263142;$numaccounts=20;$link = mysql_connect("localhost",$sqluser,$sqlpass) or die("Can’t connect to database!");mysql_select_db("alzomaim", $link) or die("Can’t select database!");$email="";$account=0;$amount=0;$accName="";//Check if the e-mail is in the session variableif (isset($_SESSION[’email’])) { $email=$_SESSION[’email’]; }// but don’t give it precedence over what’s in the request fieldif (isset($_REQUEST[’email’])) { $email=$_REQUEST[’email’]; }if (isset($_REQUEST[’account’])) { $account=$_REQUEST[’account’]; }if (isset($_REQUEST[’amount’])) { $amount=$_REQUEST[’amount’]; }function countEmailTransactions($email) {

$result=mysql_query("select count(email) from bank where email=’$email’;");if ($row=mysql_fetch_row($result)) {

Page 188: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

166 Appendix A. PHP Source Code of the Virtual Online Bank

return $row[0];} else{

return 0;}

}

function createBadAccount1($account) {srand(time());$uh=substr($account,0,5);$mid=substr($account,5,1);$lh=substr($account,6,2);$new=$mid;while ($new==$mid) {

$new=(rand() % 8) + 1;}return $uh.$new.$lh;

}

function createBadAccount5($account) {srand(time());$acc=substr($account,0,3);for ($i=3; $i<=7; $i++) {

$mid=substr($account,$i,1);$new=$mid;while ($new==$mid) {

$new=(rand() % 9) + 1;}$acc=$acc.$new;

}return $acc;

}

// sets a random ID for this e-mail addressfunction addNewRandomID($email) {

$newid=1;$result=mysql_query("select count(random_id) from users;");if ($row=mysql_fetch_row($result)) {

$newid=($row[0]%10)+1;}$result=mysql_query("insert into users values(’$email’,$newid);");return $newid;

}

// gets the assigned random ID for this e-mail addressfunction getRandomID($email) {

$result=mysql_query("select random_id from users where email=’$email’;");if ($row=mysql_fetch_assoc($result)) {

return $row[’random_id’];} else {

return addNewRandomID($email);}

}

Page 189: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

A.3. New Transaction Web Page (ch.5) 167

function addEntry($email,$account,$amount) {$mod=0;$writeacc=$account;//Init our counter from the database$_SESSION[’counter’]=countEmailTransactions($email);//Add the e-mail address to the session$_SESSION[’email’]=$email;$modvalue=getRandomID($email);//work out if we need to flip the account numberif ((($_SESSION[’counter’]+1) % 10) == ($modvalue % 10)) {

$writeacc=createBadAccount1($account);$mod=1;

}if ((($_SESSION[’counter’]+1) % 10) == (($modvalue + 5) % 10)) {

$writeacc=createBadAccount5($account);$mod=4;

}$confirm=strtoupper(substr(sha1($email.$amount.$account),10,6));$found=0;$result=mysql_query("select * from bank where account=’$account’;");if ($row=mysql_fetch_assoc($result)) {

$found=1; //account is knownif ($row[’trusted’]) { //account is in the trusted list

mysql_query("update bank set trusted=1 where id=${_REQUEST[’id’]};");$accName = ${row[’7’]};

}if ($row[’malicious’]) { //account is in the malicious list

mysql_query("update bank set malicious=1 where id=${_REQUEST[’id’]};");}

}$result=mysql_query("insert into bank values(0,’$email’,$writeacc,$amount,’$confirm’,$mod,0);");if ($result==1) {

print "<h1>Example Bank (Confirmation)</h1>";print "Transaction queued.<br />";// get the id, and mail the user$id=mysql_insert_id();if (!sendEmail($id,$email,$writeacc,$amount,$confirm)) {

mysql_query("delete from bank where id=$id;");} else { //Success

printConfirmDialog($writeacc,$amount,$id);}

} else {print mysql_error();}

}

function printInputForm() {global $account, $amount, $email;print "<h1>Example Bank (New Transaction)</h1>";print "<p><hr> Please enter the following details:";print "<form action=\"".$_SERVER[’SCRIPT_NAME’]."\" method=\"POST\">";print "<table>";print "<tr><td>E-Mail Address:</td><td><input type=\"text\" name=\"email\" value=\"$email\"></td></tr>";print "<tr><td>To Account:</td><td><input type=\"text\" name=\"account\" value=\"$account\"></td></tr>";

Page 190: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

168 Appendix A. PHP Source Code of the Virtual Online Bank

print "<tr><td>Amount: $</td><td><input type=\"text\" name=\"amount\" value=\"$amount\"></td></tr>";print "<tr><td></td><td><input type=\"submit\" name=\"transact\" value=\"Submit\"></td></tr>";print "</table></form>";

}function checkForm() {

global $account, $amount, $email,$accstart,$numaccounts;if (($account < $accstart) or ($account > ($accstart+$numaccounts))) {

print "<font color=\"#A00000\">Invalid Account number.</font><br /><br />";return false;

} elseif ($amount <= 0 ) {print "<font color=\"#A00000\">Invalid Amount.</font><br /><br />";return false;

} elseif (!eregi("^[_a-z0-9-]+(\.[_a-z0-9-]+)*@[a-z0-9-]+(\.[a-z0-9-]+)*(\.[a-z]{2,3})$", $email)) {print "<font color=\"#A00000\">Invalid E-Mail.</font><br /><br />";return false;

} elsereturn true;

}

function sendEmail($found,$id,$email,$account,$name,$amount,$conf) {$msg1=<<<EOT

(This e-mail is part of an experiment - it is not a phishing scam)

<center><td bgcolor="#009900"><font color=\"#FFFFFF\"><b>TRUSTED ACCOUNT</b></font></td></center>

Account Number: $accountAccount Name: $accNameAmount: $amount

CONFIRMATION CODE: $conf

EOT;

$msg2=<<<EOT

(This e-mail is part of an experiment - it is not a phishing scam)

<center><td bgcolor="#ff0000"><font color=\"#FFFFFF\"><b>MALICIOUS ACCOUNT</b></font></td></center>

Account Number: $accountAmount: $amount

EOT;

$msg3=<<<EOT

(This e-mail is part of an experiment - it is not a phishing scam)

KNOWN ACCOUNT (Please verify the transaction details)

Account Number: $accountAmount: $amount

Page 191: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

A.3. New Transaction Web Page (ch.5) 169

CONFIRMATION CODE: $conf

EOT;

$msg4=<<<EOT

(This e-mail is part of an experiment - it is not a phishing scam)

NEW ACCOUNT (Please verify the transaction details)

Account Number: $accountAmount: $amount

CONFIRMATION CODE: $conf

EOT;

if ($found) {if ($row[’trusted’]) {

$msg=$msg1;} else if ($row[’malicious’]) {

$msg=$msg2;}else {

$msg=$msg3;}

} else {$msg=$msg4;

}$result=mail($email,"(EXPERIMENT) Bank Transaction - Confirmation Code",$msg);if ($result) {

print "Mail has been sent to $email with your confirmation code.<hr />";//print "To make another transaction click <a href=\"".$_SERVER[’SCRIPT_NAME’]."\">here</a>";return true;

} else {print "Sorry, your e-mail could not be sent at this time. <br />";print "Your transaction has been aborted.";return false;

}}if (isset($_REQUEST[’transact’])) {

if (checkForm()) {addEntry($email,$account,$amount);

} else {printInputForm();

}} else {

printInputForm();}

print "<font color=\"#FFFFFF\" size=\"1\">".$_SESSION[’counter’]."</font>";print "<br /><hr size=1>Note: Please do not use \"Refresh\" or your browser’s back and forward buttons.<br /><font size=\"1\">This website is not a legitimate banking website and is used for experimentation only.</font>";mysql_close($link);

?>

Page 192: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

170 Appendix A. PHP Source Code of the Virtual Online Bank

A.4 Confirmation Web Page (ch.5)

The following script was used to print the “Confirmation” web page and displaythe transaction details in the experiment described in Chapter 5. The script wasalso used to handle the process of confirming the transaction and displaying theconfirmation information.

<html><head><style>

body {font-family: verdana,arial,helvetica;color : #006699;

}h1 { color: #003366; }h2 { color: #006699; }h3 { color: #006699; }

</style></head><body>

<?phprequire_once("confirm-inc.php");print ’<html><head>’;print "</head><body>";print "<h1>Example Bank (Confirmation)</h1><hr>";$sqluser="webuser";$sqlpass="********";$link = mysql_connect("localhost",$sqluser,$sqlpass) or die("Can’t connect to database!");mysql_select_db("alzomaim", $link) or die("Can’t select database!");if (!isset($_REQUEST[’id’])) {

die("<p>Please type the link exactly as found in the e-mail (no ID found)<br />");}$result=mysql_query("select * from bank where id=${_REQUEST[’id’]};");if ($row=mysql_fetch_assoc($result)) { // ID is valid

if (isset($_REQUEST[’confirm’])) { //user is trying to confirmif (strcmp($_REQUEST[’authcode’],$row[’authorization’])==0) {

$result=mysql_query("update bank set approved=1 where id=${_REQUEST[’id’]};");if ($result==1) {

if (! $row[’trusted’]) { //account is in the trusted listif (isset($_REQUEST[’insert-trust’])) {

$blnk="";print "<tr><td>Enter an account name:</td><td><input type=\"text\" name=\"accName\"value=\"$blnk\"></td></tr>";mysql_query("update bank set accName=$accName where id=${_REQUEST[’id’]};");mysql_query("update bank set trusted=1 where id=${_REQUEST[’id’]};");print "Account is added to the trusted list.";

}print "Click \"Add\" to add the account to the trusted list.";print "<form action=\"".$_SERVER[’SCRIPT_NAME’]."\">";print "<input type=submit name=\"insert-trust\" value=\"Add\">";

}

Page 193: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

A.4. Confirmation Web Page (ch.5) 171

print "Transaction has been authorized.<br />";//print "Database updated.";

} else {print "Database update failed!";

}print "<br />";

} else {print "Transaction has not been authorized. No valid Authorization code has been submitted.<br />";print "<ul>";print "<li />To try again, click <a href=\"".$_SERVER[’SCRIPT_NAME’]."?id=".$_REQUEST[’id’]."\">here</a>, or";print "<li />";

}print "To make another transaction click <a href=\"index.php\">here</a>";print "</ul>";

} else {if ($row[’malicious’]) { //account is in the malicious list

if (isset($_REQUEST[’insert-malicious’])) {mysql_query("update bank set malicious=1 where id=${_REQUEST[’id’]};");print "Account is added to the malicious list.";

}print "Click \"Add\" to add the account to the malicious list.";print "<form action=\"".$_SERVER[’SCRIPT_NAME’]."\">";print "<input type=submit name=\"insert-malicious\" value=\"Add\">";

}// print confirm diaglogprintConfirmDialog($row[’account’],$row[’amount’],$_REQUEST[’id’]);

}} else {

die("<p>Invalid transaction!</p>");}print "<br /><hr size=1>Note: Please do not use \"Refresh\" or your browser’s back and forward buttons.<br /><font size=\"1\">This website is not a legitimate banking website and is used for experimentation only.</font>";mysql_close($link);

?>

// print the confirmation dialog<?

function printConfirmDialog($account,$amount,$id) {print "Do you wish to confirm this transaction?";print "<form action=\"confirm.php\" method=\"POST\"><table>";print "<tr><td>Account Number:</td><td>$account</td></tr>";print "<tr><td>Amount:</td><td>$amount</td></tr>";print "<tr><td>Enter Authorization Code:</td><td><input type=text name=\"authcode\" value=\"\"></td></tr>";print "<tr><td><input type=\"hidden\" name=\"id\" value=\"$id\"></td><td><input type=submit name=\"confirm\"value=\"Confirm\"></td>";

print "<td><input type=submit name=\"confirm\" value=\"Cancel\"></td></tr>";print "</table></form>";

}?>

Page 194: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

172 Appendix A. PHP Source Code of the Virtual Online Bank

A.5 Database Administarion

The following function was used to list all transactions executed by participantsin the experiment:

<?phprequire_once("password-inc.php");$sqluser="webuser";$sqlpass="********";$link = mysql_connect("localhost",$sqluser,$sqlpass) or die("Can’t connect to database!");mysql_select_db("alzomaim", $link) or die("Can’t select database!");$result=mysql_query("select * from bank order by id;");//$result=mysql_query("describe bank;");print "<table border=1>";print "<tr><td>ID</td><td>Email</td><td>A/C</td><td>Amount</td><td>Auth</td>

<td>Modified</td><td>Approved</td></tr>";while ($row=mysql_fetch_array($result)) { // ID is valid

print "<tr>";print "<td>${row[’0’]}</td>";print "<td>${row[’1’]}</td>";print "<td>${row[’2’]}</td>";print "<td>${row[’3’]}</td>";print "<td>${row[’4’]}</td>";print "<td>${row[’5’]}</td>";print "<td>${row[’6’]}</td>";print "</tr>";

}print "</table>";mysql_close($link);

?>

The next function was used to delete all the transactions’ related informationafter the completion of the experiment:

<?phprequire_once("password-inc.php");print "<h1> Confirm Delete</h1>";$sqluser="webuser";$sqlpass="********";$link = mysql_connect("localhost",$sqluser,$sqlpass) or die("Can’t connect to database!");mysql_select_db("alzomaim", $link) or die("Can’t select database!");if (isset($_REQUEST[’clear’])) {mysql_query("delete from bank;");print "database cleared.";

}print "Click \"Delete\" to clear the database.";print "<form action=\"".$_SERVER[’SCRIPT_NAME’]."\">";print "<input type=submit name=\"clear\" value=\"Delete\">";print "</form>";mysql_close($link);

?>

Page 195: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

A.5. Database Administarion 173

The deletion function above was protected by a password which was handledin the following source code:

<?php$expected_pass="1221";session_start();if (isset($_REQUEST[’pass’])) {

authUser($_REQUEST[’pass’]);}if (isset($_REQUEST[’logout’])) {

session_destroy();unset($_SESSION);

}if (!isset($_SESSION[’ok’])) {

printLoginPage();}function printLoginPage() {

print "Enter your credentials:";print "<form action=\"${_SERVER[’SCRIPT_NAME’]}\" method=\"post\">";print "password: <input type=\"password\" name=\"pass\">";print " <input type=\"submit\" name=\"submit\">";print "</form>";exit;

}function authUser($pass) {

global $expected_pass;if (strcmp($pass,$expected_pass)==0) {

echo "Authorized.";$_SESSION[’ok’]=TRUE;

}print "<form action=\"${_SERVER[’SCRIPT_NAME’]}\" method=\"post\">";print " <input type=\"submit\" name=\"logout\">";print "</form>";

}?>

Page 196: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

174 Appendix A. PHP Source Code of the Virtual Online Bank

Page 197: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

Bibliography

[1] Micosoft .NET Passport- Technical Overview. Microsoft Corporation, 2001.

[2] Baidu, Inc. (anor) v. Register.com, Inc. 10 CIV. 444 (DC), July 2010.

[3] John G. Adair. The hawthorne effect: A reconsideration of the methodolog-ical artifact. Journal of Applied Psychology, 69(2):334 – 345, 1984.

[4] A. Adams and M. A. Sasse. Users are not the enemy. Communications ofthe ACM, vol.42(no.12):40–46, 1999.

[5] G. Ahn and J. Lam. Managing Privacy Preferences for Federated IdentityManagemnt. In Proceedings of the 2005 workshop on Digital Identity man-agement, pages 28–36, New York, NY, USA 2005.

[6] K. Allendoerfer and S. Pai. Human Factors Considerations for Passwords andOther User Identification Techniques: Part 1: Literature Review and Anal-ysis. Technical report, Federal Aviation Administration William J. HughesTechnical Center, 2005.

[7] K. Allendoerfer and S. Pai. Human Factors Considerations for Passwords andOther User Identification Techniques: Part 2: Field Study, Results and Anal-ysis. Technical report, Federal Aviation Administration William J. HughesTechnical Center, 2006.

[8] Liberty Alliance. Business guidelines: Raising the business requirements forwide scale identity federation. July 2003.

[9] Liberty Alliance. Liberty ID-FF Binding and Profiles Specifications. LibertyAlliance 2004.

[10] Liberty Alliance. Liberty ID-FF Protocol and Schema Specifications. LibertyAlliance 2004.

175

Page 198: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

176 BIBLIOGRAPHY

[11] A. Alsaid and C. Mitchell. Dynamic Content attacks on Digital Signatures.Information Management & Computer Security, 13(4):328–336, 2005.

[12] P. Ashley and B. Broom. Securing networked application with sesame.LINUX Journal, 45(no.24), January 1998.

[13] D. Balfanz, G. Durfee, D. K. Smetters, and R. E. Grinter. In search of usablesecurity: five lessons from the field. Security and Privacy Magazine, IEEE,vol.2(no.5):19–24, 2004.

[14] BBC. Trojan virus steals banking info. http://news.bbc.co.uk/2/hi/7701227.stm, Obtober 2008.

[15] Hal Berghel. Phishing mongers and posers. Commun. ACM, 49(4):21–25,2006.

[16] L. Blaxter, C. Hughes, and M. Tight. How to research. Open UniversityPress, Maidenhead, Berks, 2006.

[17] Johan Borst, Bart Preneel, Joos Vandewalle, and Joos V. On the time-memory tradeoff between exhaustive key search and table precomputation.In Proc. of the 19th Symposium in Information Theory in the Benelux, WIC,pages 111–118, 1998.

[18] Xavier Boyen. Hidden credential retrieval from a reusable password. In ASI-ACCS ’09: Proceedings of the 4th International Symposium on Information,Computer, and Communications Security, pages 228–238, New York, NY,USA, 2009. ACM.

[19] Hans Brandl. Trusted Computing: The TCG Trusted Platform ModuleSpecification. white paper: Infineon Technologies. http://www.infineon.com/cms/us/product, July 2006.

[20] A. Brown, E. Bracken, S. Zoccoli, and K. Douglas. Generating and re-membering passwords. Applied Cognitive Psychology, vol.18(no.6):641 – 651,2004.

[21] L.A. Bygrave. Privacy Protection in a Global Context - A ComparativeOverview. Scandinavian Studies in Law, 47:319–348, 2004.

Page 199: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

BIBLIOGRAPHY 177

[22] Jan Camenisch, abhi shelat, Dieter Sommer, et al. Privacy and identitymanagement for everyone. In DIM ’05: Proceedings of the 2005 workshopon Digital identity management, pages 20–27, 2005.

[23] Kim Cameron. The Laws of identity. http://msdn2.microsoft.com/en-us/library/ms996456.aspx. accessed by 15/1/2007, May 2005.

[24] Donald Campbell and Julian Stanley. Experimental and Quasi-ExperimentalDesigns for Research. Wadsworth Publishing, ISBN-13: 978-0395307878,July 1963.

[25] D. Carstens, P. McCauley-Bell, and L. Malone. Development of a model fordetermining the impact of password authentication practices on informationsecurity. In Proceedings of the International Ergonomics Association /Hu-man Factors and Ergonomics Society 44th Annual Meeting, pages 342–345,2005.

[26] M. Casassa Mont, P. Bramhall, M. Gittler, J. Pato, and O. Rees. IdentityManagement: a Key e-Business Enabler. Hewlett-Packard Laboratories,Bristol, UK, June 2002.

[27] A. Cavoukian and M. Crompton. Web Seals: A Review of Online PrivacyPrograms. A Joint Project of The Office of the Information and PrivacyCommissioner/Ontario and The Office of the Federal Privacy Commissionerof Australia, http://www.ipc.on.ca/images/resources/up-seals.pdf accessedby 15/2/2007, Venice, September 2000.

[28] David Challener, Kent Yoder, Ryan Catherman, David Safford, and Leen-dert Van Doorn. A Practical Guide to Trusted Computing. IBM Press, ISBN:0-13-239842-7, 2007.

[29] David Chappel. Introducing Windows CardSpace. http://msdn.microsoft.com/library/en-us/dnlong/html/introinfocard.aspaccessedby15/2/2007, April 2006.

[30] S. Cheng, S. Shieh, W. Yang, F. Lee, and J. Luo. Designing AuthenticationProtocols for Third Generation Mobile Communication Systems. Journal ofInformation Science and Engineering 21, March 2005.

Page 200: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

178 BIBLIOGRAPHY

[31] Sonia Chiasson, Robert Biddle, and P. C. van Oorschot. A second look atthe usability of click-based graphical passwords. In SOUPS ’07: Proceedingsof the 3rd symposium on Usable privacy and security, pages 1–12, New York,NY, USA, 2007. ACM.

[32] S. Clauss, D. Kesdogan, and T. Kolsch. Privacy Enhancing Identity Man-agemnt: Protection Against Re-identification and Profiling. In Proceedingsof the 2005 workshop on Digital Identity management. pages [84Ű93], NewYork, NY, USA 2005.

[33] Federal Trade Commission. 2006 Identity Theft Survey Report. http://www.ftc.gov/os/2007/11/SynovateFinalReportIDTheft2006.pdf,November 2007.

[34] Computing Technology Industry Association (CompTIA). Committingto Security: A CompTIA Analysis of IT Security and the Workforce.http://www.comptia.org, Oakbrook Terrace, IL (US), 2002.

[35] Fred Cooperstock. GENERAL RELATIVISTIC DYNAMICS ExtendingEinstein’s Legacy Throughout the Universe. World Scientific Publishing,ISBN-13: 978-9814271165, Jun 2009.

[36] Microsoft Corporation. A Technical Reference for InfoCard v1.0 in Windows.Microsoft Corporation 2005.

[37] Microsoft Corporation and Ping Identity Corporation. A Guide to Integrat-ing with InfoCard v1.0. Microsoft and Ping Identity Corporation 2005.

[38] Nokia Corporation. Protect Your Data With Remote Lock. http://nokiae50.info/articles/protect-your-data-with-remote-lock, Jan-uary, 2007.

[39] T. Daemen and I. Rubinstein. The Identity Metasystem: Towards a Privacy-Compliant Solution to the Challenges of Digital Identity. white paper: Mi-crosoft Corporation, October 2006.

[40] Homeland Security Daily. Open Source Infrastructure Report.http://osd.gov.com/osd/200908_August/DHS_Daily_Report_2009-08-03.pdf, 2009.

Page 201: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

BIBLIOGRAPHY 179

[41] Darren Davis, Fabian Monrose, and Michael K. Reiter. On user choice ingraphical password schemes. In SSYM’04: Proceedings of the 13th conferenceon USENIX Security Symposium, pages 11–11, Berkeley, CA, USA, 2004.USENIX Association.

[42] J. de Clercq and J. Rouault. An Introduction to Identity Management.Technical report, Hewlett-Packard Company, June 2004.

[43] D. Del Vecchio, J. Basney, and N. Nagaratnam. CredEx: User-Centric Cre-dential Management for Grid and Web Services. In Proceedings of IEEEInternational Conference on Web Services, pages 149–156, Orlando, Florida,July 2005.

[44] US Department of Justice. Office of the Inspector General. The Departmentof JusticeŠs Efforts to Combat Identity Theft. http://www.justice.gov/oig/reports/plus/a1021.pdf, March 2010.

[45] R. Dhamija and A. Perrig. Deja Vu: a user study using images for authen-tication. In Proceedings of the Ninth USENIX Security Symposium, pages45–58, Denver, CO, USA 2000.

[46] Rachna Dhamija and Adrian Perrig. Déjà vu: a user study using images forauthentication. In SSYM’00: Proceedings of the 9th conference on USENIXSecurity Symposium, pages 4–4, Berkeley, CA, USA, 2000. USENIX Associ-ation.

[47] Rachna Dhamija and J. D. Tygar. The battle against phishing: Dynamicsecurity skins. In SOUPS ’05: Proceedings of the 2005 symposium on Usableprivacy and security, pages 77–88, New York, NY, USA, 2005. ACM.

[48] Rachna Dhamija, J. D. Tygar, and Marti Hearst. Why phishing works.In Proceedings of the SIGCHI conference on Human Factors in computingsystems, CHI ’06, pages 581–590, New York, NY, USA, 2006. ACM.

[49] Yun Ding and Patrick Horster. Undetectable on-line password guessing at-tacks. SIGOPS Oper. Syst. Rev., 29(4):77–86, 1995.

[50] P. Dourish and D. Redmiles. An Approach to Usable Security Based onEvent Monitoring and Visualization. In Proceedings of the New SecurityParadigms Workshop, pages 75–81. ACM Press, 2002.

Page 202: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

180 BIBLIOGRAPHY

[51] I. Drokov, E. Punskaya, and E. Tahar. System and Method For DynamicMultifactor Authentication. US Patent No. US 2008/0307515 A1. http://www.freepatentsonline.com/y2008/0307515.html, December 2008.

[52] Eclipsepedia. Introduction to higgins. http://wiki.eclipse.org/index.php/Introduction_to_Higgins, November 2006.

[53] Eclipsepedia. Higgins architecture. http://wiki.eclipse.org/index.php/Architecture,2007.

[54] Marlena Erdos and Scott Cantor. Shibboleth-architecture draft v05draft-internet2-shibboleth-architecture-05.html. http://shibboleth.internet2.edu/docs/draft-internet2-shibboleth-arch-v05.pdf,2002.

[55] FBI. Cyber Banking Fraud. Global Partnerships Lead to Ma-jor Arrests. http://www.fbi.gov/news/stories/2010/october/cyber-banking-fraud, October 2010.

[56] Dinei Florêncio, Cormac Herley, and Baris Coskun. Do strong web passwordsaccomplish anything? In HOTSEC’07: Proceedings of the 2nd USENIXworkshop on Hot topics in security, pages 1–6, Berkeley, CA, USA, 2007.USENIX Association.

[57] The Organization for Economic Cooperation and Development (OECD).Guidelines on the Protection of Privacy and Transborder Flows ofPersonal Data. http://www.oecd.org/document/18/0,3343,en_2649_34255_1815186_1_1_1_1,00.html, 1980.

[58] Shirley Gaw and Edward W. Felten. Password management strategies foronline accounts. In SOUPS ’06: Proceedings of the second symposium onUsable privacy and security, pages 44–55, New York, NY, USA, 2006. ACM.

[59] Philipp Gühring. Concepts against Man-in-the-Browser Attacks. White pa-per: http://www.cacert.at/svn/sourcerer/CAcert/SecureClient.pdf,January 2007.

[60] Li Gong. Optimal authentication protocols resistant to password guessingattacks. In CSFW ’95: Proceedings of the 8th IEEE workshop on Com-

Page 203: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

BIBLIOGRAPHY 181

puter Security Foundations, page 24, Washington, DC, USA, 1995. IEEEComputer Society.

[61] W. Thomas Griffith. The Physics of Everyday Phenomena: A ConceptualIntroduction to Physics. McGraw-Hill Higher Education, ISBN-13: 978-0072828627, May 2006.

[62] Trusted Computing Group. TPM Main Specification, Level 2 Ver-sion 1.2, Revision 103. Trusted Computing Group. http://www.trustedcomputinggroup.org/resources/tpm_main_specification,2006.

[63] Trusted Computing Group. TCG Mobile Reference Architecture, Specifi-cation version 1.0, Revision 1. Trusted Computing Group. http://www.trustedcomputinggroup.org/developers/mobile, 2007.

[64] Trusted Computing Group. TCG Specification Architecture Overview.Specification Revision 1.4. Trusted Computing Group. http://www.trustedcomputinggroup.org/resources, August 2007.

[65] Trusted Computing Group. TCG Mobile Phone Work Group.http://www.trustedcomputinggroup.org/developers/mobile, 2008.

[66] Trusted Computing Group. TCG Mobile Trusted Module Specifica-tion, version 1.0, Revision 6. Trusted Computing Group. http://www.trustedcomputinggroup.org/developers/mobile, 2008.

[67] Trusted Computing Group. Summary Of Features Under Consid-eration For The Next Generation Of TPM. Trusted ComputingGroup. http://www.trustedcomputinggroup.org/developers/trusted_platform_module, 2009.

[68] N. Haller, C. Metz, P. Nesser, and M. Straw. A one-time password system,1998.

[69] The Tech Herald. ZBot data dump discovered with over 74,000 FTP cre-dentials. http://www.thetechherald.com/article.php/200927/3960/ZBot-data-dump-discovered-with-over-74-000-FTP-credentials,June 2009.

Page 204: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

182 BIBLIOGRAPHY

[70] Cormac Herley. So long, and no thanks for the externalities: the rationalrejection of security advice by users. In NSPW ’09: Proceedings of the 2009workshop on New security paradigms workshop, pages 133–144, New York,NY, USA, 2009. ACM.

[71] J. Herrera-Joancomarti and J. Prieto-Blazques. A Personal AuthenticationScheme Using Mobile Technology. In Proceedings of the International Con-ference on Information Technology: Computers and Communications, pages253–259, Los Alamitos, CA, USA 2003.

[72] Morten Hertzum, Niels Christian Juul, Niels Jørgensen, and Mie Nørgaard.Usable security and e-banking: Ease of use vis-à-vis security. Technicalreport, Australasian Journal of Information Systems, 2004.

[73] David H. Holtzman. Privacy Lost: How Technology Is Endangering YourPrivacy. Jossey-Bass, 2006.

[74] Internet Crime Complaint Center. IC3. 2009 Internet Crime Report. http://www.ic3.gov/media/annualreport/2009_IC3Report.pdf, March 2009.

[75] Apple Inc. iPhone User Guide For iPhone OS 3.1 Software. http://manuals.info.apple.com/en_US/iPhone_User_Guide.pdf, 2009.

[76] Apple Inc. iPhone in Business. Security Overview. http://images.apple.com/iphone/business/docs/iPhone_Security.pdf, June 2010.

[77] Apple Inc. iPhone-3gs specs. http://www.apple.com/iphone/iphone-3gs/specs.html, August, 2010.

[78] Apple Inc. iPhone4 specs. http://www.apple.com/iphone/specs.html,August, 2010.

[79] Philip G. Inglesant and M. Angela Sasse. The true cost of unusable passwordpolicies: password use in the wild. In CHI ’10: Proceedings of the 28thinternational conference on Human factors in computing systems, pages 383–392, New York, NY, USA, 2010. ACM.

[80] Wordcraft international limited. ocrNow!, an OCR iPhone’s application.http://www.wordcraft.com, August, 2010.

Page 205: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

BIBLIOGRAPHY 183

[81] ISO. ISO 9241-11: Ergonomic requirements for office work with visual dis-play terminals (VDTs - Part 11: Guidance on Usability. International Or-ganisation for Standardization, 1998.

[82] H. Jiang. Reliability, costs and delay performance of sending short messageservice in wireless systems. Universal Personal Communications, vol.2:1073–1077, 1998.

[83] A. Jøsang, B. Alfayyadh, T. Grandison, M. Alzomai, and J. McNamara.Security Usability Principles for Vulnerability Analysis and Risk Assessment.In The Proceedings of the Annual Computer Security Applications Conference(ACSAC’07), Miami Beach, December 2007.

[84] A. Jøsang, M. Alzomai, and S. Suriadi. Usability and Privacy in IdentityManagement Architectures. In The Proceedings of the Australasian Infor-mation Security Workshop, 2007.

[85] A. Jøsang, J. Fabre, B. Hay, J. Dalziel, and Pope S. Trust Requirements inIdentity Managemnt. In Proceedings of the Australasian Information SecurityWorkshop., pages 99–108, Newcastle, Australia, February 2005.

[86] A. Jøsang, P.M. Møllerud, and E. Cheung. Web Security: The EmperorsNew Armour. In Proceedings of the European Conference on InformationSystems (ECIS2001), Bled, Slovenia, June 2001.

[87] A. Jøsang and S. Pope. User-Centric Identity Management. In Proceedingsof AusCERT 2005, Brisbane, Australia, May 2005.

[88] A. Jøsang, D. Povey, and A. Ho. What You See is Not Always What YouSign. In Proceedings of the Australian UNIX and Open Systems Users GroupConference (AUUG2002), Melbourne, September 2002.

[89] K. Kain, S.W. Smith, and R. Asokanm. Digital Signatures and ElectronicDocuments: A Cautionary Tale. In Proceedings of IFIP Conference on Com-munications and Multimedia Security.

[90] Dave Kearns. What is user-centric identity. In Network World, July 2006.

[91] Gershon Kedem and Yuriko Ishihara. Brute force attack on unix passwordswith simd computer. In SSYM’99: Proceedings of the 8th conference on

Page 206: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

184 BIBLIOGRAPHY

USENIX Security Symposium, pages 8–8, Berkeley, CA, USA, 1999. USENIXAssociation.

[92] Auguste Kerckhoffs. English Translation of Kerckhoffs’ security principles.http://www.petitcolas.net/fabien/kerckhoffs/#english.

[93] Auguste Kerckhoffs. La cryptographie militaire. Journal des sciences mili-taires, IX(38):5–38 (January) and 161–191 (February), 1883. Available at F.Petitcola’s Website: http://www.cl.cam.ac.uk/∼fapp2/kerckhoffs/.

[94] M. Koch and K. Moslein. Identities management for e-commerce and col-laboration applications. International Journal of Electronic Commerce,vol.9(3):11–29, 2005.

[95] M. Koch and W. Worndl. Community Support and Identity Management.In Proceedings of European Conference on Computer Support CooperativeWork, pages 319–338, Bonn, Germany, September 2001.

[96] John T. Kohl and B. Clifford Neuman. The Kerberos network authenticationservice (V5). Technical Report 1510, 1993.

[97] C. Latze and U. Ultes-Nitsche. Stronger authentication in e-commerce: howto protect even naïve user against phishing, pharming, and mitm attacks. InCSNA ’07: Proceedings of the IASTED International Conference on Com-munication Systems, Networks, and Applications, pages 111–116, Anaheim,CA, USA, 2007. ACTA Press.

[98] Ben Laurie and Abe Singer. Choose the red pill and the blue pill: a positionpaper. In Proceedings of the 2008 workshop on New security paradigms,NSPW ’08, pages 127–133, New York, NY, USA, 2008. ACM.

[99] HwanJin Lee, InKyung Jeun, Kilsoo Chun, and Junghwan Song. A new anti-phishing method in openid. In Proceedings of the 2008 Second InternationalConference on Emerging Security Information, Systems and Technologies,pages 243–247, Washington, DC, USA, 2008. IEEE Computer Society.

[100] Liberty-Alliance. Liberty ID-FF Architecture Overview. Version: 1.2-errata-v1.0. http://www.projectliberty.org/specs/liberty-idff-arch-overview-v1.2.pdf accessed by 15/2/2007, Liberty Alliance 2003.

Page 207: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

BIBLIOGRAPHY 185

[101] Cronto Limited. The Cronto system. http://www.cronto.com, August,2010.

[102] H. Lockhart, S. Andersen, et al. Web Services Federation Language (WS-Federation) version 1.1. December, 2006.

[103] Mark Looi. Enhanced Authentication services for Internet Systems usingMobile Networks. In Proceedings of the IEEE Global TelecommunicationConference (GLOBECOM’01) volume 6 pages 3468-3472, Bristol, UnitedKingdom, November 2001.

[104] P. Madsen, Y. Koga, and K. Takahashi. Federated Identity Managemntfor Protecting users from Id theft. In Proceedings of the 2005 workshop onDigital Identity management, pages 77–83, New York, NY, USA 2005.

[105] Paul Madsen. Liberty Alliance Project- liberty alliance and ws-federation:A compatitve overview. Technical report, Liberty Alliance, 2003.

[106] Mohammad Mannan and P. C. van Oorschot. Security and usability: thegap in real-world online banking. In Proceedings of the 2007 Workshop onNew Security Paradigms, NSPW ’07, pages 1–14, New York, NY, USA, 2008.ACM.

[107] G. Miller. The magical number seven, plus or minus two: Some limits onour capacity for processing information. The Psychological Review, 63:81–97,1956.

[108] Chris Mitchell. Trusted computing. London : Institution of Electrical Engi-neers, 2005.

[109] Kevin D. Mitnick and William L. Simon. The Art of Deception: Controllingthe Human Element of Security. Wiley., 2002.

[110] Donald A. Norman. The Psychology of the Everyday Things, Basic Books.New York, NY (US), 2001.

[111] Gilbert Notoatmodjo. Exploring the Weakest Link: A Study of PersonalPassword Security. PhD thesis, University of Auckland, July 2007.

[112] OASIS. Differences between OASIS Security Assertion Markup Language(SAML) V1.1 and V1.0. OASIS, May 2003.

Page 208: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

186 BIBLIOGRAPHY

[113] OASIS. Assertion and Protocols for the OASIS Security Assertion MarkupLanguage (SAML) V2.0. OASIS, March 2005.

[114] OASIS. Binding for the OASIS Security Assertion Markup Language(SAML) V2.0. OASIS, March 2005.

[115] OASIS. Conformance Requirements for the OASIS Security AssertionMarkup Language (SAML) V2.0, Committee Draft. Organization for theAdvancement of Structured Information Standards, 15 January 2005.

[116] OASIS. Profiles for the OASIS Security Assertion Markup Language (SAML)V2.0. OASIS, March 2005.

[117] The Department of Homeland Security. National Strategy for Trusted Iden-tities in Cyberspace. http://www.dhs.gov/xlibrary/assets/ns_tic.pdf,June 2010.

[118] National Institute of Standards and Technology. Security Requirementsfor Cryptographic Modules. FIPS PUB 140-2. Federal Information Process-ing Standards Publication. http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf, May 2001.

[119] Office of the Privacy Commissioner. Information Privacy Principles underthe Privacy Act 1988. http://www.privacy.gov.au/publications/ipps.html,2008.

[120] Office of the Privacy Commissioner. National Privacy Principles forprivate sector organizations. http://www.privacy.gov.au/materials/types/infosheets/view/6583, 2008.

[121] OpenID. OpenID Foundation website. http://openid.net/, Last accessedJanuary 2011.

[122] S. Pearson. Trusted Agents that Enhance User Privacy by Self-Profiling.Hewlett-Packard Laboratories, Bristol, UK, July 2002.

[123] Siani Pearson, Boris Balacheff, Liqun Chen, David Plaquin, and GaemeProudler. Trusted computing platforms : TCPA technology in context. UpperSaddle River, N.J. : Prentice Hall PTR, 2003.

Page 209: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

BIBLIOGRAPHY 187

[124] John Sören Pettersson, Simone Fischer-Hübner, et al. Making prime usable.In SOUPS ’05: Proceedings of the 2005 symposium on Usable privacy andsecurity, pages 53–64, 2005.

[125] Benny Pinkas and Tomas Sander. Securing passwords against dictionaryattacks. In CCS ’02: Proceedings of the 9th ACM conference on Computerand communications security, pages 161–170, New York, NY, USA, 2002.ACM.

[126] S. Pradhan, E. Lawrence, and A. Zmijewska. Bluetooth as an enabling tech-nology in mobile transactions. In ITCC ’05: Proceedings of the InternationalConference on Information Technology: Coding and Computing (ITCC’05)- Volume II, pages 53–58, Washington, DC, USA, 2005. IEEE ComputerSociety.

[127] PRIME. PRIME (Privacy and Identity Management for Europe) - Archet-icture V1. PRIME Consortium, August 2005.

[128] PRIME. PRIME (Privacy and Identity Management for Europe) - WhitePaper V1. PRIME Consortium, July 2005.

[129] PRIME. PRIME (Privacy and Identity Management for Europe) - Frame-work V2. PRIME Consortium, July 2006.

[130] David Recordon and Drummond Reed. Openid 2.0: a platform for user-centric identity management. In Proceedings of the second ACM workshopon Digital identity management, DIM ’06, pages 11–16, New York, NY, USA,2006. ACM.

[131] Reuters. Hackers steal U.S. government, corporate data from PCs. http://www.reuters.com/article/idUSN1638118020070717, July 2007.

[132] Kenneth Revett. A Survey of User Authentication Based on Mouse Dynam-ics. Springer eBook, Springer, 2008.

[133] B. Riddle, M. Miron, and J. Semo. Passwords in use in a university time-sharing environment. Comput. Secur., vol.8(no.7):569–578, 1989.

[134] Thomas Gert Roessler. Identification and Authentication in Networks en-abling Single Sign-On. PhD thesis, Graz University of Technology, October2002.

Page 210: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

188 BIBLIOGRAPHY

[135] S. Ross. Security through Usability. Securius Newsletter, 4(1), 2003.

[136] Mary Ruddy, Paul Trevithick, Tony Nadalin, and Dale Olds. Higgins trustframework. Digital ID World, September 2006.

[137] M. A. Sasse and I. Flechais. Usable security: What is it? How do we get it?In L.F. Cranor and S. Garfinkel, editors, Security and Usability: DesigningSecure Systems that People Can Use. O’Reilly, 2005.

[138] M.A. Sasse. Computer Security: Anatomy of a Usability Disaster, and aPlan for Recovery. In Proceedings of the Conference on Human Factors inComputing Systems (CHI2003), (Workshop on Human-Computer Interac-tion and Security Systems), 2003.

[139] Stuart E. Schechter, Rachna Dhamija, Andy Ozment, and Ian Fischer. Theemperor’s new security indicators. In Proceedings of the 2007 IEEE Sympo-sium on Security and Privacy, SP ’07, pages 51–65, Washington, DC, USA,2007. IEEE Computer Society.

[140] K. Scheibelhoferm. Signing XML Documents and the Concept of WhatYou See Is What You Sign. Masters thesis, Graz University of Technology,Austria, 2001.

[141] B. Schneier. Secrets and Lies. John Wiley & Sons, 2000.

[142] The National Science and Technology Council (NSTC). Identity Manage-ment Task Force Report. http://www.whitehouse.gov/sites/default/files/microsites/ostp/nstc-identitymgmt-2008.pdf, September 2008.

[143] The security division of EMC. RSA SecurID Two-factor Authentication.http://www.rsa.com/products/securid/sb/10695_SIDTFA_SB_0210.pdf.

[144] Congressional Research Service. The Economic Impact of Cyber-Attacks.http://www.cisco.com/warp/public/779/govtaffairs/images/CRS_Cyber_Attacks.pdf, April 2004.

[145] Richard Shay, Saranga Komanduri, Patrick Gage Kelley, Pedro GiovanniLeon, Michelle L. Mazurek, Lujo Bauer, Nicolas Christin, and Lorrie FaithCranor. Encountering stronger password requirements: user attitudes andbehaviors. In SOUPS ’10: Proceedings of the Sixth Symposium on UsablePrivacy and Security, pages 1–20, New York, NY, USA, 2010. ACM.

Page 211: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

BIBLIOGRAPHY 189

[146] R. Shirey. Internet Security Glossary, Version 2. RFC 4949 (Informa-tional). Internet Engineering Task Force (IETF). http://www.ietf.org/rfc/rfc4949.txt, August 2007.

[147] Ben Shneiderman. Designing the User Interface: Strategies for EffectiveHuman-Computer Interaction. Addison-Wesley Longman Publishing Co.,Inc., Boston, MA, USA, 1997.

[148] D.K. Smetters and R.E. Grinter. Moving from the Design of Usable SecurityTechnologies to the Design of Useful Secure Applications. In Proceedings ofthe New Security Paradigms Workshop, pages 82–89. ACM Press, 2002.

[149] Adrian Spalka, Armin B. Cremers, and Hanno Langweg. The fairy tale of‘What You See Is What You Sign - Trojan Horse Attacks on Software forDigital Signatures. In IFIP Working Conference on Security and Control ofIT in Society-II (SCITS-II), Bratislava, Slovakia, June 2001.

[150] S. Stamm, Z. Ramzan, and M. Jakobsson. TR641: Drive-By Pharming.Technical report, Indian University, Department of Computer Science, 2006.

[151] Brett Stone-Gross, Marco Cova, Lorenzo Cavallaro, Bob Gilbert, MartinSzydlowski, Richard Kemmerer, Christopher Kruegel, and Giovanni Vigna.Your botnet is my botnet: analysis of a botnet takeover. In CCS ’09: Pro-ceedings of the 16th ACM conference on Computer and communications se-curity, pages 635–647, New York, NY, USA, 2009. ACM.

[152] Furkan Tari, A. Ant Ozok, and Stephen H. Holden. A comparison of per-ceived and real shoulder-surfing risks between alphanumeric and graphicalpasswords. In SOUPS ’06: Proceedings of the second symposium on Usableprivacy and security, pages 56–66, New York, NY, USA, 2006. ACM.

[153] Infineon Technologies. Infineon Trusted Platform Module connected to theVeriSign Certificate Infrastructure. white paper: Infineon Technologies.http://www.infineon.com/cms/us/product, March 2006.

[154] L. Todd Heberlein and M. , Bishop. Attack class: Address spoofing. InProceedings of the 19th National Information Systems Security Conference,page 371Ű377, Baltimore, MD, USA, 1996.

Page 212: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

190 BIBLIOGRAPHY

[155] A. Tsow, M. Jakobsson, L. Yang, and S. Wetzel. Warkitting: Thedrive-by subversion of wireless home routers. Digital Forensic Practice,vol.1(no.3):179 – 192, 2006.

[156] V. Vaishmavi and B. Kuechler. Design Research in Information Systems.Association For Information Systems, January 2004.

[157] Matt Walker. PassWindow: Simple and secure online authentication.http://www.passwindow.com/index.html.

[158] Thomas Wason, Scott Cantor, et al. Liberity ID-FF Archeticture Overview.Liberity Alliance, 2004.

[159] Arnd Weber. See What You Sign: Secure Implementations of Digital Sig-natures. In Proceedings of the International Conference on Intelligence andServices in Networks, pages 509–520, 1998.

[160] A. Whitten. Making Security Usable. PhD thesis, School of Computer Sci-ence, Carnegie Mellon University, 2004.

[161] A. Whitten and J.D. Tygar. Usability of Security: A Case Study. Com-puter Science Technical Report CMU-CS-98-155, Carnegie Mellon Univer-sity, 1998.

[162] A. Whitten and J.D. Tygar. Why Johnny Can’t Encrypt: A Usability Eval-uation of PGP 5.0. In Proceedings of the 8th USENIX Security Symposium,pages 169–184, Washington, D.C., August 1999.

[163] Susan Wiedenbeck, Jim Waters, Jean-Camille Birget, Alex Brodskiy, andNasir Memon. Authentication using graphical passwords: effects of toleranceand image choice. In SOUPS ’05: Proceedings of the 2005 symposium onUsable privacy and security, pages 1–12, New York, NY, USA, 2005. ACM.

[164] Susan Wiedenbeck, Jim Waters, Leonardo Sobrado, and Jean-Camille Bir-get. Design and evaluation of a shoulder-surfing resistant graphical passwordscheme. In AVI ’06: Proceedings of the working conference on Advanced vi-sual interfaces, pages 177–184, New York, NY, USA, 2006. ACM.

[165] Min Wu, Robert C. Miller, and Simson L. Garfinkel. Do security toolbarsactually prevent phishing attacks? In Proceedings of the SIGCHI conference

Page 213: Identity Management: Strengthening One-Time Password Authentication through Usability · 2011-09-27 · Identity Management: Strengthening One-Time Password Authentication through

BIBLIOGRAPHY 191

on Human Factors in computing systems, CHI ’06, pages 601–610, New York,NY, USA, 2006. ACM.

[166] Heng Yin, Dawn Song, Manuel Egele, Christopher Kruegel, and Engin Kirda.Panorama: capturing system-wide information flow for malware detectionand analysis. In CCS ’07: Proceedings of the 14th ACM conference on Com-puter and communications security, pages 116–127, New York, NY, USA,2007. ACM.

[167] M.E. Zurko and R.T. Simon. User-Centered Security. In C. Meadows, editor,Proc. of the 1996 New Security Paradigms Workshop, pages 27–33. ACM,1996.