Thesis

Context-aware multifactor authentication for the augmented human

HUSEYNOV, Emin

Abstract

Multi-factor authentication is currently one of the de-facto standards for systems requiring strong security. In most of the cases, multi-factor authentication is rather complex and not very user-friendly, as it requires additional steps as far as end-users are concerned: e.g. with two-factor authentication, in addition to entering a username and a password (usually considered as a first factor), users need to manually enter an additional code (second factor) that they either receive by text messages, look up in a previously printed list of passwords or generated by a hardware or software token. An extensive review of potential security risks that multi-factor authentication is capable of mitigating is a significant part of this thesis. The thesis will review phishing as one of the biggest end-user targeted attacks and describe the security risks as well as modern methods of such attacks that can potentially lead to theft of sensitive data, such as user credentials, passwords and/or credit card information. The main purpose of this research is to review existing multi-factor authentication systems, primarily in corporate [...]

Reference

HUSEYNOV, Emin. Context-aware multifactor authentication for the augmented human. Thèse de doctorat : Univ. Genève, 2020, no. SdS 149

URN : urn:nbn:ch:unige-1358289 DOI : 10.13097/archive-ouverte/unige:135828

Available at: http://archive-ouverte.unige.ch/unige:135828

Disclaimer: layout of this document may differ from the published version.

1 / 1 Context-Aware Multi- factor Authentication for the Augmented Human THÈSE présentée à la Faculté des sciences de la société de l’Université de Genève par Emin Huseynov

sous la codirection de Dr. Jean-Marc Seigneur, Prof. Giovanna Di Marzo Serugendo

pour l’obtention du grade de Docteur ès sciences de la société mention Systèmes d’information

Membres du jury de thèse: Prof. Jean-Henry Morin (Président du jury), CUI, Université de Genève Dr. Jean-Marc Seigneur (Co-directeur de thèse), CUI, Université de Genève Prof. Giovanna Di Marzo Serugendo (Co-directrice de thèse), CUI, Université de Genève Prof. Sviatoslav Voloshynovskiy, CUI, Université de Genève Prof. Alessandro Aldini, Information Science and Technology Institute, University of Urbino

Thèse no 149 Genève, 12 05 2020 ii Context-Aware Multi-factor Authentication for the Augmented Human

La Faculté des sciences de la société, sur préavis du jury, a autorisé l’impression de la présente thèse, sans entendre, par-là, émettre aucune opinion sur les propositions qui s’y trouvent énoncées et qui n’engagent que la responsabilité de leur auteur.

Genève, le 14 05 2020

Le doyen Bernard DEBARBIEUX

Impression d'après le manuscrit de l'auteur

Résumé iii

Table of Contents

Résumé ...... viii Abstract ...... xi Acknowledgements ...... xiii Acronyms ...... xiv Publications ...... xv Chapter 1. Introduction ...... 1 1.1 Purpose of this research ...... 1 1.2 Risks overview ...... 1 1.3 Context definitions ...... 1 1.4 Organization of This Thesis ...... 2 Chapter 2. Research framework ...... 3 2.1 Research flow model ...... 6 2.2 Gap analysis ...... 6 2.3 Validation framework ...... 7 2.4 Solutions implementation principles ...... 8 2.5 Potential security risks overview ...... 9 2.5.1 Introduction ...... 9 2.5.2 Background ...... 9 2.5.2.1 Targeting victims: phishing or spear phishing ...... 9 2.5.2.2 Phishing email – reaching the victim ...... 10 2.5.2.3 Attacks using network equipment ...... 10 2.5.2.3.1 Free Wi-Fi networks with Fake captive portals ...... 10 2.5.2.3.2 Modem and routers exploits ...... 11 2.5.2.4 Phishing page – the final destination ...... 11 2.5.3 Anatomy of a phishing page ...... 11 2.5.3.1 The URL ...... 12 2.5.3.2 Long subdomains technique ...... 13 2.5.3.3 Homograph attack ...... 14 2.5.3.4 “Secure” phishing...... 14 2.5.3.5 Tools for phishing attacks ...... 15 2.5.4 Summary ...... 17 Chapter 3. Review of existing MFA systems ...... 18 3.1 TOTP algorithm and implementation overview ...... 18 3.2 Classic multi-factor authentication systems and solutions ...... 20 3.2.1 Hardware tokens...... 20 3.2.2 Software tokens ...... 22 3.2.3 Alternative types of strong authentication ...... 24 3.2.3.1 SMS based strong authentication ...... 25 3.2.3.2 Paper based MFA systems ...... 25 3.2.3.2.1 PMFA Concept ...... 27 3.3 Modern multi-factor authentication systems and solutions ...... 30 3.3.1 Programmable tokens: a compromise between software and hardware tokens 30 3.3.1.1 Programmable tokens provisioning guide sample ...... 33 iv Context-Aware Multi-factor Authentication for the Augmented Human

3.3.1.2 Programmable tokens vs classic tokens – user self-service aspect 37 3.3.2 Solutions based on static or pseudo-dynamic context ...... 40 3.3.3 Dynamic Context ...... 42 3.3.4 Bluetooth Low Energy based solutions ...... 42 3.3.5 Wi-Fi based solutions ...... 43 3.3.6 Sound as a context ...... 43 3.4 Review of existing solutions and gap analysis ...... 45 Chapter 4. Our New MFA Solutions ...... 48 4.1 Review of the improvement areas ...... 48 4.2 Beacon AuthPath - Augmented Human Path Authentication ...... 49 4.2.1 Introduction ...... 49 4.2.2 Related Work ...... 49 4.2.3 Beacon Authpath Model ...... 50 4.2.3.1 “Beacon AuthPath” with standard beacons ...... 50 4.2.3.2 “Beacon AuthPath” with “smart” beacons ...... 51 4.2.4 Beacon Authpath Prototype Implementation and Validation ...... 53 4.2.5 Summary ...... 54 4.3 Physical presence verification using TOTP and QR codes ...... 54 4.3.1 Introduction ...... 54 4.3.2 Concept ...... 54 4.3.3 Implementation ...... 55 4.3.4 Proof-of-concept device ...... 55 4.3.5 Summary ...... 56 4.4 WifiOTP: Pervasive Two-Factor Authentication Using Wi-Fi SSID Broadcasts ...... 57 4.4.1 Related Work ...... 57 4.4.2 About WiFiOTP Solution ...... 58 4.4.2.1 System model ...... 58 4.4.2.2 One-Time password generation and encryption ...... 61 4.4.3 Evaluation of WiFiOTP Solution ...... 62 4.4.3.1 WiFiOTP Token ...... 62 4.4.3.2 WiFiOTP Client applications ...... 64 4.4.4 WifiOTP Use cases...... 68 4.4.4.1 Use case 1: Minimal user interaction...... 69 4.4.4.2 Use case 2: Zero user interaction ...... 70 4.4.4.3 Summary of reviewed use cases...... 71 4.4.5 Security analysis ...... 72 4.4.6 Summary ...... 72 4.5 Hardware token provisioning with the full control of the seeds ...... 73 4.5.1 Token2 TOTP Toolset ...... 74 4.5.2 Secure hardware token provisioning with Token2 TOTP Toolset ..... 74 4.6 miniOTP-2 — a programmable hardware token with time synchronization 75 4.6.1 Time drift: a major downside of TOTP hardware tokens ...... 75 4.6.2 MiniOTP-2 as a Potential Solution...... 76 4.6.3 Summary ...... 77 Résumé v

4.7 TOTPRadius: Enhancing RADIUS-based MFA authentication systems with RESTful API for self-service enrolment ...... 78 4.7.1 Introduction ...... 78 4.7.2 Review of existing implementations ...... 79 4.7.3 Use case review: Migration from classic to multifactor authentication 80 4.7.4 A theoretical model of self-service enrollment for RADIUS-based two- factor authentication ...... 81 4.7.4.1 Initial login concept ...... 81 4.7.4.2 Self-service enrollment concept ...... 82 4.7.5 Proof of concept...... 83 4.7.5.1 Self-enrollment RESTful API ...... 84 4.7.5.2 Implementation of Proof of Concept ...... 85 4.7.6 Security analysis and summary ...... 85 Chapter 5. Validation of the results and comparative summary ...... 86 5.1 User experience survey ...... 87 5.1.1 Purpose of the survey ...... 87 5.1.2 Components ...... 88 5.1.3 Survey scenario ...... 89 5.1.4 Capturing the results ...... 91 5.1.5 Results ...... 91 5.2 Survey Results Analysis ...... 91 5.3 Commercialization ...... 93 5.3.1 Results ...... 93 Chapter 6. Conclusion and Future work ...... 94 6.1 Conclusion ...... 94 6.1.1.1 Apply the MFA wherever possible ...... 95 6.1.1.2 Use context as an additional factor ...... 95 6.1.1.3 Best practice approaches in the areas of user experience and user behavior 96 6.1.1.4 Best practices in the area of addressing MFA targeted risks ...... 99 6.1.2 Best practice recommendation : “Passwordless” as an alternative to MFA 100 6.2 Future work ...... 102 Chapter 7. References ...... 104

List of Tables

Table 1. Google Authenticator compared to MobileOTP ...... 24 Table 2. MFA Systems analysis ...... 45 Table 3. WifiOTP Use case comparison ...... 71 Table 4. Review of products using RADIUS as a secondary identity store ...... 79 Table 5. Justification of context type selection for the validation exercise ...... 86 Table 6. User survey results: comparative summary ...... 91 Table 7. MFA Enrollment procedure comparison ...... 98

vi Context-Aware Multi-factor Authentication for the Augmented Human

List of Figures

Figure 1. Augmented Human context factors for MFA ...... 4 Figure 2. Diagram of context types as factors for multi-factor authentication ...... 5 Figure 3. Research flow model diagram ...... 6 Figure 4. Gap analysis flowchart ...... 7 Figure 5. User acceptance validation process ...... 8 Figure 6. An example of a fake captive portal ...... 11 Figure 7. Address bar of different browsers ...... 12 Figure 8. Microsoft Office 365 Genuine and "Fake" login page comparison ...... 13 Figure 9. Very long FQDN ...... 13 Figure 10. IDN domain in an unpatched browser (first "a" is Cyrillic)...... 14 Figure 11. EV Certificate issued to "Identity Verified" company, as shown by Safari on iOS ...... 15 Figure 12. Phishing Frenzy Template gallery ...... 16 Figure 13. Gophish - Open-Source Phishing Framework. Promo Page ...... 16 Figure 14. TOTP validation flowchart ...... 20 Figure 15. A hardware token for two-factor authentication ...... 21 Figure 16. Yubico connected tokens ...... 22 Figure 17. MobileOTPv 1.07 running on a Nokia 3510 ...... 23 Figure 18. Google Authenticator mobile application for Android ...... 23 Figure 19. An example of a paper token based system ...... 26 Figure 20. One-time passwords list printed by an ATM ...... 27 Figure 21. PMFA OTP Matrix generation function ...... 28 Figure 22. Paper MFA token ...... 28 Figure 23. Classic (single-factor) authentication flowchart ...... 29 Figure 24. Authentication flowchart with MFA paper token ...... 30 Figure 25. TOTP Enrollment procedure ...... 31 Figure 26. TOTP Enrollment with programmable tokens ...... 32 Figure 27. Token2 Token Burner application ...... 33 Figure 28. Hardware tokens for Facebook, Step 1 ...... 34 Figure 29. Hardware tokens for Facebook, Step 2 ...... 35 Figure 30. Hardware tokens for Facebook, Step 3 ...... 35 Figure 31. Hardware tokens for Facebook, Step 4 ...... 36 Figure 32. Hardware tokens for Facebook, Step 5 ...... 36 Figure 33. Activating OATH hardware tokens with Azure MFA (Global Admin interface) ...... 38 Figure 34. leostick_otp hardware components...... 39 Figure 35. Temperature-based Context-Aware Authentication with BLE Beacon .... 41 Figure 36. Biometric verification in Wells Fargo mobile application ...... 42 Figure 37. Sound-based Authentication Example ...... 44 Figure 38. Watermelon 2FA System Design ...... 45 Figure 39. Diagram of context types as factors for multi-factor authentication with new solutions proposed ...... 48 Figure 40. AuthPath sequence diagram ...... 50 Figure 41. Beacon AuthPath data flow (online) ...... 51 Figure 42. Beacon AuthPath with smart beacons data flow (online and offline) ...... 52 Figure 43. AuthPath Android application interface ...... 53 Résumé vii

Figure 44. TOTP-QR action flow ...... 55 Figure 45. PoC Device for TOTP-QR solution ...... 56 Figure 46. Web application for presence verification using TOTP-QR concept ...... 57 Figure 47. WiFiOTP Logical diagram ...... 59 Figure 48. Format of the SSIDs broadcasted by WiFiOTP tokens...... 60 Figure 49. WiFiOTP Data flow model ...... 61 Figure 50. Standalone WifiOTP token based on NEXX WT3020 router ...... 63 Figure 51. WiFiOTP Token on a standalone OpenWRT device ...... 63 Figure 52. WiFiOTP Token application for Windows ...... 64 Figure 53. WiFiOTP Client for Windows ...... 65 Figure 54. WiFiOTP Android Client. Clipboard mode ...... 65 Figure 55. WiFiOTP Android Client. Web Browser mode ...... 66 Figure 56. WiFiOTP Android Custom Keyboard ...... 67 Figure 57. Custom WiFiOTP Keyboard based on English (US) layout ...... 68 Figure 58. Classic two-factor authentication flowchart ...... 69 Figure 59. Two-factor authentication flowchart with WiFiOTP Windows client ...... 70 Figure 60. Zero user interaction two-factor authentication using Android mobile application...... 71 Figure 61. Token2 TOTP Toolset ...... 74 Figure 62. Token2 Burner App with time synchronization feature ...... 76 Figure 63. An example of an authentication flow with LDAP and RADIUS identity stores ...... 80 Figure 64. Initial login authentication flow ...... 82 Figure 65. Self-service enrollment diagram ...... 83 Figure 66. TOTPRadius network diagram ...... 84 Figure 67. WifiOTP test-drive station setup ...... 89 Figure 68. Demo web application with MFA login ...... 90 Figure 69. MFA Experience of the survey respondents ...... 92 Figure 70. Comparing different MFA methods ...... 93 Figure 71. The Inevitability of the Click (Verizon Data Breach Report) ...... 94 Figure 72. Push notification-based MFA login approval ...... 97 Figure 73. Phishing landing page used to bypass 2FA ...... 100 Figure 74. "Passwordless" authentication flow presented in Microsoft whitepaper 101

viii Context-Aware Multi-factor Authentication for the Augmented Human

Résumé

Authentification Contextuelle Multi facteur pour l'Humain Augmenté L’authentification multi facteur est actuellement l’une des normes de facto pour les systèmes exigeant une sécurité renforcée. Dans la plupart des cas, l’authentification multifactorielle est plutôt complexe et peu conviviale, car elle nécessite des étapes supplémentaires en ce qui concerne les utilisateurs finaux : p. Ex. avec une authentification à deux facteurs, en plus de saisir un nom d'utilisateur et un mot de passe (généralement considéré comme un premier facteur), les utilisateurs doivent saisir manuellement un code supplémentaire (deuxième facteur) qu'ils reçoivent par messages texte. Liste de mots de passe ou générée par un jeton matériel ou logiciel. Un examen approfondi des risques de sécurité potentiels que l'authentification multifactorielle est capable d'atténuer constitue une partie importante de cette thèse. Le document examinera le phishing comme l’une des plus grandes attaques ciblées d’utilisateur final et décrira les risques de sécurité ainsi que les méthodes modernes de telles attaques pouvant potentiellement entraîner le vol de données sensibles, telles que les identifiants, mots de passe et / ou informations de carte de crédit. L'objectif principal de cette recherche est d'examiner les systèmes d'authentification multi-facteurs existants et de combler les lacunes et les insuffisances existantes en introduisant des contextes de divers types de facteurs d'authentification supplémentaires. L'objectif principal de cette recherche est de rendre le processus convivial et possible avec les technologies humaines augmentées tout en maintenant le niveau de sécurité le plus élevé possible. Ceci doit être réalisé à la fois en améliorant les systèmes existants après une évaluation critique et en proposant de nouvelles solutions pouvant améliorer l'expérience utilisateur avec l'authentification multi-facteurs. En plus d'améliorer les techniques côté client telles que les jetons matériels ou logiciels et les méthodes de transmission des facteurs d'authentification supplémentaires, les implémentations côté serveur seront également examinées. Cela permettrait d'introduire une authentification multi facteur dans les systèmes qui ne prennent pas en charge de manière native plusieurs facteurs d'authentification. Au cours de cette recherche, une approche complexe et complète de l'authentification multi-facteurs doit être utilisée pour couvrir tous les aspects et les problèmes de sécurité de chaque solution et des risques de sécurité potentiels. La recherche couvrira différents composants de ces systèmes d’authentification, tels que les composants et les logiciels, les méthodes de transfert des facteurs d’authentification de ces dispositifs et logiciels vers les principales stations d’authentification et, enfin, les serveurs d’authentification destinés à vérifier les facteurs supplémentaires soumis par les utilisateurs. L'objectif de ce travail est d'améliorer et de minimiser (idéalement de mettre à zéro) l'interaction utilisateur requise pour s'authentifier à l'aide de facteurs d'authentification supplémentaires. L'amélioration de l'expérience utilisateur est recherchée non seulement dans le contexte des processus d'authentification (c'est-à-dire, la connexion aux systèmes avec authentification multi facteur activée), mais également dans les procédures d'inscription des utilisateurs. Les recherches visant à permettre une inscription en libre-service complète pour les utilisateurs finaux visent également à examiner les solutions possibles pour minimiser la charge administrative du processus. Résumé ix

Outre les facteurs d’authentification classiques, tels que les jetons matériels, cet article étudiera les solutions modernes, dont beaucoup correspondent au concept de l’être humain amélioré, telles que les solutions introduisant des facteurs contextuels supplémentaires, d’où le titre. Le concept d'utilisation des technologies humaines augmentées dans l'authentification multifactorielle repose principalement sur l'utilisation de facteurs appartenant à un utilisateur en tant qu'être humain en tant que facteurs d'authentification supplémentaires. Des exemples de tels facteurs sont des propriétés telles que les caractéristiques biométriques, le cheminement physique des mouvements de la personne, le son qu'il produit ou entoure. Dans le cadre de cette recherche, une enquête d'acceptation des utilisateurs a également été menée afin de valider l'expérience utilisateur des solutions modernes d'authentification multifactorielle. L’enquête a été menée sous la forme d’une comparaison entre l’utilisation des méthodes d’authentification classiques et les solutions d’authentification modernes proposées comme innovations dans cette recherche.

Abstract xi

Abstract

Multi-factor authentication is currently one of the de-facto standards for systems requiring strong security. In most of the cases, multi-factor authentication is rather complex and not very user-friendly, as it requires additional steps as far as end- users are concerned: e.g. with two-factor authentication, in addition to entering a username and a password (usually considered as a first factor), users need to manually enter an additional code (second factor) that they either receive by text messages, look up in a previously printed list of passwords or generated by a hardware or software token. An extensive review of potential security risks that multi-factor authentication is capable of mitigating is a significant part of this thesis. The thesis will review phishing as one of the biggest end-user targeted attacks and describe the security risks as well as modern methods of such attacks that can potentially lead to theft of sensitive data, such as user credentials, passwords and/or credit card information. The main purpose of this research is to review existing multi-factor authentication systems, primarily in corporate applications, and overcome existing gaps and shortcomings with introducing contexts of various types of additional authentication factors. Context as a word means the influence factors and events related to a particular situation. In our case, the meaning remains the same, it is only worth mentioning that in the situation we are applying the context - it is namely the user authentication operation or sequence of operations. Also, the goal of this research is to make the process user-friendly and possible to use with Augmented Human technologies while keeping the level of security at the highest level possible. This is to be achieved by both improving existing systems after critical evaluation, as well as proposing new solutions that can improve user experience with multi-factor authentication. In addition to improving client-side techniques such as hardware or software tokens and the methods of transmitting the additional authentication factors, server-side implementations will also be reviewed. This would allow introducing multi-factor authentication in systems that are not natively supporting more than one authentication factors. During this research, a complex and comprehensive approach to multi-factor authentication is to be used to cover all aspects and security concerns of each and every solution and potential security risk. The research will cover different components of such authentication systems such as end-user facing components including but not limited to devices and software, methods of transferring authentication factors from such devices and software to main authentication stations and, finally, the authentication servers destined to verify the additional factors submitted by users. The focus of this work is to improve and minimize (ideally to zero) user interaction required to authenticate using additional authentication factors. User experience improvement is researched not only in the context of authentication processes (i.e. logging in to end systems with multifactor authentication enabled) but also the user enrollment procedures as well, so the review of administrative effort to enable strong security for end-users in corporate environments will be considered as the complexity factor. Researches toward enabling fully self-service enrollment for xii Context-Aware Multi-factor Authentication for the Augmented Human

end users are also meant to review possible solutions to minimize administrative burden of the process. In addition to classic authentication factors such as hardware tokens, this thesis will research modern solutions, many being in line with the Augmented Human concept such as solutions introducing additional innovative context factors, hence the title. The concept of using Augmented Human technologies in multifactor authentication is mainly based on using factors belonging to a user as a human being as additional authentication factors. Examples of such factors are properties such as the biometric characteristics, the physical path of the person’s movements, the sound he/she produces or surrounded with. As a part of this research, a user acceptance survey was also conducted in order to validate the user experience of modern multifactor authentication systems used by widely used corporate enterprise solutions such as Microsoft Office 365, Citrix XenApp, Google Suite, Duo and similar. The survey was conducted in a form of a comparison between using classic authentication methods and modern authentication solutions proposed as innovations within this research. The results of the survey, presented in Chapter 5, are showing higher user acceptance of the proposed novel solutions compared to classic approach.

Acknowledgements xiii

Acknowledgements

I would like to thank the people that helped me, or played an important role, in the realization of this thesis. I'd like to thank my wife, who supported and encouraged me during the realization of this PhD. She took care about my well-being, spent some extra time with our children since I had to work some evenings and some weekends, and gave me all the happiness that I needed to finish this work. xiv Context-Aware Multi-factor Authentication for the Augmented Human

Acronyms

2FA Two factor authentication NFC Near Field Communication API Application Programming OTP One-Time Password Interface PoC Proof of Concept ASCII American Standard Code for PIN Personal Identification Number Information Interchange PHP Nonsensical acronym for PHP ATM Automatic Teller Machine programming language BLE Bluetooth Low Energy QR Quick Response Code DNS Domain Name Service RFC Request for Comments DSL Digital Subscriber Line SDK Software development kit DV Domain Validated SMS Short Message Service EV Enterprise Validated SoOP Signals of Opportunity FTP File Transfer Protocol Positioning GPS Global Positioning System SSID Service set identifier HMAC Hash Message SSH Secure Shell Authentication Code SSL Secure Socket Layers HOTP HMAC-based One-time SSO Single Sign-On Password TLS Transport Layer Security IDN Internationalized domain name TOTP Time based One Time IETF Internet Engineering Task Password Force TX Transmission IP Internet Protocol URL Universal Resource Locator ISP Internet Service Provider USB Universal Serial Bus LAN Local Area Network WLAN Wireless local area network MFA Multi-factor authentication Publications xv

Publications

Published academic papers related to this Ph.D. dissertation are listed below.

• Emin Huseynov, Jean-Marc Seigneur Context-Aware Multi-Factor Authentication. Computer and Information Security Handbook, 3rd Edition. Morgan Kaufmann, 2017

• Emin Huseynov, Jean-Marc Seigneur Beacon Authpath, Augmented Human Path Authentication. Proceedings of the 10th International Conference on Application of Information and Communication Technologies, IEEE Xplore, 2016.

• Emin Huseynov, Jean-Marc Seigneur Pervasive Two-Factor Authentication Using Wi-Fi SSID Broadcasts. IEEE. Kaleidoscope International Conference. Barcelona (Spain) - 9-11 December 2015

• Emin Huseynov, Jean-Marc Seigneur Enhancing RADIUS Based Multifactor-Factor Authentication Systems with RESTful API for Self-service Enrolment. 2017 11th IEEE International Conference on Application of Information and Communication Technologies, Moscow, Russia, 2017

• Emin Huseynov Web Vulnerability-Based Spear Phishing. A modern Combination of Tools in Cyberterrorism Online Terrorist Propaganda, Recruitment, and Radicalization CRC Press, 2019

• Emin Huseynov, Jean-Marc Seigneur Physical presence verification using TOTP and QR codes 34th International Conference on ICT Systems Security and Privacy Protection - IFIP SEC 2019, Lisbon, Portugal , 2019

• Emin Huseynov, Jean-Marc Seigneur Hardware TOTP tokens with time synchronization 2019 IEEE 13th International Conference on Application of Information and Communication Technologies (AICT), Baku, Azerbaijan, 2019

Introduction 1

Chapter 1. Introduction

1.1 Purpose of this research Multi-factor authentication (MFA) is perceived by end users as rather complex and not very user-friendly, as it requires additional steps as far as end-users are concerned: e.g. with two-factor authentication, in addition to entering a username and a password (first factor), users need to manually enter an additional code (second factor) that they either receive by SMS, look up in a previously printed list of passwords or generated by a hardware or software token. The purpose of this research is to review existing multi-factor authentication systems and overcome existing gaps and shortcomings with introducing contexts of various types as additional authentication factors.

During the research, we will review examples of such projects to illustrate the principle of context-aware multi-factor authentication, primarily focusing on the technologies that augment the human, the “augmented human”. As a foreground of the research, an overview of potential risks (primarily phishing attacks) will also be reviewed.

1.2 Risks overview Digital crime and online fraud have become a threat that has already affected many people and will be highly affecting much more if no adequate mechanisms are implemented. The risk of using static passwords is simple and easy to understand, once the password is stolen nothing can stop the attackers; this thesis will review the methods that hackers use to steal passwords, such as keyloggers and phishing attacks and evaluate how MFA can effectively mitigate these risks. Phishing is the fraudulent practice of sending emails purporting to be from reputable companies in order to induce individuals to reveal personal information, such as passwords and credit card numbers. Although there are other risks where MFA can be an effective mitigation tool, phishing is still considered the main risk. As an example of this, we refer to a recent article [1] where Google informs about the success rate of phishing attacks against its employees becoming zero after enabling hardware MFA keys. “The basic idea behind two-factor authentication is that even if thieves manage to phish or steal your password, they still cannot log in to your account unless they also hack or possess that second factor”

1.3 Context definitions As the subject states, this research focuses on utilizing context as the additional authentication factors. The definitions of context may vary depending on the research areas, but broadly, context refers to different ambient conditions of the objects that are parts of the authentication mechanism. We can consider contexts to be characterized by a set of contextual predicates i.e. as information that characterizes situations of objects that are considered relevant to the user-application interaction. We will be researching context-aware

2 Context-Aware Multi-factor Authentication for the Augmented Human

methods that augment the traditional classification approach by leveraging additional information such as the location, identity and state of people, groups and computational and physical objects. In our work the following examples can be shown as context factors: a) Carried device (classic multi-factor authentication) b) Environmental (sound, light, images, videos, ambient temperature) c) Internal (Biometrics, IP address, GPS) While some of these factors, such as physical location, i.e. proximity to a certain device, will be used as the primary factor, the others will be used as additional verification or protection mechanisms in combination with the primary factor. An example of such combination is transmitting physical location together with the exact ambient temperature of a beacon device to the authenticating server that can then be verified with the same data submitted by the client trying to authenticate, to improve the security of the process and minimize data spoofing and replay attack possibilities.

1.4 Organization of This Thesis In line with the framework model proposed in Chapter 2 we will review a few aspects of potential security risks, such as phishing, to further support the idea of using MFA to protect not only from phishing but from similar attack vectors as well. This will stress the importance and the practical need of MFA systems as such. In Chapter 3, we will review and critically evaluate existing MFA systems and provide comparative analysis. The MFA systems will be structurally divided into various categories, such as Classic and Modern systems. Additionally, MFA systems will be classified based on context factors they are functioning with. Further, in Chapter 4 we will present a few new systems proposed as a part of this thesis as efforts to enhance the MFA concept as such by improving the user experience keeping the security level the same or even higher. User acceptance validation will also be provided as a part of the overall validation of both existing and newly proposed systems. Chapter 5 will provide a comparative summary of reviewed and proposed MFA solutions and provide an analysis of user experience survey results in view of these solutions And, finally, in Chapter 6 we will explain the authors’ view on the existing situation, the value of this particular research, future work as well as potential research topics in this area.

Research framework 3

Chapter 2. Research framework

This chapter provides an overview of the conceptual research framework based on the review of the related work and possible solutions in order to address the shortcomings and issues with current systems and technologies presented in the literature review. The main purpose of having a well-defined research framework is to formulate a clear scientific research approach of the theories, models, technologies and solutions reviewed, researched or applied in this research field. The framework will show the techniques to be applied in the implementation of the new proposed solutions and provide a taxonomy that distinguishes between different approaches. The first augmented human international conference started in 2010 [2].Augmented human research, in a wider context cover the modern scientific contributions in the area of augmenting human capabilities applying technology for increased well-being, improvement of people daily life and enjoyable experiences, cover the different technologies that may be used to augment humans: augmented and mixed reality [3]; head-mounted displays and smart glasses [4] ; wearable computing and smart textile [5]; Brain-Computer Interfaces (BCI) [6]; senses, muscle and implanted interfaces [7]; sensors; prosthesis, bionics and exoskeletons [8]; medicines, drugs and ingested nanorobots [9]. The main goal of this research is to make the process user-friendly and possible to use with Augmented Human technologies while keeping the level of security at the highest level possible. This is to be achieved by both improving existing systems after critical evaluation, as well as proposing new solutions that can improve user experience with multi-factor authentication. Figure 1 shows the overall picture of context factors that can be used for multi- facto authentication in the augmented human. The areas this thesis will contribute to are shown in green text, and will consist of the following: - Device possession - Augmented human path verification - Proximity to a device

4 Context-Aware Multi-factor Authentication for the Augmented Human

Figure 1. Augmented Human context factors for MFA

Unfortunately, nowadays, augmented human technologies aren’t yet available and we have to investigate the currently available technologies if we want to advance the field. In the long term, we envision that augmented humans would have many more ways of augmenting their authentication tasks, for example, based on implanted chips or advanced biometrics. The overall scope of the context factors existing in one or another form, that can be used as multifactor authentication factors are shown in Figure 2.

Research framework 5

Figure 2. Diagram of context types as factors for multi-factor authentication

A note on biometric context factors security Authentication context based on biometric identification, such as fingerprint readers or face recognition subsystems, has been getting more and more wide-spread. Modern mobile phones presently have fingerprint reader modules, and users are prompted to use them not only to unlock the devices but also to defend sensitive data such as payment information. Multiple laptops models also have built-in fingerprint readers, which are promoted as a reliable alternative to static passwords. As the recent cyber-attack against OPM [10] shows, the fingerprint-based system is flawed fundamentally. With regular passwords, if there is a suspicion of a breach and/or leak, the classic passwords can be changed immediately. This would be impossible with conventional fingerprint-based security: the fingerprints are static, and the entropy is only up to ten for most cases (well, strictly speaking, the entropy can be equal to twenty - but that is rather inconvenient for most of the users). A similar attack vector exists for most of the biometric factors. Due to the considerations stated above, the human body context factors are regarded by us as insecure, and therefore will not be included in this research.

6 Context-Aware Multi-factor Authentication for the Augmented Human

User authentication is a balance of security and user experience. This research is aiming to explore the possibilities of creating a simple and low-cost multifactor authentication system that simplifies user’s interaction compared to existing solutions by minimizing or eliminating the actions required to add the additional factors for authentication. While the main principle of the solutions proposed is on simplifying user interaction with systems requiring two-factor authentication by eliminating the need of typing OTPs manually; some of the solutions proposed also present a possibility of introducing an additional authentication factor – such as physical location of the user, ambience illumination and other similar factors.

2.1 Research flow model The existing systems as well the proposed solutions need to be reviewed in whole, a systematic approach to all research areas is inevitable. Figure 3 shows the proposed flow of the research directions based on the above-mentioned areas.

Figure 3. Research flow model diagram

Reviews of the existing solutions, as well as validations of the proposed solutions, will be reviewing the combination context and the transmission method as one multifactor authentication solution, which will allow evaluating its security and user experience via the most realistic approach (i.e. implemented as a proof-of- concept). An example of the approach presented in this research is a comparative summary of the classic hardware token-based solution and one of the modern solutions to be reviewed. The same research flow model will be used to define the areas of the research as well as to identify the areas of potential improvements in order to propose new solutions.

2.2 Gap analysis The main goal of this research is to propose new, more secure and/or more user- friendly approach to context-based multi-factor authentication. As a part of the research framework, a critical evaluation of the shortcomings and disadvantages of the existing systems, gap analysis, is proposed. This analysis will review the main aspects of each solution, identify gaps and help propose improvements in relevant areas where possible. The gap analysis diagram is shown in Figure 4. Research framework 7

Figure 4. Gap analysis flowchart The gap analysis is, ideally a continuously repeating process that is focused on achieving both the highest security level possible and the most transparent user interaction.

2.3 Validation framework Validation of achieved results and/or proposed novel solution should be an integral part of every research framework. Both the security level and the user experience level of each solution proposed. User experience level validation should be based on a combination of functional design and redesign based on pilot users’ experience as well as improvements of other factors, such as production cost, battery lifetime, physical dimensions and aesthetics. An example of such validation process is illustrated in Figure 5.

8 Context-Aware Multi-factor Authentication for the Augmented Human

Figure 5. User acceptance validation process

2.4 Solutions implementation principles Based on the research and review of existing solutions and implementations, this research will propose several new solutions in order to address the discovered shortcomings and propose improvements. Proposed solutions can be divided into the following groups: - introducing additional context factors for multi-factor authentication and - simplifying user authentication processes using alternative OTP transmission channels - simplifying user registration processes by implementing systems with self-service enrollment

Research framework 9

2.5 Potential security risks overview

2.5.1 Introduction The Internet is nowadays the centre of most people’s social and professional life, therefore protecting online identity is becoming even more critical. In addition to usual risks of being compromised, such as theft, a compromised account can be used as a ladder to perform more sophisticated attack: e.g. if the account if a regular employee in an organization is compromised, it can be used to continue the attacks using the internal vector and the internal attacks are known to be much more successful. Therefore, account compromisation is still a popular target of cyber terrorism, and the most popular way of compromising online accounts is a phishing attack. Phishing is still the most popular and most successful type of hacker attacks. Everything is simple, no software, no servers, no networks to be penetrated, because the most vulnerable components of information systems are the end- users. As a result, apart from its regular risks, a compromised email or a social network account can become a powerful tool of cyber-terrorist by exploiting the identity of another person. For this reason, accounts of popular public figures are under even more risk. In this thesis, we will describe several different techniques that modern attackers use to enhance phishing attacks and bring the success rate of such attacks to a significantly higher level by using advanced methods of crafting phishing pages; including pages created using vulnerabilities of legitimate web applications. After a brief review of existing classic methods used by phishing attacks, the thesis will review the methods of developing phishing pages with attempts to make them look like genuine ones by utilizing the vulnerabilities of different natures and on different levels, such as IDN name display method of browsers, web certificate issuance process imperfections and classic cross-site scripting vulnerabilities of web applications.

2.5.2 Background While the main goal of this thesis is describing the advanced techniques of creating the phishing pages, it is still important to understand the basics of phishing attacks.

2.5.2.1 Targeting victims: phishing or spear phishing Different from regular phishing, spear phishing attacks are targeted against a specific group of users, for example, against a particular organization. Both attacks start with an email message. However, if phishing is easier for end-users to determine because the attack is much broader, it uses fewer specifics and therefore much more suspicious, whereas spear phishing, if well crafted, can mimic legit email messages sent from help desk or system announcements. Nowadays, there are also attacks against users of a particular cloud service, that have a broader scope of targeted victims, such as users hosted on Google Apps or Microsoft Office 365. In these cases, even though the users are belonging to different organizations, the email messages and phishing pages are sharing the same design and URLs.

10 Context-Aware Multi-factor Authentication for the Augmented Human

2.5.2.2 Phishing email – reaching the victim Modern email systems can identify emails with phishing contents. However, there are techniques that allow phishers to work around these filters and succeed in getting the emails delivered the end users, such as using non-Latin characters in the message body etc., as well as using properly set up DNS infrastructure with domain names looking similar to target organization’s domain name. Another common practice for sending phishing email is to use well known and widely trusted email systems that allow free and fully anonymous online registration and are allowing sending emails without any further verification. Examples of such systems are Gmail [11] and ProtonMail [12], they both are allowing new email accounts to be registered without any additional verification, whereas, for example, Hotmail requires phone number verification before sending out the first email.

2.5.2.3 Attacks using network equipment

2.5.2.3.1 Free Wi-Fi networks with Fake captive portals

Another technique to navigate the users to a phishing page is using a special set of hardware to provide free access to the Internet with a captive portal which allows authenticating using one of the account providers. This is rather harder to implement, but technically possible if the attackers have access to the premises of the potential victims. Alternatively, this is can be a method for mass phishing if such an attack is executed in public locations such as airports and coffee shops. Users can freely connect to these networks without a password and will often be directed to a web page where authentication required before being allowed to browse the web. As an alternative to regular authentication methods, the captive portal offers to use an existing social network such as Facebook or LinkedIn, or other widely used authentication source such as Google, Azure or Dropbox; but instead of redirecting to relevant services using common authentication schemes, such as OAuth, OpenID or similar, these captive portals only show a web form on the page itself asking for usernames and passwords to be entered directly.

Research framework 11

Figure 6. An example of a fake captive portal Alternatively, this technique can be used to gain access to local network credentials.

2.5.2.3.2 Modem and routers exploits Several incidents were reported when attackers benefited from vulnerabilities of the networking equipment, such as DSL modems or ISP routes. In one case [13], through known old exploits dating from 2015, a malicious agent was attempting to modify the DNS server settings in the routers redirecting all their DNS requests through a malicious DNS server. The malicious DNS server was modifying requests of domain names of a certain bank and redirecting to a fake, cloned website. The uniqueness of this approach is that the attack is performed without any interaction from the user and without affecting the operating system or the browsers: the targeted website can be accessed using a regular way (i.e. by typing the address, from history or existing bookmarks).

2.5.2.4 Phishing page – the final destination The ultimate goal of a phishing attack is to obtain sensitive information, such as user’s password, directly from users and the main instrument to get this information is to somehow convince to the user to enter it on a web page. This is done by creating a web page that the user can trust and enter his or her password. This information is afterwards sent to the attacker and completes a successful phishing attack. In order to minimize user’s suspicion, after the information is recorded, the user is usually forwarded to a legitimate login page. This phase of the attack will be described with more details further below.

2.5.3 Anatomy of a phishing page If the techniques used previous phases were enough to convince the victim to click on the link inside the phishing message, there is only the last portion left to make the attack successful: making the user enter the password on the phishing page. However, the way the URL of the phishing page looks like in the email itself

12 Context-Aware Multi-factor Authentication for the Augmented Human

is also important to provoke the user to really click on it. This is the first component of a successful phishing page.

2.5.3.1 The URL For several reasons, many attackers are using random URLs provided by free hosting providers or URLs of websites with vulnerabilities allowing to upload files. These URLs are easy to be identified as a phishing attempt, even for average IT- savvy users. There are some free hosting providers that allow registering quite long third level domains on top of short second level domains, this allows attackers to become more creative when it comes to selecting the subdomain for their future phishing page. As per RFC 7230 [14] , the maximum length of an URL is 2000 characters. A hyperlinked portion of text may or may not be the same as the URL itself, in case it is not, the target URL will be shown in the status bar of the application used to open the phishing email. Some browsers, for example, will only show a portion of such as long URL, therefore the URL may be crafted to appear as a legitimate one for the end users. Example of such an URL could be as follows. Let's say an organization is using a centralized SSO login web application with the URL below:

https://login.fictionalcompany.com/

A more successful phishing attack can benefit from a free hosting service, such as and host the phishing page under a URL as shown below:

http://login-fictionalcompany-com-443-h.freehost.tld/

Depending on the client software used and security awareness level, the potential victim may only see or attention to the first few characters of the URL in the status bar before clicking on it, and eventually, assume this URL as a legitimate one. After the user clicks on URL, the browsers’ address bar is only showing first N characters (depending on the screen size), which may lead to a look like shown in Figure 7, under different browsers.

Figure 7. Address bar of different browsers

Using this technique an attacker can produce a significantly long URL and if the screen resolution of a victim is not very high, the URL in the address bar will not Research framework 13

look suspicious at all. If this is combined with an exact replica of the company’s single sign-on login page [15], the potential victim is more likely to continue by entering his/her password. A visual comparison of a legitimate login page and a phishing page is shown in Figure 8. The phishing page is imitating user login page for Office 365 service [16].

Figure 8. Microsoft Office 365 Genuine and "Fake" login page comparison

2.5.3.2 Long subdomains technique One of the differences in the particular example shown in Figure 8 is dash characters instead of dots as opposed to the legitimate URL, which may look suspicious. This is a limitation of many free hosting services, but nothing prevents attackers to use several levels of the subdomain to make the phishing page URL look more similar to legitimate ones. According to RFC 1035 [17] and RFC 1123 [18], the theoretical limits for a DNS record is 63 bytes per label and 255 bytes for an FQDN, which fully covers the requirements for creating a URL which is long enough to be shown partially on any browser’s address bar even with the highest screen resolution. So, with creating a DNS record, the attackers can host the phishing page with the URL shown in Figure 9.

Figure 9. Very long FQDN

14 Context-Aware Multi-factor Authentication for the Augmented Human

2.5.3.3 Homograph attack Another, quite successful technique of FQDN for phishing pages is using characters visually similar to some of the letters in the domain name. “From a security perspective, Unicode domains can be problematic because many Unicode characters are difficult to distinguish from common ASCII characters,” Zheng writes [19]. “It is possible to register domains such as ‘xn--pple-43d.com’, which is equivalent to ‘аpple.com’. It may not be obvious at first glance, but ‘аpple.com’ uses the Cyrillic ‘а’ (U+0430) rather than the ASCII “a” (U+0041). This is known as a homograph attack.” Additionally, the attack can utilize characters like diacritics. Diacritics are not exactly visually similar to their Latin alternatives, there are little “dots” above or below the letters, but still are very close and hard to distinguish, especially if the style of displaying the hyperlinks is standard, which is underlined text.

Figure 10. IDN domain in an unpatched browser (first "a" is Cyrillic)

2.5.3.4 “Secure” phishing A phishing attack is less likely to be successful if the legitimate login page is using EV certificate and the users are trained to pay attention to company name appearing on the address bar and not just the “Secure” or lock icon (as with DV certificates). However, it is worth mentioning that EV certificates are also possible to be reproduced on a non-genuine domain. This is done by launching a company verification process with certificate authorities that are checking incorporation documentation in a rather relaxed way. At least two security researchers [20] [21] were able to obtain EV certificates, one with a name similar to an existing payment provider, and another one with EV certificate issued as “Identity verified” (this was the company name). Combined with the condition that the target victims are using Safari, the success rate of the attack would be very high because Safari does not show the actual URL if the web server is using an EV certificate. Together with a name like "Identity Verified" the page asking to enter the username and password looks legitimate and safe (Figure 11). Research framework 15

Figure 11. EV Certificate issued to "Identity Verified" company, as shown by Safari on iOS

Although phishing page with EV certificate is harder to implement, is more expensive and more complex to hide traces, using phishing pages with EV certificates would significantly improve the success rate of such attacks. Especially if this is used in combination with other techniques and the EV certificate is issued to visually similar domain names.

2.5.3.5 Tools for phishing attacks The phishing page imitating different services’ login page is relatively easy to replicate using tools like HTTrack [22] or even just saving the page locally using standard browser’s “Save as..” functionality. In addition, there are a few initiatives to make this process even easier, such as open source phishing templates and even phishing frameworks. Figure 12 shows a selection of templates that can be cloned to create a phishing login page from an open source project called Phishing Frenzy [23]. Currently, it has templates for Intel, LinkedIn, Office 365 and a couple of others. The project community is working to extend this list further.

16 Context-Aware Multi-factor Authentication for the Augmented Human

Figure 12. Phishing Frenzy Template gallery

Another example of such a tool, or to be entirely correct a full phishing toolkit, is called Gophish [24]. The project description states that the toolkit is designed for penetration testers and allows executing phishing engagements with a goal to raise security awareness. It is obvious that nobody can guarantee that these tools cannot be used (or are not used) for real-life phishing attacks.

Figure 13. Gophish - Open-Source Phishing Framework. Promo Page

Research framework 17

2.5.4 Summary The main goal of this chapter is to show that the phishing attacks are becoming increasingly sophisticated. There are, however, measures that any IT organization can take, which, of course, will not remove the risk of phishing attacks completely, but it can minimize or prevent the direct costs altogether. This chapter demonstrated that a sophisticated phishing attack has more chances to become successful even if user awareness is at a good level. Therefore, the best way to protect users from phishing attacks is to make a stolen password useless by implementing multi-factor authentication. This can significantly reduce the likelihood that a compromised credential will have access to an organization’s data, therefore making the phishing attacks against MFA-enabled accounts completely useless [25]. A study [26] dated 2006 is showing that around 90% of users were fooled to click on a phishing URL. The chapter reviewed technologies and methods used by attackers in order to raise the success rate of attacks, as well as a number of mitigation methods currently in use. It was stated, however, that enabling multifactor authentication is the most effective method: it will not prevent from attacks to be successful (i.e. stealing the user credentials) but will make the credentials impossible to use to gain access to further resources.

18 Context-Aware Multi-factor Authentication for the Augmented Human

Chapter 3. Review of existing MFA systems

3.1 TOTP algorithm and implementation overview The idea of using one-time passwords was formulated in November 1981 by Lamport [27]. In principle, OTP can be generated in different ways, but the majority of existing classic as well as modern MFA systems rely on modern RFC-based TOTP standard, in this section we will give a brief overview of the theoretical background of OTP generation methods this standard uses. Bellare, Canetti and Krawczyk presented a construction called HMAC (for Hash- based Message Authentication Code) [28], which keyed message authentication codes from public unkeyed cryptographic hash functions, by simulating the keying of the hash function’s initialization vector. HMAC function is defined as shown in Equation 1, where ⊕ denotes the bitwise exclusive-or operation, k denotes the concatenation operation, and opad and ipad are constants for outer padding and inner padding respectively.

Equation 1. HMAC function 퐻푀퐴퐶(퐾, 푚) = 퐻((퐾 ⊕ 표푝푎푑)푘퐻((퐾 ⊕ 푖푝푎푑)푘푚))

The Time-based One Time Password Algorithm (TOTP) was proposed by M’Raihi et. al. in [29], and presents a type of key-derivation function that takes a single secret (such as a password or passphrase) as an input and produces a single key as an output. TOTP is a variation of HOTP algorithm, however, with TOTP, the key is dependent on the secret as well as on the current time, instead of arbitrary counter value defined in HOTP; so current epoch time is considered a counter instead and is calculated as shown in Equation 2, where T0 is a predetermined epoch relative to which all times are counted and Ts is a time step. Time steps used in the majority of TOTP implementations are 30 or 60 seconds.

Equation 2. Time counter value Current Time − T0 푇푐 = Ts

Once the value of the time counter is calculated, the TOTP output can be calculated by signing the master secret (K) and the time counter (Tc) using HMAC function as shown in Equation 3. Equation 3. TOTP function 푇푂푇푃(퐾) = 퐻푀퐴퐶(퐾, 푇퐶 )

Review of existing MFA systems 19

The master secret (K) used to calculate the HMAC hash is also called a shared secret. The reason for that is because this key is shared between the authentication server and the client generating OTP codes. The secret is shared during the registration. So, the values used to generate TOTP are exactly the same at both parties (client and the server): the secret is the same and the time counter used is based on system clocks, ideally the same or within the 30/60 seconds offset 1 . So, as shown in Figure 14, the validation process of user- submitted OTP codes is as simple as comparing with server generated OTP codes.

Figure 14. TOTP validation flowchart

1 A number of server implementations designed to be used with hardware tokens as TOTP generators also allow time drift adjustment to overcome the time synchronization issues

20 Context-Aware Multi-factor Authentication for the Augmented Human

3.2 Classic multi-factor authentication systems and solutions Multi-factor authentication using carried devices (a hardware token or an application on a mobile device) as a context was among the first implementations of strong security. We consider this context as classic and review some of the most commonly used variations of such systems in this section.

3.2.1 Hardware tokens One-time passwords (OTP) generated by a standalone hardware token can be considered a classic method of multi-factor authentication. In this example, this hardware device is serving as a proximity context proving the user has access to a physical device. For our survey, the type of the algorithms used to generate a one-time password is not critical, however, we can review a number of modern hardware types to compare with each other. Majority of the token producers are now moving or have already moved to HMAC-based (HOTP) standard and in most of the cases its time-based variant – Time OTP (TOTP) [30] and the principle of TOTP hardware or software tokens is exactly the same, therefore we review some of the tokens that are not using TOTP as their algorithm. Hardware tokens can be of two types: a) disconnected tokens, separate devices that have no direct connection to client system (users have to manually type the OTPs using keyboards); b) connected tokens, that transmit the generated OTPs to the client via a physical connection, usually via USB by emulating keystroke signals.

Figure 15. A hardware token for two-factor authentication

RSA SecurID is one of the oldest hardware tokens on the market and used to be a de-facto standard for two-factor authentication. It is using RSA proprietary algorithms for generating a one-time password. The RSA SecurID authentication mechanism consists of a so-called token — either hardware or software (also called soft token) — which is assigned to an end user and generating an authentication code at fixed intervals (usually 60 seconds) based on current time (there is a built-in clock) and a factory-encoded random key (known as the "seed") assigned to each token. The seed is different for each token and is loaded into Review of existing MFA systems 21

the corresponding RSA SecurID server (RSA Authentication Manager) as the tokens are purchased. RSA SecurID is still quite popular, but after a security breach in 2011 [31], not considered as secure by end-users anymore. Yubico offers a number of products appearing to be the achieving the real minimum of user’s interaction required to submit second factor [32], and can be shown as examples of connected tokens. Yubico’s Nano and Neo hardware tokens are designed to send generated OTPs via NFC or USB (emulating keyboard input). These devices are indeed making two-factor authentication much easier for end users, however, there are still some disadvantages. The USB based token is impossible to use on the majority of mobile devices without additional equipment, and the activity range of NFC tokens is limited to a few centimetres [33] .

Figure 16. Yubico connected tokens

In addition to regular OTP algorithms, Yubico keys are also supporting core challenge-response features, where the OTP generation is based on a challenge sent by the target application (i.e. a web browser) and the response is generated by signing the challenge using a key stored on the device.

3.2.2 Software tokens Software tokens are applications running on a computer device, usually mobile devices. Modern mobile operating systems allow creating very complex and powerful mobile applications, so software tokens nowadays provide additional features, such as multiple profiles, QR code based enrolments and cloud backup. However, for the main functionality of software tokens (i.e. generation of OTPs) is supported even on models that are not defined as “smartphones”. This section reviews a variety of such applications under different platforms. MobileOTP (MOTP) is one of the first software tokens designed for two-factor authentication. The first version of MOTP was published in 2003 and was intended to be run primarily on regular phones with Java support (not smartphones) [34].

22 Context-Aware Multi-factor Authentication for the Augmented Human

OTP codes generated by MOTP are not HMAC based, but the concept is very similar to the TOTP algorithm described above. The OTP codes with MOTP are alphanumeric codes generated based on an MD5 hash of a secret seed, current timestamp and a PIN code entered by end user each time OTP needs to be generated. MOTP has the same level of security [35], however it was originally designed to work on ordinary cell phones (now called "conventional") , therefore it lacks some features, and especially the enrolment process designed to be done in "client-to-server" direction; this means that the unique key (secret) needs to be generated on the device and then entered to the user's profile on the authentication server (Radius, Database or plain text configuration files- there are hundreds server side realizations done for MOTP). Figure 17 shows photos of MobileOTP Java application (MIDLet) running on Nokia 3510 phone.

Figure 17. MobileOTPv 1.07 running on a Nokia 3510

Google Authenticator is a mobile application that utilizes TOTP or HOTP algorithms as described by RFC 6238 [29]. The algorithm of OTP generation is based HMAC-SHA1 hash of a secret key and a counter value (timestamp in case of TOTP). The enrolment process, different from MOTP, is a server to the client, and in most cases, it is based on a QR code with a manual entry in case the device does not have a camera. Review of existing MFA systems 23

Figure 18. Google Authenticator mobile application for Android

Google Authenticator is available on multiple platforms, such as Android, Blackberry and Apple iOS, a number of applications with similar functionalities exist on alternative platforms [36].

With TOTP based systems, the secret key is generated on the server and then shown to the client during the enrolment process, in particular with Google Authenticator the key is shown as a QR code to be scanned by the app, which makes the enrolment process extremely easy. This, in our opinion, is the main advantage of Google Authenticator, and this is the reason for such systems to be becoming more popular. However, there are some more key factors that are different, as shown in the table below.

Table 1. Google Authenticator compared to MobileOTP

MobileOTP Google Authenticator

OTP Generation algorithm MD5 based TOTP/HMAC-SHA-1 based OTP validity time 2 10 seconds 30/60 seconds

2 OTP regeneration interval on the client, the server-side algorithm can be set to accept previous OTPs by adjusting the timestamp used: e.g. a loop from [time ()-300] to [time ()] will accept OTPs generated during an interval of 300 seconds. For example, Google seems to be accepting the current and one previous OTP

24 Context-Aware Multi-factor Authentication for the Augmented Human

Additional PIN protection 3 Yes No Key generation Client side Server side Easy enrolment (with QR) No Yes RFC based No Yes

Majority of other software tokens are using push-notifications to deliver OTP to the user’s mobile device. In this case, the OTP is generated on a central server, which then sends this information over the cellular or Wi-Fi network to end users. Most of such apps are using HOTP/TOTP as a fallback method in case the device is not online. There are also alternative apps that offer additional PIN code protection to standard HOTP/TOTP profiles.

3.2.3 Alternative types of strong authentication While HOTP/TOTP is the standard algorithm described by IEFT for implementing two-factor authentication, there are other technologies that provide the same or almost the same level of security by using different approaches and algorithms. We will not review the proprietary systems providing such strong authentication but will cover open-source strong authentication tokens.

3.2.3.1 SMS based strong authentication A common technique used for the delivery of OTPs is text messaging. Because text messaging is a ubiquitous communication channel, being directly available in nearly all mobile handsets and, through text-to-speech conversion, to any mobile or landline telephone, text messaging has a great potential to reach all consumers with a low total cost to implement. The implementation is rather simple: the authentication service creates a random value (usually digits only PIN) and transmits it to user’s mobile phone (in some implementations this can be done via landline numbers). Then, the user enters the code received which serves as the second factor for the authentication. In general, using SMS (as well as automated phone calls) to receive a one-time token is much more user-friendly than relying on a software or hardware token . However, being easier these methods are also less secure. That’s because thieves can intercept that one-time code by tricking the mobile provider into either swapping mobile device’s SIM card or “porting” the mobile number to a different device. However, if the only MFA options offered by a site you frequent are SMS and/or phone calls, it is still better than simply relying on a password.

3 With MobileOTP PIN is basically a portion of the key and is stored only on the server. Users only have to remember it and type in the client app whenever an OTP is needed. With Google Authenticator TOTP algorithm keys stored both on client and server sides need to be equal. As per comparison table, the advantage of MobileOTP based systems would be an additional layer of protection (PIN), although some may regard this as an inconvenience. In the same time, lack of pin code protection (or at least a possibility of having one) is the main shortcoming of Google Authenticator. Review of existing MFA systems 25

3.2.3.2 Paper based MFA systems

There are a number of implementations of strong authentication that use a list of one-time passwords printed on a piece of paper. The logic behind is also simple, both server and client have a list of numbered passwords, and when logging in, the server chooses a password and prompts the user to enter it [37]. Figure 19 illustrates an example of a real-life paper token based production system [38]. The login page shown randomly selects a password to be entered. The user has a laminated piece of paper with these passwords which is used to find the requested password.

Figure 19. An example of a paper token based system

A similar approach is used in the e-banking system of AzeriCard. In its implementation, the lists of passwords are being printed out from participant banks ATM machines. As per user instructions published on the website [39], “To connect to the "Internet Banking" system it is necessary to obtain a list of one-time passwords in any of the information kiosks or ATMs of the Bank. To do this, in the ATM menu, select "Payment", then "Services", then "A list of IB passwords”, and the machine will print out a list similar to the one shown on Figure 20. Although the access to this list is secured with an additional factor of the banking card and its pin code, this can be regarded as another example of paper-based strong authentication.

26 Context-Aware Multi-factor Authentication for the Augmented Human

Figure 20. One-time passwords list printed by an ATM

3.2.3.2.1 PMFA Concept High-security multifactor authentication does not need to be expensive. In fact, it can be free as the examples above demonstrate. As a part of this PhD research, we decided to create the simplest and the cheapest authentication system with Multifactor authentication – Paper Multifactor Authentication (PMFA) based on the existing technologies reviewed in 3.2.3.2 . Data storage and format For simplicity, the user credentials, as well as the second factor data for this test implementation, will be stored in text files – we will assume these file will be stored in a secure location – in the username.password. The data will be stored in PHP’s native serialized [40] format generated from the following 2 arrays: - $user[‘password’] – a string variable, an SHA-256 salt of user password - $user[‘otpmatrix’] – a two-dimensional array containing a matrix of pseudo-one-time passwords for this user as described below Review of existing MFA systems 27

Pseudo-one-time passwords array This array is generated and stored for every user. The generation can be done using php’s uniqid [41] function as a part of the user provisioning. A sample function generating this array is shown in Figure 21.

Figure 21. PMFA OTP Matrix generation function

The same data will be printed out on a laminated small format paper card (i.e. credit card size if double-sided) and will be used by the user as the “paper MFA token” to log in as shown in Figure 22.

Figure 22. Paper MFA token

Login process A standard, classic, login process flowchart implemented with PHP and based on sessions is shown in Figure 23. Sessions in PHP (as well as other server scripting languages) is a way to store information (in variables) to be used across multiple pages. Different from cookies, the data is not stored on the user’s browser, which is an even more critical aspect when it comes to authentication. For our project, we will add an additional step and a session variable in order to implement the second-factor verification.

28 Context-Aware Multi-factor Authentication for the Augmented Human

Figure 23. Classic (single-factor) authentication flowchart

In the login procedure with the second-factor authentication involved, the flow is modified to include the following steps: 1. After the username and password is generated, the user is redirected to the second login page 2. An additional session variable for MFA is generated. The variable consists of 2 random digits, first (row – X ) in the range between 0 and 9 and the second (column - Y) in the range between 0 and 19 3. The user is asked to look for the OTP value in row X and column Y in the paper token and submit on the MFA login form 4. The OTP value submitted by the user is matched against $otp[X,Y] stored for the current username 5. If the OTP value matches, login is successful 6. If OTP value is not matching, the access is denied, sessions are cleared and the process is terminated A simplified version of this flow is shown in Figure 24. If for any reason, this concept is to be used beyond proof-of-concept, a number of enhancements are strongly advised: A) A temporary “black-list” of recently used OTP codes is to be maintained to eliminate the possibility of replay attacks B) CAPTCHA interface to be implemented prior to MFA verification to eliminate brute-force attack C) Limit the number of MFA attempts by implementing account lockout procedures (i.e. if the password was correct but OTP was wrong more than 3 times in a row). The measures above are important due to the fact that there are only 200 OTP values in the matrix and without such protection, it is theoretically possible to compromise the account knowing the username, password and one of the Review of existing MFA systems 29

previously used OTP values (i.e. refreshing the MFA page until the known OTP value is requested)

Figure 24. Authentication flowchart with MFA paper token

3.3 Modern multi-factor authentication systems and solutions Multi-factor authentication is the area where new inventions appear quite frequently. In this section, we will review methods, techniques and products that were designed to replace, complement, simplify or strengthen classic methods.

3.3.1 Programmable tokens: a compromise between software and hardware tokens As explained previously, hardware tokens provide way better security and user experience if we are comparing with standard TOTP software tokens (mobile

30 Context-Aware Multi-factor Authentication for the Augmented Human

applications). The way classic hardware tokens are being registered is that the secret key of the token is entered to the authentication server database and is associated with the relevant user account. However, not many services are allowing users to input the values of the shared secret keys, in most of the cases the shared secrets are generated on the server during the enrolment process. A simplified flowchart of the enrollment process is shown in Figure 25.

Figure 25. TOTP Enrollment procedure

Several vendors [42] [43] are offering a solution that allows implementing hardware tokens for systems without native support. This is done by programming the tokens, namely, applying the secret keys by a special app running on Android and using the NFC chip. This allows using hardware tokens for systems where the shared keys are generated on the server side. Technically, the hardware tokens become “clones” of mobile tokens and the procedure is similar to regular enrollment with one additional step of “burning” the shared key via NFC using the burner application as shown in Figure 26.

Review of existing MFA systems 31

Figure 26. TOTP Enrollment with programmable tokens

The configuration of the programmable token requires an Android smartphone with NFC support and the burner application. A burner application from one of the vendors is shown in Figure 27. We have been commercializing the concept of programmable hardware tokens under TOKEN2 project, therefore the app as well as the provisioning guides are branded under its name.

32 Context-Aware Multi-factor Authentication for the Augmented Human

Figure 27. Token2 Token Burner application

One of the advantages of this method is that the end user can benefit from both hardware and software tokens, adding more redundancy as well as convenience for the login process (i.e. if one of the tokens is currently not available, its alternative can be used to log in).

3.3.1.1 Programmable tokens provisioning guide sample To better illustrate the provisioning of programmable tokens, we will use the Facebook account as an example. Facebook does not natively support hardware Review of existing MFA systems 33

tokens, but it supports mobile authenticator apps such as Google Authenticator to serve as a second factor to secure account login. The guide will use the Token2 miniOTP-1 card as an example of a programmable hardware token. The Token2 miniOTP-1 card is a "drop-in" replacement of mobile applications such as Google Authenticator or Token2 Mobile OTP. The only prerequisite is an NFC-enabled portable device running Android (v3.x and higher) and only during the enrolment phase. Subsequent logins will not require any other device, only the token itself will be needed.

Step1. Log in to your Facebook account, and from the user menu on the right, select 'Settings'

Figure 28. Hardware tokens for Facebook, Step 1

Step2. Navigate to the "Security and login" page and click on "Edit" button next to 'Use two-factor authentication' option. On the following page, click on "Get started" to start the enrollment process.

34 Context-Aware Multi-factor Authentication for the Augmented Human

Figure 29. Hardware tokens for Facebook, Step 2

Step3. Select "Authenticator App" in the Two-Factor Authentication dialogue window and click Next.

Figure 30. Hardware tokens for Facebook, Step 3 Review of existing MFA systems 35

Step 4. During this step, you will need to have your miniOTP-1 token and Token2 Burner App ready. Install Token2 Burner App and make sure your token is accessible via NFC. You can test NFC access by "get OTP" button of the app: push the button on the miniOTP-1 device and hold it close to the NFC antenna of your Android device (usually below the camera on the back). Then on the Burner App, touch "get OTP" button. The OTP shown on the app should match the one displayed on the token.

Figure 31. Hardware tokens for Facebook, Step 4

Step 5. Click Next and enter the OTP code generated by your token when requested by the wizard. Once the correct OTP is entered, the enrollment process is complete.

Figure 32. Hardware tokens for Facebook, Step 5

36 Context-Aware Multi-factor Authentication for the Augmented Human

3.3.1.2 Programmable tokens vs classic tokens – user self-service aspect The use case of programmable tokens is clearly explained earlier in this section: they can be a workaround for cases where classic token secret key hashes import is not supported by the authentication service or server and is always generated by the server. Up until October 2018, Microsoft Azure MFA server in the cloud (MFA system used for popular Office 365 service) did not support importing secret keys, so programmable hardware tokens were the only solution for users not possessing or not willing to use their mobile phones. In October 2018, Microsoft has introduced classic OATH tokens support with Azure Cloud MFA [44], which gives us an opportunity to compare both token types in the same environment. As per Microsoft "Azure AD supports the use of OATH-TOTP SHA-1 tokens of the 30-second or 60-second variety. Customers can procure these tokens from the vendor of their choice. Note that secret keys are limited to 128 characters, which may not be compatible with all tokens" Token2 classic tokens are 30-seconds and the keys are 64 characters, so we are fine here. Next, "[..] once tokens are acquired they must be uploaded in a comma-separated values (CSV) file format including the UPN, serial number, secret key, time interval, manufacturer, and model[..]". No problem here as well, token vendors will send the CSV file for the tokens acquired upon request. Furthermore, to complete the process "the administrator then can activate each key by clicking Activate for the token to be activated and entering the OTP displayed on the token". This one is something not very convenient and here is why: a) When they say, "the administrator", they really mean it. In order to activate a hardware token for a user, Global tenant admin rights are required. As per our knowledge MFA permission delegation has yet to be implemented b) The administrator will need to have access to the token itself in order to activate it. This makes the provisioning process kind of cumbersome as tokens cannot be bulk provisioned or pre-provisioned. This needs to be done one by one, with the physical presence of the user (or the token). If the token is provisioned (activated) in advance and then sent to the end user, he or she will not be able to log in until the token reaches the user. Review of existing MFA systems 37

Figure 33. Activating OATH hardware tokens with Azure MFA (Global Admin interface)

Summarizing this comparison, we can state that while using classic TOTP tokens can significantly decrease the budget needed to enable hardware token based MFA, this adds more work for tenant administrators. Therefore, only smaller organizations where global administrators take care of user provisioning and operating in one physical location can fully benefit from this new feature. Bigger organizations should still rely on programmable hardware tokens, where provisioning is done by users themselves, at least as far as this example (Microsoft Office 365 MFA) is concerned. We believe the situation would be similar with other systems as well. TOTP Tokens with USB HID interface Another aspect affecting user experience when using classic TOTP tokens is the necessity to manually type in the OTP digits. Two solutions reviewed below are supposedly bringing us a step closer to the ideal minimal user interaction MFA concept while keeping the hardware cost at the acceptable level. The idea behind these solutions are quite simple: the devices are utilizing the USB interface and emulating Human Interface Devices (HID), namely USB keyboard and the OTP generated can be sent as keystrokes via HID interface emulating pressing the digit keys. This concept is described and implemented as a DIY project named leostick_otp [45].

38 Context-Aware Multi-factor Authentication for the Augmented Human

Figure 34. leostick_otp hardware components

For one particular use case the solution works fine and as expected: assuming the token is permanently plugged into the USB port of the workstation, during the authentication process, user’s actions are minimized to the following steps: 1. The user sets the focus on the text field in the form asking to enter the OTP 2. User press the button on the device and the OTP digits are sent to the USB HID channel 3. User submits the form by clicking on Submit In most of the systems, the focus is already set automatically, so this eliminates the step #1. Additionally, most of the authentication forms get submitted when the Enter key is hit on the keyboard; this means that if the OTP generated by the token device is followed by a keystroke emulating the Enter button (keycode 13), the step 3 can also be removed from the actions list. So, taking into account the assumptions above, we can summarize that the only action required by users is to press the button on the token device. There is, however, one major disadvantage in this particular implementation, as many of the users are using different devices to log in, there are chances that in a particular situation the USB ports will not be available. This could be due to the device limitations (i.e. Apple iPhone does not have USB interface at all) or administrative restrictions (some organizations deny using USB ports for device security purposes). This disadvantage can be potentially addressed by adding an LCD screen to display the OTP; which will make the device a hybrid one, so in case USB method is not available, users can always type the OTP in manually.

Review of existing MFA systems 39

3.3.2 Solutions based on static or pseudo-dynamic context The context factors reviewed below are not changing frequently enough to qualify as strong security factors. We are reviewing them to illustrate and compare with other, more secure, context factors. It may sound controversial, but any type of authentication over a TCP/IP network already has a possibility of the context-aware authentication: the IP address of the client device. So, restricting access to an IP address or a range of IP addresses can be theoretically regarded as a context factor. Furthermore, because all IP address databases also have associations with countries, cities and in some cases particular buildings, they can also be considered as proximity context factors. However, it is relatively easy to forge/spoof IP addresses, so using IP address restriction itself cannot provide a satisfactory level of security. In some cases, this method can complement other methods to provide an acceptable security level- in the example below, it is used in conjunction with OTP to secure plain FTP connections. FTP as a protocol is known to be insecure by design and is not recommended to be used. It should be replaced by SFTP or SSLFTP, however, in some situations, users prefer to keep using the standard plaintext FTP. OTP- FTP is an attempt to make the plain-text FTP protocol as secure as possible by introducing a web panel, protected with two-factor authentication, that generates a temporary session password for an FTP user and also restricts access to a specific IP address. In this example, IP address is a context factor used as an additional protection mechanism. In some cases, access to a certain resource is restricted to a geographic location. This idea is presented in the “Secure Spatial Authentication using Cell Phones” paper [46]. The main principle is that the cell phones send the GPS coordinates both to the authentication server and the cellular network, which is then compared and validated if these coordinates match. The paper states that the main requirement for this concept to be secure, is to use a “using a tamper-proof GPS module”, which would be rather hard to ensure, and GPS coordinates would be easy to forge with special devices. Many BLE devices are equipped with temperature sensors, so it is technically possible to verify the ambient temperature when authorizing a user. Estimote devices can be used as an example of such devices [47]. The logic behind it is simple, as illustrated in Figure 35, the device equipped with a temperature sensor sends the current temperature both to the client via BLE and to the authentication server via IP/Internet connection. Given that the sensor has high accuracy level and current temperature may keep changing, the ambient temperature may be constantly changing factor and can serve as a dynamic second factor.

40 Context-Aware Multi-factor Authentication for the Augmented Human

Figure 35. Temperature-based Context-Aware Authentication with BLE Beacon The disadvantages of this method are obvious: in addition to the hardware requirements and the accuracy level of the sensor, there is a very narrow attack window to the nature of the factor itself (in most areas ambient temperature stays constant and does not change significantly). However, in some cases, this may be a very convenient method (e.g. for outdoor areas with frequently changing temperature). Several services provide API to integrate users’ face and/or voice recognition as a second authentication factor. KeyLemon [48] provides API as well as additional integration components (such as WordPress plugins) to enable this. Biometrics is also relied upon in more critical areas such as online banking. Recently, Wells Fargo [49] has implemented biometric logins to their online banking system using a mobile application. The application, shown in Figure 36 uses both voice and face recognition to identify users.

Review of existing MFA systems 41

Figure 36. Biometric verification in Wells Fargo mobile application

3.3.3 Dynamic Context The context factors reviewed in this section are dynamic and provide higher security as the attack vector is minimal, especially compared with static factors. A hardware token based on TOTP algorithm is the ideal example of such dynamic context as the factor it generates changes every 30/60 seconds. This section will review modern systems utilizing dynamic context as authentication factors.

3.3.4 Bluetooth Low Energy based solutions User’s physical location is one of the examples of a context. Being close to a device can verify the location as well. There are a number of techniques that use BLE (Bluetooth Low Energy, Bluetooth 4.0) [50] to determine proximity to a device. BLE beacons periodically broadcast sets of data that includes the unique ID of a device as well as additional parameters (major ID, minor ID and others) that can be used to deliver OTP data to the end users’ devices. Authy Bluetooth is a TOTP based implementation of two-factor authentication. As it is based on BLE protocol, the use of Authy Bluetooth [51] is limited to situations where both a client access system (e.g. a laptop) and the system running the token (e.g. a mobile phone with the Authy app) support the BLE protocol. For this reason, Authy Bluetooth is only supported on recent Mac devices as clients, iPhone 4s and above, plus Android devices running version 4.4.4 and above with BLE support as a mobile device. In addition, the current implementation can hardly be considered as a system with “minimal user interaction” as users need to: launch the Authy application, select an account and after the current OTP is copied to the clipboard, users are advised to paste it to the form requiring the OTP. Another system with a similar implementation is proposed by Rijswijk-Deij [52], where TOTP broadcasts are emitted by a BLE based token beacon device. This concept may be further developed using Eddystone, an open beacon format announced by Google [53]. Authentication using a virtual iBeacon as a second factor has been used in the product offered by SAASPASS [54]. The application installed on a user’s smartphone automatically transmits the generated one-time password to a special

42 Context-Aware Multi-factor Authentication for the Augmented Human

connector (currently, only available for Macs). This connector searches for BLE packets transmitted in the near or immediate range and if the packet parameters match, passes the values gathered to the application (e.g. a browser) emulating keyboard keys. Beacon Authpath [55], a system proposed as a part of this research is also relying on BLE for transmitting the authentication data to validation/authentication server. It is combining the physical location of users with their physical location history to form a complex dynamic context which is used as an additional authentication factor. The drawbacks of Bluetooth based systems are: BLE is only supported on limited types of devices and Bluetooth is usually not activated on devices, as users often perceive it as a battery hog.

3.3.5 Wi-Fi based solutions Several concepts use Wi-Fi as a proximity context. Wi-Fi can indeed be a good (or in some cases better) alternative to BLE given the range and wider spread, especially as far as hardware is concerned. Trust in Wi-Fi [56] is constantly evolving but it is becoming a mature technology from the point of view of security. A system based on Wi-Fi SSID is proposed by Namiot [57] , where SSID is used as a context-aware application concept. This paper describes using the information exchanged between access points and client devices to determine proximity data and using this proximity data to send promotional information, similar to Apple’s iBeacon technology but based on Wi-Fi rather than BLE (Bluetooth Low Energy). This paper uses similar concept of utilizing Wi-Fi SSID to relay information but does not provide any security analysis as the system is not intended to be used as a security mechanism. Another similar solution, called WifiOTP, implements two-factor authentication without affecting user experience by introducing minimum user interaction based on standard Wi-Fi [58]. The main idea is to create a dynamically changing SSID that has OTP encrypted in it. Client devices only need to “see” the name of the network without connecting to it and use a special shared encryption key to decrypt the OTP broadcasted via SSID. This concept is described further in Chapter 5.

3.3.6 Sound as a context There are a few projects that utilize sound as the context. A common pre-requisite for utilizing these projects is having a device equipped with a microphone and a speaker. In Sound-Proof [59] the second authentication factor is based on verification of user’s phones presence near the main device. The system compares the ambient noise recorded by the main system (e.g. a laptop) with the sound recorded by the mobile phone. This comparison is triggered by a push notification, i.e. the ambient sound does not need to be recorded all the time - it is done only for a short time when the second factor is requested by the system. In case there is no ambient Review of existing MFA systems 43

sound at all (which is presented as a very rare case), system suggests the user to “clear the throat” to generate some sound.

Figure 37. Sound-based Authentication Example

Another concept similar to Sound-Proof is called SlickLogin. Instead of relying on the ambient sound, the mobile application generates inaudible sounds (ultrasound) which is captured by the main system’s microphone and sent to the server for comparison [60]. Authors also propose a similar concept called Watermelon 2FA [61] presented as zero-effort two-factor authentication scheme called that uses audio signals without user interaction. In the proposed concept, when users log into an account, the phone automatically plays an audio signal that encodes into a code that the browser listens for. The audio is then decoded for the code and used in authentication on the remote server. The principle is shown on Figure 38.

44 Context-Aware Multi-factor Authentication for the Augmented Human

Figure 38. Watermelon 2FA System Design

3.4 Review of existing solutions and gap analysis Many solutions reviewed in this chapter are having their own relevant shortcomings when it comes to user convenience, therefore they may lead to negative user experience and even present a risk of users choosing not to enable multi-factor authentication if they have choice to do so. In this sub-section we will review the main existing MFA systems and critically evaluate the existing gaps. Propositions on closing the gaps for a few of the reviewed systems will be given in the next chapter. In the Table 2 we compare existing solutions providing the highest level of security (solutions with static or pseudo-dynamic context used as the second factor are omitted as obviously insecure)

Table 2. MFA Systems analysis MFA System Description Gaps

Classic Classic isolated - Manual OTP entry may lead to negative hardware tokens hardware tokens user experience based on HOTP or - Limited usage area: can only be used TOTP algorithm with systems allowing importing the seeds. Review of existing MFA systems 45

- Time drift: may become unusable if system clock is significantly out of sync and the authentication system does not support automatic or manual time drift adjustments Software tokens Mobile - Manual OTP entry may lead to negative without push applications based user experience notifications on HOTP or TOTP - Risk of OTP or seed leak if the app runs algorithm on a compromised mobile device Software tokens Server generated - Risk of unconscious login approval due with push challenge to low user awareness level notifications transferred to - Risk of auto-approve implementation if mobile application the app runs on a compromised mobile via push device notifications – user action (“Allow”) needed to approve logins Programmable Isolated hardware - Manual OTP entry may lead to negative hardware tokens tokens based on user experience HOTP or TOTP - Time drift: may become unusable if algorithm, seeds system clock is significantly out of sync can be transferred and the authentication system does not via NFC support automatic or manual time drift adjustments BLE based OTP Isolated hardware - Limited usage area: can only be used hardware tokens tokens based on with systems allowing importing the HOTP or TOTP seeds. algorithm. OTP - Time drift: may become unusable if gets transferred system clock is significantly out of sync via BLE protocol and the authentication system does not support automatic or manual time drift adjustments.

The analysis shows the requirements of proposing new solutions as an attempt to address the gaps described in this summary.

Chapter 4. Our New MFA Solutions

In this chapter we will present new solutions that are meant to improve the user experience with MFA as well as introduce additional context factors. The new context factors illustrated on the Figure 39 are: 1) WifiOTP , 2) AuthPath Beacons and TOTP-QR solution, and 3) Programmable tokens with time sync. In addition to proposing the new contexts, we will also review and propose improvements in the provisioning (such as self-service enrollment), time adjustment and enrollment procedures that we believe will lead to more positive and consistent user experience in multi-factor authentication systems.

Figure 39. Diagram of context types as factors for multi-factor authentication with new solutions proposed

4.1 Review of the improvement areas As the gap analysis shown in Table 2 there are three basic areas than need improvements: - Introducing additional context factors that could potentially lead to presenting the additional authentication factors automatically with no or 47

minimum user interaction (such as path transferred via BLE described in 4.2 and using Wifi SSID to transfer the OTP shown in 4.4) - Solving the issue of the time sync with isolated devices where TOTP is used as the main or fallback algorithm (shown in 4.6) - Minimizing user actions needed during transferring the OTP generated by the context-based device to main authentication system as well as during enrolling the second factor with the authentication system (as proposed in 4.7) In order to measure the user acceptance of the proposed ideas and to compare them with existing solutions, some of the solutions will have produced a physical proof of concept device. This will allow to run evaluations done by user surveys at least for some of them. Having proof of concept devices ready to be used and tested will also simplify passing the ideas to production phase as well as commercializing them for real-life use.

4.2 Beacon AuthPath - Augmented Human Path Authentication

4.2.1 Introduction As per Stajano [62], ubiquitous computing with all its sensors embedded in the environment and carried out by humans has open the door for novel context- aware authentication schemes. Determining exact geographic location of a person has always been a way of proving identity. While there are obvious ways of implementing this, such as determining GPS coordinates or getting location information based on Internet connection used, they are not accurate and trustworthy: IP address-based information’s accuracy is generally limited to determining a city/village/neighborhood, GPS’s can mainly only be used outdoors and in areas with direct satellite coverage. Furthermore, both methods are easy to forge, jam and spoof. In this section, we present how those augmented paths can authenticate a user in a secure way whereby the users can prove they have passed by a path, even with current unsecure beacons. After surveying related work, details of our new scheme will be provided, such as its model, use-cases and alternative implementations. Later, we present how we have validated this new authentication scheme with unsecure Estimote beacons. Estimote has recently released a new firmware version, where a security mechanism has been implemented [63]; with the new version, Unique ID of an Estimote will periodically change based on a secret key (similar to hash key of TOTP algorithm [29] ) and therefore and device can be easily checked for authenticity by querying Estimote cloud API.

4.2.2 Related Work Electronic geo-fencing [64] is a technique that has been proposed to ensure that people, devices and machinery are accessed in or from authorized physical locations only. In contrast, our scheme focuses on secure paths with currently

48 Context-Aware Multi-factor Authentication for the Augmented Human

deployed BLE technology. IT security is not the only area where BLE beacon technology may appear. Bluesmart [65] , marketed as a “smart suitcase” relies on BLE beacon technology for physical security: the owner can open the suitcase by just approaching or tapping on an app installed.

4.2.3 Beacon Authpath Model In this section, we describe our new Beacon AuthPath model including several use-cases. We first start by use-cases with standard beacons, then with smart beacons and finally, without a smartphone.

4.2.3.1 “Beacon AuthPath” with standard beacons One of the possible use-cases can be a system for verifying a path passed by a person within a wider geographical area, such as a smart city.

Figure 40. AuthPath sequence diagram

BLE beacons transmit radio packets consisting of 4 main pieces of information: “UUID” – a 16-byte unique identifier of the device, “Major” and “Minor” - 2-byte string and “Tx Power” – value used to determine the distance between devices [66]. The mobile application used in this use case will detect this information, save locally together with current timestamp, and transfer the harvested data to the 49

server at the final checkpoint. To protect from the replay attack (e.g. generating a virtual beacon with the same parameters) the mobile device then initiates changing the value of “Major” variable of the BLE device to a random value using a special SDK built in the application. The app sends the new value to the server after assigning it to the beacon device.

Figure 41. Beacon AuthPath data flow (online)

This use case makes use of standalone BLE beacons that can be managed via Bluetooth using an SDK call, and with no security mechanisms in place. Estimote beacon [4] is an example of such devices and is planned to be used in the proof- of-concept implementation. The model with standard beacons provides limited security, as the beacon broadcasts are publicly visible. With the scenario where the app uses SDK calls to modify beacon’s parameters, the risks of “replay” attacks are minimal (as the server generates and sends new values only to the last user passing the checkpoint). However, as the Estimote SDK provides no protection, the authentication sequence is insecure. This is a major obstacle to using the given scenario in systems requiring higher level of security.

4.2.3.2 “Beacon AuthPath” with “smart” beacons This is a slight modification of the previous use case where standard beacon devices are replaced with compact devices (“smart” beacons) running an operating system capable to periodically run simple scripts. This will allow avoiding modifying beacon values when passing the checkpoints; instead, the major value will be regenerated automatically every N seconds. This also removes the requirement of the mobile device to be online, the collected beacon information can be stored locally and uploaded to the server in bulk at any convenient time or place, e.g. when reaching the final destination point. Each “smart” beacon will have a secret hash key (not visible, stored in device’s internal memory). The Major value broadcasted by smart beacon device is generated

50 Context-Aware Multi-factor Authentication for the Augmented Human

using TOTP [30] algorithm based on current time and the secret hash key. When user approaches the beacon, the broadcasted packet information (UUID and Major) is saved to mobile devices’ memory together with current timestamp. After the path is completed, the array of information gathered at all checkpoints and afterwards uploaded to the server. The server will have a copy of hash keys of all smart beacons and is able to analyze the submitted matrix and verify whether it contains valid “Major” values, by rerunning TOTP algorithms with the submitted timestamps and stored hash keys and comparing with the submitted “Major” values.

Figure 42. Beacon AuthPath with smart beacons data flow (online and offline)

The model with “smart” beacons provides higher security in comparison with previous model. Although, the smart beacons are relying on the same BLE technology and attackers can still intercept broadcast packets, the risks of “replay” attacks are minimal due to the limited time of validity of the data broadcasted: in majority of TOTP implementations, the period is less than 30 seconds [29]. 51

4.2.4 Beacon Authpath Prototype Implementation and Validation In this section, we first detail our model implementation with Estimote Beacons. Then we discuss what the validation of this prototype has underlined including areas for extensions and current limitations. We have developed a prototype path verification app using Estimote Android SDK using Apache Cordova [67]. The app is a combination of an HTML5 interface connecting to android library using Cordova. The object passes nearby (within BLE’s allowable distances of 10 cm – 70 meters) certain points equipped with BLE packet emitter or harvester devices. Prototype app has a sample path containing four checkpoints. Two checkpoints were equipped with physical Estimote beacons, 2 remaining checkpoints used virtual beacon apps running on iPhone 5s devices. The interface consists of a graphical path showing the current location of the user and a list of checkpoints. Once a user approaches a checkpoint, the relevant checkbox becomes checked, and the user icon animation of moving to the checkpoint appears. The algorithm checks the order of the beacons ranging, e.g. if checkpoint #3 has been visited before #2, the checkpoint is ignored. For the prototype, any proximity is being considered valid (the TX power value is not checked). The Minor value of beacons are used as their identifications.

Figure 43. AuthPath Android application interface A simple implementation of an Estimote SDK based app has demonstrated how a physical path can be validated using a set of BLE beacons. The exact approach can be used for a real-life application with some improvements: the identification of BLE beacons should be based on UUID with Estimote security enabled, and the validation should be done with integration of Estimote Cloud API into the application. The accuracy of the proximity authentication can be improved by checking the transmission power of checkpoints’ BLE beacons (RSSI value), e.g. if we want to validate a checkpoint as passed only if the distance was below 20 meters. Another possible use area might be Augmented Sports; namely, a smaller scale version of Amateur radio direction finding (also known as radio orienteering) [68] where the only equipment required would be a smartphone and a path of BLE beacons need to be followed showing the best speed and accuracy possible.

52 Context-Aware Multi-factor Authentication for the Augmented Human

As already described above, older hardware and mobile operating systems do not fully support Bluetooth 4.0. In addition, many users still perceive Bluetooth as a battery hog. Therefore, for a number of real-life applications BLE might be a less favorable option. We are proposing the following as alternative solutions to avoid using BLE in the use-cases researched: 1) Wi-Fi SSID based beaconing – a technology similar to iBeacon but less accurate in determining distance between devices 2) Signals of opportunity (SoOP) [69] based geo-location. This solution uses no beacon devices at all and is more accurate outdoors. However, some companies, such as Merlin [70], are promising to provide better accuracy even indoors using the same technology.

4.2.5 Summary In this part, we have proposed a new authentication model based on physical location of a person wearing or passing by BLE beacons. It was validated with a real implementation, which is an Android application. Future work shall involve larger scale deployment and tests in the shops of a real smart city in the mountain, i.e., a smart ski resort.

4.3 Physical presence verification using TOTP and QR codes

4.3.1 Introduction Presence verification features are highly demanded in a number of industries, and one of the most demanded features for medical institutions for cases where different parties are contracted to periodically visit patients to provide services. This applies not only to external service providers but also to providers within the same institutions. Often, hospital systems provide services within an enterprise, demonstrating the level of interoperation abstraction within the same organization. Usual methods of presence verification are consisting of a simple paper-based schedule table where the service providers just put the current date and time and their signatures. Being simple enough and easy to implement, this method, however, does not guarantee the accuracy, as the signatures on the paper are easy to back-date and/or forward date. The method introduced in this work will allow to securely implement presence verification using a special mobile application and a static hard-ware token displaying two-dimensional barcodes.

4.3.2 Concept The system proposed in this thesis is based on three main components: a stationary hardware token, a mobile app and a verification server. The stationary hardware token is an isolated device that is to be installed next to the patient’s bed and can be powered using a regular electrical network. The mobile app is to be installed on the smartphones carried by the service providers’ employees and will be used to record their presence using the hardware tokens showing the 53

current OTP in a QR code for-mat. The verification process is based on Time- based One-time Password Algorithm (TOTP) algorithm [30].

4.3.3 Implementation The proof of concept implementation is quite simple: we are planning to use a special hardware token showing TOTP codes in both as digits as well as QR code (the stationary device) and a smartphone for the verification client (mobile app or web application) to run. For production use, the stationary device needs to be hardened both physically and at the operating system level to prevent the modification, especially system time adjustment, which may allow replay attacks. In our implementation, in addition to the components having the shared secrets stored (the validation server and the QR generator) there will be a third component used to read the current OTP as a QR and storing its value together with the current timestamp. The combination of the OTP and the current timestamp will be the basic principle of the presence verification. The action flow is illustrated on flow Figure 44.

Figure 44. TOTP-QR action flow

4.3.4 Proof-of-concept device The stationary part, that can also be called TOTP-QR token consists of a computational component (using common programming frameworks based on C or C++), with real-time clock as TOTP algorithm relies on accurate time to calculate one-time passwords. The device also has an LCD display device, which will display a QR code to be scanned by the client app. A device prepared to illustrate this contribution was created as a proof-of-concept and is shown on Figure 45 .

54 Context-Aware Multi-factor Authentication for the Augmented Human

Figure 45. PoC Device for TOTP-QR solution

4.3.5 Summary With the idea presented in this it is already possible to state that this would be a significant improvement in the area of keeping records of a physical presence of a person in a particular location compared to methods currently in use, mainly paper based. The concept can be used to be implemented in areas like medical service providers or other similar domains. For example, this can be used to quickly and securely log visits of a doctor or cleaning services employees in a patient’s room. The main concept of the authentication does not change (it is still using TOTP), and a regular hardware token can be used to achieve the same results. However, displaying the OTP codes as QR code greatly improves user experience and allows avoiding human errors (typos when entering OTPs manually), therefore is fully meeting the goals of this research, particularly in the area of improving user experience. This concept was already presented as a work-in-progress paper [71] , and a web application was created to show the proposed implementation sample as shown on Figure 46. 55

Figure 46. Web application for presence verification using TOTP-QR concept

4.4 WifiOTP: Pervasive Two-Factor Authentication Using Wi-Fi SSID Broadcasts Traditional two-factor authentication solutions use standalone hardware or software tokens that generate one-time passwords (OTP) for the second step of the login process [72]. Users need to transfer OTP to the primary system to complete the process. In most of the cases, users need to type the OTP manually. This introduces a certain level of inconvenience to users. WiFiOTP is a concept of simplifying user interaction with systems requiring two- factor authentication by eliminating the need of typing OTPs manually; instead, an isolated standalone device (WiFiOTP Token) will generate and broadcast OTP as a part of wireless network service set identifiers (SSID). This SSID will contain a system ID and an OTP, encrypted with a symmetric algorithm. The hardware requirements for WiFiOTP are minimal, a WLAN network adapter is, in fact, the only requirement. Software requirements are not strict either; as a part of the concept, we have successfully implemented the WiFiOTP Client applications for Windows and Android. WiFiOTP tokens can run on any Windows or Linux computer or WLAN routers running any Linux based operating system (e.g. OpenWRT [73]).

4.4.1 Related Work Zero Interaction Authentication (ZIA) [74] is one example of an effort for making security easy to use. A few academic papers include concepts of using existing

56 Context-Aware Multi-factor Authentication for the Augmented Human

wireless or wired network components for ZIA. However, the proposed systems [75] are based on connecting to common wireless or wired networks which makes it impossible to use in systems that do not allow multiple wireless connections and presents additional risks of network based attacks. These papers also use constant characteristics of network components, such as BSSID of a WLAN network or a MAC address of network routers, which could make the systems vulnerable to replay attacks. A system based on WIFI SSID is proposed by Namiot [57] where SSID is used as a context-aware application concept. This paper describes using the information exchanged between access points and client devices to determine proximity data and using this proximity data to send promotional information, similar to Apple’s iBeacon technology but based on Wi-Fi rather than BLE. This paper uses similar concept of utilizing Wi-Fi SSID to relay information but does not provide any security analysis as the system is not intended to be used as a security mechanism. SSID broadcasts-based systems are researched by authors [76] where they propose to channel the authentication data via SSID, however their approach assumes two-way communication between the client and the SSID Access point. This approach is logical if the purpose is to be used in a typical online banking system where user interacts with the second factor authentication system. In this approach, the client device sends a packet and receives a response from the system broadcasting SSID in both directions. The limitation of this method is that the client device will need to emit SSID broadcasts and not only scan for SSIDs; this method is a significant obstacle for systems using WLAN as their primary connection. This would not be required for TOTP based systems as only one-way data flow is needed for such systems. Amigo [77] is another example of proximity authentication based on Wi-Fi proximity, which utilizes promiscuous mode for 802.11 frame packet scanning. This system requires at least three trusted devices in the close proximity (few meters), which can be considered a major drawback compared to WiFiOTP which requires only one device providing Wi-Fi coverage with minimal signal strength (up to 100 meters).

4.4.2 About WiFiOTP Solution

4.4.2.1 System model The client part consists of an application running on user's device that queries the WLAN network adapter for the list of currently available SSIDs and finds the one with required prefix (System ID) then decrypts the OTP part using shared key and sends as text to the relevant input fields. As a result, the authentication credentials contain three authentication components: the username (entered by user), password (entered by user) and OTP (automatically read from SSIDs and decrypted instantly upon activation). The solution consists of two main components: - A connector application or a service/daemon running on the client device that scans the broadcasted SSIDs periodically or when initiated by users 57

- An OpenWRT based Wi-Fi access point running WiFiOTP PHP script that broadcasts a special SSID that contains the encrypted one-time password together with other data (e.g. system ID etc.) The system’s principle is illustrated in Figure 1. The device used as an access point is using a locally stored secret hash to generate OTP values and broadcasts an SSID that includes the system identifier and the current OTP. OTP values change periodically (every 30 seconds as per TOTP specification [29]), therefore the broadcasted SSID equally changes.

Figure 47. WiFiOTP Logical diagram

The format of SSID broadcasted by WiFiOTP token is shown in Figure 48.

58 Context-Aware Multi-factor Authentication for the Augmented Human

Figure 48. Format of the SSIDs broadcasted by WiFiOTP tokens

The connector application on the client device scans the broadcasted SSIDs periodically searching for SSIDs starting with a predefined prefix (in the example above, “WOTP__”) then parses the SSID name to extract the system ID and encrypted OTP. The system ID is used to distinguish between multiple WiFiOTP accounts running in parallel on the same token device. The last portion of SSID, Increment ID, is required to overcome the SSID name “caching” on the client systems. The value of Increment ID will increment on every OTP change and the SSID with larger increment value will be used as the current OTP (if the increment reaches 99999, the SSID with increment equal to 1 will be considered the most current one). The client application may use a predefined API to pass the authentication data to the validating server, or just pass the parsed data to another application (i.e. a web browser) using a keyboard shortcut or other methods. This data flow is illustrated in Figure 49. 59

WiFiOTP Login Form token

A A u u t t h h e e n n

d t t r i ic c o P a a w T t t S s i i O s o o S a n ID d n P e R B t R e WOTP_1234 ro p e e y a m s q r d a p u c

_A7AD8F09 c n e o e a r

d s e n s t 6_1122 s s t

U e

User name Pa ssword

User WifiOTP Client Web Application

Figure 49. WiFiOTP Data flow model

In this example, the current OTP (decrypted by the client application) is passed to the server together with the first authentication factor (username and password). At the final step, all submitted data is verified on the server: username and password checked for validity and submitted OTP checked with the OTP generated on the server using the same secret hash.

4.4.2.2 One-Time password generation and encryption As described above, we will be using TOTP as the standard for generating OTP. In principle, TOTP is a version of HOTP where the current time is used as a part of secret key [29]. The value of OTP is calculated using standard TOTP function described in 3.1. With WiFiOTP, OTP is encrypted with a symmetric encryption algorithm in order to avoid transmitting current OTPs in plaintext. Due to the limitations of SSID name length (maximum 64 characters), the algorithms that can be used for this step are also limited. The value transmitted using WiFiOTP is calculated using the function shown Equation 4, where: CipherEncrypt – a symmetric encryption function (e.g. RC4), E - a key for encrypting the OTP (known to WiFiOTP device and the client application).

60 Context-Aware Multi-factor Authentication for the Augmented Human

Equation 4. WifiOTP SSID Generation WiFiOTPServer (K, T, E) = CipherEncrypt (TOTP (K, T), E)

The client application will scan the broadcasted networks and select one SSID matching the defined conditions (e.g. having a specific prefix and the highest increment number). Then, the OTP to be transferred to the authentication server will be calculated using the formula shown in Equation 5, where: COTP- the ciphered value of OTP broadcasted as a part of SSID, CipherDecrypt - a decryption function utilizing the same key as in WiFiOTPServer function.

Equation 5. WifiOTP OTP Decryption WiFiOTPClient (COTP,E) = CipherDecrypt (COTP,E)

4.4.3 Evaluation of WiFiOTP Solution

In order to evaluate WiFiOTP in practice we have created the following prototypes as a proof of concept: WiFiOTP Token: a) a service running on a Windows 7 computer with a wireless network card b) a modification of a standard wireless access point running on OpenWRT WiFiOTP Client: a) an application on Windows 7 b) an Android application c) an Android custom keyboard

4.4.3.1 WiFiOTP Token WiFiOTP Token is the central component of the system. It periodically generates the one-time passwords based on the stored secret hash key and the current time and broadcasts it as a part of a wireless network name (SSID) in an encrypted format. We have created two versions of WiFiOTP Token, a standalone device and an application running on a Windows operating system. A commodity access point running OpenWRT was used to create a standalone WiFiOTP Token. OpenWRT allows running commands modifying Wi-Fi network parameters, including changing SSID broadcasts, without reloading the system [73]. For our proof of concept, we have installed PHP scripting language and utilized PHP based open source TOTP libraries to generate one-time passwords [78]. The device used for this proof of concept is NEXX WT3020 [79], a miniature Wi-Fi router with 8Mb of flash memory, which allows installation of additional modules needed to run required scripts. 61

Figure 50. Standalone WifiOTP token based on NEXX WT3020 router

The WifiOTP token PoC shown in Figure 50, based on the miniature Wi-Fi router, was used also for the user acceptance survey test-drive exercise described in Chapter 5.

Figure 51. WiFiOTP Token on a standalone OpenWRT device

As building or configuring a standalone WiFiOTP Token device might be rather complex, in order to ease the evaluation; a Windows application has been created to emulate WiFiOTP Token. Due to security concerns, such an application is not recommended to be used in a real production scenario. Windows application is

62 Context-Aware Multi-factor Authentication for the Augmented Human

based on creating computer-to-computer (ad-hoc) wireless network using “netsh hostednetwork” command. An application has been created using Autoit [80] that generates and encrypts one-time passwords and passes SSID name as an argument to netsh command. This application can run on any computer equipped with a WLAN network card and a recent Windows operating system (tested on Windows XP, Windows 7, Windows 8.x and Windows 10). The parameters, such as SSID prefix, secret shared key and encryption key are stored in an ini file.

Figure 52. WiFiOTP Token application for Windows

4.4.3.2 WiFiOTP Client applications WiFiOTP Client searches for the SSID with encrypted one-time passwords broadcasted by WiFiOTP Tokens. For this proof of concept, we created a Windows client application and an Android app. The user interaction model of each application is explained within the use cases section of this thesis. Standard Windows netsh command is capable of scanning the SSIDs broadcasted (“netsh wlan show networks”) [81]. The parsed SSID data needs to be decrypted and sent to the input field requesting OTP, which is then submitted the validation server together with other data. A simple system daemon has been developed using Autoit [16] monitors a specific keyboard shortcut (e.g. Ctrl+Alt+X) to send currently broadcasted OTP to active text input. Optionally, it can send return character together with OTP to minimize user’s interaction: e.g., when user is prompted to enter OTP in a web application, pressing Ctrl+Alt+X, will insert the required OTP and submit the current form immediately. A screenshot of a running WiFiOTP Client application is shown in Figure 53. WiFiOTP Client for Windows. The window below shows the current OTP for demonstration purposes only; the client application should run silently in the background with only an icon displaying its activity in the tray area.

63

Figure 53. WiFiOTP Client for Windows

Furthermore, we decided to prototype an Android application for WiFiOTP Client using PhoneGap [82] platform. A PhoneGap plugin scanning Wi-Fi networks currently in range was created for this prototype application. The broadcasted OTP is fetched by the application using the same methods as with the Windows application. The unencrypted OTP can subsequently be copied to the clipboard allowing pasting of the current OTP to a relevant field in any application (e.g. a web browser).

Figure 54. WiFiOTP Android Client. Clipboard mode

64 Context-Aware Multi-factor Authentication for the Augmented Human

The application can also act as a web browser, and in this mode, the field requesting the OTP is populated automatically.

Figure 55. WiFiOTP Android Client. Web Browser mode

Using a separate mobile application introduces a number of restrictions, the main one being the inability to use WiFiOTP with any standard application, such as a web browser. To resolve this, we need a resource containing WiFiOTP Client code, which would be available to any application throughout the system. Android allows developers to create custom keyboards and run any type of code associated with its keys, including scanning for available Wi-Fi networks [83]. We have created a custom keyboard, based on a sample provided within the Android developer guide [83]. The keyboard consists of two keys: the first will execute Wi-Fi scanning, parse and decrypt OTPs broadcasted by WiFiOTP Token and insert the OTP to the current input field, the second will delete contents of the current input field. User interaction required for our initial implementation of WiFiOTP Android custom keyboard is shown in Figure 56. As can be seen from the image, the user interaction for entering the second factor to authenticate can be reduced to two actions: selecting WiFiOTP keyboard and hitting “Insert OTP” key. This process can be simplified further to reduce the number of actions to one: this will require the keyboard to automatically send an OTP upon activation.

65

Figure 56. WiFiOTP Android Custom Keyboard

Having an additional keyboard only for authentication purposes may introduce a certain level of inconvenience for users, especially for users frequently using more than one keyboard layout. To overcome this, a custom keyboard containing standard language layout and one additional key to insert OTP can be created. With this keyboard set as default, a user interaction to enter the OTP in the relevant field is reduced to pressing a key when prompted. See the example below (Figure 57) of such a keyboard based on English (US).

66 Context-Aware Multi-factor Authentication for the Augmented Human

Figure 57. Custom WiFiOTP Keyboard based on English (US) layout

4.4.4 WifiOTP Use cases In this section, we present two use cases to illustrate the usage of the WiFiOTP in real-life scenarios. Both cases will consider logon to a web application with two- factor authentication enabled account. As a part of use case review, we will compare user experience with a classic two-factor login process that has the following steps (assuming correct credentials are supplied): 1) The user navigates to a login page 2) The user enters first factor credentials (username and password) 3) The user submits the login form, either by clicking on a button or hitting Enter key on the keyboard 4) On the next window, the system asks for the second factor (one-time password), where the user manually enters the digits shown on the device or mobile application (OTP) 5) Login process completes The flowchart of the classic process looks like shown in Figure 58. 67

Figure 58. Classic two-factor authentication flowchart

4.4.4.1 Use case 1: Minimal user interaction Using WiFiOTP Client for Windows is an example of this use case. Assuming a WiFiOTP Token is correctly configured and active, the procedure of logging in to a standard system with two-factor authentication will consist of the following user interaction stages: 1) The user navigates to the login page 2) The user enters first factor credentials (username and password) 3) On the next window, when the system asks for the second factor (one-time password), the user presses Ctrl+Alt+X combination on the keyboard 4) Login process completes As can be seen from the procedure, also illustrated in Figure 12, the second factor is entered automatically, with the only difference of using a specific keyboard shortcut (Ctrl+Alt+X) instead of hitting enter or clicking on Submit button.

68 Context-Aware Multi-factor Authentication for the Augmented Human

Figure 59. Two-factor authentication flowchart with WiFiOTP Windows client

This use case requires no modification on the authentication server side, thus can be used on existing systems with two-factor authentication implemented in one (where both factors are requested in the same time, e.g. on the same login form) or two steps using any standard software. This use case was successfully tested on a number of public services (including Gmail and Dropbox) using a standard web browser, as well as special applications (e.g. Google Drive). This use case is also valid for Android custom keyboard.

4.4.4.2 Use case 2: Zero user interaction To demonstrate this use case, we have developed an Android WiFiOTP Client application that will allow zero user interaction for providing the second factor during the authentication process. Procedure for this use case is as follows: 1) The user launches the mobile application 2) The user enters first factor credentials (username and password) 3) On the next window, when the system asks for the second factor (one-time password), the mobile application automatically populates the relevant field with OTP and submits the form without any user interaction 4) Login process completes The flowchart shown in Figure 60, illustrates that there are no additional actions required from the users to securely authenticate, which makes the user experience similar to one-factor authentication systems. 69

Figure 60. Zero user interaction two-factor authentication using Android mobile application

4.4.4.3 Summary of reviewed use cases Both use cases demonstrated that using WiFiOTP simplifies users’ interaction compared to classic two-factor authentication systems. Although case 1 still requires additional user action, it has its advantages, as it can be used with existing client-side applications without any modification of authentication systems. With Use case 2, user interaction is reduced to zero, but the method can only be used via a special mobile application. A detailed summary table of use cases is provided in Table 3 below.

Table 3. WifiOTP Use case comparison Comparison Classic two-factor Use Case 1 Use Case 2 aspect authentication User interaction The user should Minimal Zero manually type OTP (keyboard generated by shortcut) hardware token or mobile application Software No additional Can be used Access to requirements application on the with any systems can client system. application on only be done the Windows via WiFiOTP operating Android system application Server-side (web Any Any Any application)

70 Context-Aware Multi-factor Authentication for the Augmented Human

WiFiOTP Token Any Any Any Hardware Network access Wireless Wireless requirements equipment Network Card Module (wireless, wired or cellular)

Additionally, we would like to clarify that the platforms chosen for both use cases are only examples chosen for our evaluation and not based on any technical restriction: i.e. Use Case 2 can be easily implemented as a Windows application and vice versa. Due to the fact that the interaction flows are similar for Windows Client and Android custom keyboard-based solution, we have not reviewed it as a separate use case. Both use cases demonstrated no interference or another negative effect to any of existing wireless or wired networks: we successfully tested the functionality on systems connected over different networks (such as Wi-Fi, wired network and cellular data network on mobile devices) as per current and proposed connectivity standards [84] [85].

4.4.5 Security analysis Generic security analysis of proposed two-factor mechanism is already done by many authors, and we will refer to existing works [86] [87] as full analysis would be out of the scope of this dissertation. An additional security risk is introduced by transmitting OTPs via SSID name broadcast, which is publicly readable. This risk is still minimal even if OTPs are transmitted in plain text and equal to a situation when attackers gain access to the OTP device (e.g. a hardware token). However, even with this minimal risk, we attempted to eliminate it by introducing symmetric encryption of broadcasted OTPs using RC4 encryption algorithm. RC4 is rather weak compared to other modern cryptographic methods [88], however, the limitation of the SSID length [85] does not allow many options to choose from.

4.4.6 Summary User authentication is a balance of security and user experience. This thesis presents the possibility of creating a simple and low-cost two-factor authentication system that simplifies user’s interaction compared to existing solutions by minimizing or completely eliminating the actions required to add the second factor for authentication. The solution proposed also presents a possibility of introducing an additional authentication factor – the physical location of the user, which makes it a good example of the authentication for the Augmented Human. Most of the systems utilizing multifactor authentication are designed to enrol users with generating a secret key on the server side and transferring to clients when enabling the second factor. A system to transfer these keys securely to WiFiOTP device is needed to simplify the enrollment. 71

One of the options could be a mobile application that can read a QR code using the camera and transfer the parsed key to the device. The same needs to be developed for key reset or broken device replacement procedures. Experiments have shown that system clocks on devices are very important to be in accord with the highest precision possible. Therefore, a time synchronization mechanism for WiFiOTP devices needs to be developed to overcome possible time mismatch issues. The evaluation done in preparation of this thesis included only Windows and Android applications. Applications for other platforms (such as MacOSX, Linux and Windows Phone) should also be created where possible. Unfortunately, API methods for scanning wireless networks are not publicly available for current versions of operating systems for iPhone/iPad (iOS), therefore it is not possible to implement WiFiOTP Client for iOS [89]. However, if in future versions, these methods become available, iOS version needs to be considered as well. OTP encryption security can also be significantly improved by using vendor- specific information element field of WLAN network broadcasts instead of SSID name. Vendor-specific information element field allows up to 252 bytes to be transmitted [90], and this will allow using stronger cryptography mechanisms to encrypt broadcasted sensitive data. Vendor-specific information element could not be used for our implementation due to limitations of software components used to create WiFiOTP Tokens. One of the advantages of using stationary WLAN systems to serve as WiFiOTP Tokens (e.g. Wireless Controllers with multiple access points broadcasting the same SSID in an office building) can be the possibility of verifying user’s physical location. This aspect of WiFiOTP is yet to be researched in the context of secure proximity-based authentication.

4.5 Hardware token provisioning with the full control of the seeds There are questions constantly arising about the security surrounding the shared secret key hashes (seeds) of classic hardware tokens, especially after a security incident with security giant RSA in 2011 [91], where secret keys of their hardware tokens were compromised due to a successful phishing attack. When it comes to transferring the keys to end users, most vendors strongly recommend using PGP or GPG encryption to transfer secret keys for all types of tokens. PGP and GPG are popular solutions for encrypting, decrypting, signing, and verifying messages and files, often found in email communications and package repository identity verification. However, due to the nature of the production, there are many potentials of the seeds to be leaked and or compromised: the tokens are produced at remote locations and seeds are not only transferred from and to manufacturers but also kept at the factory’s computers, even for a limited time. Taking this into account, no one can fully guarantee the integrity. And here is when programmable tokens can show another benefit by allowing hardware token provisioning with the full control of the seeds.

72 Context-Aware Multi-factor Authentication for the Augmented Human

4.5.1 Token2 TOTP Toolset To achieve provisioning with allowing the end users to have the full control of the seeds, we have developed a simple HTML5 application (named "Token2 TOTP Toolset") which can be run locally without accessing any libraries/resources on the Internet (including the QR image generation). This application is designed to generate random seeds and produce CSV file ready to be imported to different authentication systems, such as Azure MFA. The source code if the application is available on GitHub [92]. TOTP Toolset can be run locally without accessing any libraries/resources on the Internet (including the QR image generation) and has the following set of features: • converts hex seed to base32 format and vice versa • generates QR image based on hex or base32 seed key values • generates random seed values to be used with programmable tokens • verify the time drift with customizable skew value • create CSV for Azure MFA and similar systems

Figure 61. Token2 TOTP Toolset

4.5.2 Secure hardware token provisioning with Token2 TOTP Toolset The provisioning shall be done in the following way: • Download and launch Token2 TOTP Toolset - local. Users may want to run this app on a computer that is fully offline (or firewalled) to be sure no information is being transferred to third parties • Install Token2 Burner App on an Android device with NFC. After the app has been installed, users can set the device to flight mode with Bluetooth, WIFI and Cellular data off to ensure no data will be transferred outside 73

• Generate a random seed using Token2 TOTP Toolset. • After the seed is generated, burn the seed using the Burner App • Verify the OTP shown on the device with the OTP value shown on the TOTP Toolset • Enter the serial number of the programmable token and the username in UPN format to the relevant fields on the TOTP Toolset and click on " ⇲ append to CSV" button • Repeat steps 3 to 6 for every token you are provisioning • Click on "save as file" button and save your MFA CSV file • Import the CSV to Azure MFA • The tokens are ready to be activated for users

4.6 miniOTP-2 — a programmable hardware token with time synchronization

4.6.1 Time drift: a major downside of TOTP hardware tokens The TOTP scheme requires hardware tokens to have real-time clocking capability by embedding an oscillator in the device. A token’s clock drift needs to be considered and accommodated accordingly by the server. The protocol also advises the server to implement “look-ahead” and “look-behind” windows to for resynchronization when a tolerable amount of clock drifts have happened on the token. While this is less critical with mobile authenticator apps (because mobile devices get their system clock synced via the cellular network or internet), all TOTP hardware tokens have a natural tendency to introduce time-drift after some period. This a well-known limitation of most oscillators, also mentioned in the RFC 6238: #6 [29], and therefore the authentication server must be able to cope with the potential time-drift with TOTP tokens in order to minimize any impact on users. While most of the servers are ready to follow this recommendation (such as Azure MFA server which does this automatically, or TOKEN2 TOTPRadius reviewed in 4.7, where time drift can be set manually), there are many implementations where this recommendation is neglected (for example Duo [93]). After a period of time (i.e. 1–2 years) many of the tokens will drift outside of the global synchronization window. While this has not changed a lot for the last 20 years, the battery life of modern tokens is now much longer. So, in the past, a hardware token battery lasted for 2 years and the maximum time drift introduced would be only 4 minutes. Now there are tokens with batteries good enough to work for over 5 years, which means that after its 4th year, even though the battery is still good to allow using the token for another year, the token cannot be re- enrolled to a different authentication server as its time drift would be almost 10 minutes and very few systems would support such big discrepancy. A token that is not used very often is likely to drift even more beyond the synchronization window that an authentication server is using. In addition, organizations are afraid to keep a large stock of hardware tokens: a token that is not used at all will have its battery almost like new, but the time-drift will not allow using the token at all,

74 Context-Aware Multi-factor Authentication for the Augmented Human

which causes such investments to be completely unprotected. While TOTP as an authentication protocol is secure and very easy to implement, the issue described above is seen as one of the main disadvantages, at least as far as hardware tokens are concerned.

4.6.2 MiniOTP-2 as a Potential Solution To address the issue above, we have developed a concept solution that would allow syncing the clock of hardware tokens. There are already programmable tokens on the market [43] where users can set seeds using our burner app via NFC. However, there was no way to fix the time drift on hardware tokens, even programmable ones. Changing the time on a hardware token is not as simple as adjusting your wristwatch: there is a minor potential security risk (TOTP code replay attack) if it is only the system clock that is being changed. The code replay attack is quite easy to explain. Imagine a user being under attack and the attacker has access to the hardware token, even for a few minutes only. If we allow changing the time only, the attackers can set the time in the future and write down the OTP code the token generates. This process can be repeated a significant number of times, so the attacker would have, let’s say, 100 OTP codes that the victim’s token will display at certain times in the near (or far) future. This already means that the second factor is compromised and is equal to attackers having the tokens shared key/seed. Once this has been achieved, the attackers only need to get access to the first factor, e.g. the password, which is much easier to implement, and later, when the time of validity of the OTP codes arrives, both factors will be compromised. To address the TOTP code replay attack, the time sync procedure we plan to implement with miniOTP-2 will be combined with reseeding the token using a burner app shown on Figure 62 .

Figure 62. Token2 Burner App with time synchronization feature

Another method of preventing replay attack would be limiting the possibility of adjusting the time to a value that is defined by the oscillator’s accuracy. This limit (L) can be calculated by the Equation 6.

75

Equation 6. Time adjustment limit for miniOTP-2 퐿 = ±(퐷 × 퐵)

Where: D – is the expected time drift depending on the accuracy of system clock used in the token. Usually about 2 minutes per year. B – expected maximum life of the battery used in the token. The value of the limit L, then should be used in the TOTP time counter calculation as an additional argument as shown

Equation 7. Time counter with time adjustment Current Time − T0 ± L 푇푐 = Ts

This modified time counter Tc, can then be used in the standard TOTP Equation 3 already described in the previous sections.

So, the replay attack is addressed by a time of a token that can only be set together with its secret key or within the allotted maximal range, however currently there is no real prototype that can implement these restrictions at the chip level. However, the fact that the seed can only be set, and never be read, from programmable tokens (the current model and the future miniOTP-2) will make sure the seed is only accessible by the authentication server. Therefore, unauthorized access to the time adjustment of the hardware tokens will not result in the replay attack. Contrary to this, if the time setting is set by a legitimate user (i.e. the administrator), the seed set together with the correct time value will also be set at the authentication server, or vice-versa, a new seed will be requested to be generated by the authentication server to be written to the token together with time synchronization. Meanwhile, worth mentioning that the risk of such attacks is minimal and can be performed only if all of the following conditions are met: - The first factor (username and password) is already known by the attackers - Attackers have physical access to the hardware token - Attackers can discreetly access the hardware token over NFC for a long period of time (i.e. 15-20 minutes are needed to set the time, generate significant amount of future OTP codes and set the time back). These conditions are relatively hard to be met and can be compared to a situation where a hardware token is stolen.

4.6.3 Summary As per our research, currently, there are no TOTP hardware tokens with time synchronization feature existing on the market, meanwhile, this feature is in very

76 Context-Aware Multi-factor Authentication for the Augmented Human

high demand as per the feedback we are getting from our customers. Being big fans of TOTP as a protocol, we believe it will get its second breath with this new product — miniOTP-2 a programmable hardware token with time synchronization. Furthermore, this will be a huge step towards investment protection for organizations willing to invest in TOTP hardware tokens. Mass production of miniOTP-2 is currently being discussed and arranged with a number of factories in China. Due to NFC antenna surface limitation the programmable hardware tokens (both miniOTP-1 and miniOTP-2) are limited to be in card form-factor only.

4.7 TOTPRadius: Enhancing RADIUS-based MFA authentication systems with RESTful API for self- service enrolment

4.7.1 Introduction Majority of modern two-factor authentication solutions use standalone hardware or software tokens that generate one-time passwords (OTP) to be used as the second factor for the authentication process. Many systems use separate and, in some cases, isolated, Remote Access Dial-In User Service (RADIUS) [94] systems to serve the authentication of the second factor only. RADIUS is based on a simple transaction between a client and server. To ensure the secure communication channel between the client and the server, both are configured with a shared secret key. This secret key is used to cryptographically sign all messages in both directions to ensure integrity. RADIUS server keeps the attributes required to calculate a current second factor for each user enrolled and when requests are made, it calculates the second factor and compares it with user-provided data. If these values match, the authentication is accepted by sending an “Accept” response. Although more and more new context-aware authentication means are invented, legacy solutions such as RADIUS can benefit from these new solutions. The solution presented in this thesis is based on adding a registration or self- enrollment functionality to standard RADIUS systems by introducing an additional REST Web API library. Representational state transfer (REST) or RESTful Web services are methods of providing command execution and data exchange between computer systems on the network. RESTful web services are based on standard HTTP, or preferably, HTTPS protocol [95]. This thesis will review how RADIUS protocol is used in two-factor authentication systems as well as the architectural layout of such systems. A summary of the limitations of using RADIUS as the second-factor provider is reviewed together with a theoretical model of implementing self-service enrollment for two-factor authentication by complementing the standard RADIUS authentication protocol with RESTful based self-service registration service. This section will also present a proof of concept implementation of a RADIUS service with examples of integration. A conclusion on the proposed model and its implementation as well as a brief security analysis is presented as a summary of the proposed invention. 77

4.7.2 Review of existing implementations The primary goal for deploying two-factor authentication mechanisms is to increase the security of traditional identity stores such as Lightweight Directory Access Protocol (LDAP) [96], RADIUS or Active Directory (AD) [97]. Even though both factors (e.g. user password and one-time passwords) can technically be verified using one single store, industry’s best practices recommend separating first and second factor stores from each other. In Table 4 we have reviewed several products allowing enabling second-factor authentication and discovered that in the majority of cases, RADIUS servers are recommended as the identity stores for second factor only. All reviewed implementations use one-time passwords as the second factor based on time-based one-time password (TOTP) [29] algorithm.

Table 4. Review of products using RADIUS as a secondary identity store Product Primary identity Second factor-ready stores identity stores

VMware Horizon 7 Active Directory RSA SecurID, RADIUS

Citrix Netscaler 12 LDAP, RADIUS LDAP, RADIUS

Fortinet Fortigate VPN LDAP RADIUS

Microsoft Network Policy RADIUS RADIUS Server Microsoft Office 365 Active Directory Azure Multifactor Authentication. RADIUS

To illustrate the authentication flow, we will use an example of the configuration, where LDAP is used as the primary identity store and RADIUS is used as the secondary identity store. As shown in Figure 63, the user credentials requested by the login server consists of three fields: the username, first password (LDAP user password) and the second password. The authentication flow is happening in the following sequence: 1. User credentials are sent to the identification broker4 2. Identity broker sends credentials to the identity stores

4 Identity broker shown in this list as well as in the authentication flow is a logical component and depending on the implementation may or may not be implemented as a separate instance

78 Context-Aware Multi-factor Authentication for the Augmented Human

2.1. Identity broker sends the username and the first password to the LDAP Server 2.2. Identity broker sends the username and the second password to the RADIUS Server 3. Identity broker receives the response from the identity stores 3.1. Identity broker receives the response from the LDAP Server 3.2. Identity broker receives the response from the RADIUS Server 4. Identity broker allows or denies access depending on the responses received from LDAP and RADIUS.

Figure 63. An example of an authentication flow with LDAP and RADIUS identity stores

All reviewed solutions are relying on a pre-existing database of users in both identity stores they rely upon. While it is inevitable for the primary user base as a part of the user provisioning process, enabling the second factor by administrators is introducing additional negative user experience.

4.7.3 Use case review: Migration from classic to multifactor authentication Let us review a use case with an existing infrastructure in place, where the goal is to enable second-factor authentication. While there is no or minimal change in the primary authentication source, enabling the second factor using existing RADIUS solutions for users will bring the following inconveniences: - Mobile application enrolment: assuming that a mobile application on a user-owned (i.e. personal) smartphone is used as a second factor password generator; an administrator with the physical presence of the user must complete the enrollment process; alternatives to this method (such as sending the secret key by alternative channels, such as email) introduce additional security risks 79

- Hardware token provisioning: in case a hardware token is used as the second-factor password generator, the transition needs to be coordinated with the end users. In addition, it complicates the preparatory phase and the logistics of the process; i.e. a database with secret keys and hardware token assignment needs to be pre-populated before the migration - User migration and coexistence: migration from single factor to two-factor authentication for a large user base is not possible with the reviewed RADIUS-based solution. This means additional negative user experience as well as more resources for the migration. The main reason for this is that any user is obliged to enter a correct second-factor password in order to get access; this also makes the coexistence of both authentication methods impossible: i.e. all users must be one-factor or two-factor enabled and these two types cannot coexist

4.7.4 A theoretical model of self-service enrollment for RADIUS-based two-factor authentication

To address the issues given in the previous section, we will first describe a theoretical model of a RADIUS appliance that allows users to enrol the second factor without any intervention of administrators or IT helpdesk.

4.7.4.1 Initial login concept Prior to everything else, a user without any record in the secondary identity store would normally not be able to log in. To overcome this restriction, RADIUS server should allow a number of initial logins with empty or wrong second factor. The system needs to keep a log of such logins to keep the security at the acceptable level. With this method implemented, a user without a second-factor record created is able to log in and access the system using the first factor only (i.e. username and password). Upon successful login, where possible, the end system detects that the second-factor record is missing and prompts or forces the user to enroll to the secondary identity store. In the cases where showing a prompt or informational message is not possible, users shall be informed and instructed to do so using other methods (i.e. a message on the login page, instructions sent by email etc.). As per authentication flow of the initial login shown on Figure 64, the system (RADIUS server), in addition to regular user records database, will also keep history of login attempts of users without user records and allow access on first N attempts. For security purposes, the value of N needs to be kept as low as possible: ideally, N=1: only to provide users without user records with one single login in order to allow access the self-enrollment procedure.

80 Context-Aware Multi-factor Authentication for the Augmented Human

Figure 64. Initial login authentication flow

4.7.4.2 Self-service enrollment concept After the initial login has been allowed, the users are prompted to enrol for the second-factor authentication. This thesis proposed 2 methods of the second factor: hardware tokens and software tokens. For both methods, the self- enrollment is based on RESTful API, so the user shall launch a web page which will in its turn reach out to the RADIUS appliance and send the current users username (and the serial number in case of the hardware token method). RADIUS appliance will create a user record containing the username and the TOTP [30] secret hash, which will be randomly generated (for software tokens) or retrieved from hardware token hashes database based on the serial number provided. In case of software tokens, the generated hash will be returned back via RESTful API and displayed in a QR code format to the user in order to complete the software token enrolment. A structural diagram of this process is shown in Figure 65.

81

Figure 65. Self-service enrollment diagram

4.7.5 Proof of concept The proof concept of self-enrollment RESTFul API for two-factor authentication has been implemented for Citrix Netscaler and Citrix Storefront integration. Usually, two-factor authentication on the Netscaler is integrated based on Radius where usernames are the same as usernames in Active Directory or LDAP. When integrated with Citrix Storefront, NetScaler acts as a reverse proxy and Storefront serves as a web server. Therefore, the API calls between NetScaler and Storefront can be run directly over HTTPS. The implementation of the API is based on a virtual appliance code-named TOTPRadius that operates as a standard RADIUS server, but instead of standard static passwords verifies TOTP based one-time passwords. The network diagram of the solution is shown in Figure 66.

82 Context-Aware Multi-factor Authentication for the Augmented Human

Figure 66. TOTPRadius network diagram

4.7.5.1 Self-enrollment RESTful API This proof of concept is only accepting enrollment of software tokens (such as Google Authenticator [98])The RESTFul API of TOTPRadius looks like shown below:

https://[FQDN]/createuser?api=[api_key]&user=[username] where: FQDN – is the hostname or IP address of the RADIUS server api_key – the API key serving as an additional protection factor. The API key should match the key recorded in the server settings user – username of the current user Upon successful execution of the API call, the response contains the following information: text – response text notifying about the successful execution of the API call hash – the secret hash key generated and assigned to the user hashqr – hash key in the format of base64 data of the PNG image containing the QR code for creating TOTP profile on the mobile application 83

4.7.5.2 Implementation of Proof of Concept The proof of concept described in this thesis has been implemented and is available to be tested as a part of the Token2 project. The RADIUS server (TOTPRadius) [99] is a virtual appliance running on Ubuntu Linux 17.0 and based on FreeRadius 3.0. NetScaler/Storefront integration based on the self-enrollment API is also presented by Token2.

4.7.6 Security analysis and summary As the security of RADIUS protocol has been already reviewed in a number of papers [9, 10], this security analysis is covering only the new components of the solution, namely, the self-enrollment part and the initial login procedure. Depending on the implementation, the web application initiating the API call may present an additional security risk, however, in our proof of concept, the API is initiated from within Citrix Storefront, which is protected by the authentication mechanisms, thus it is not applicable. In theory, this could be a potential vector of attack; therefore, when implementing, it the following is considered to be the safe technique to run API calls to the RADIUS server: - The username of the current user should be securely identified - The API call should only be executed on the server side, and under no circumstances, the API Key should be visible to the end-users As described earlier, the API is intended to be reachable over HTTPS. This ensures the data is only accessible from the client and service endpoints. It is also important that the SSL certificate is set up correctly, and the initiator script is correctly verifying the validity of the certificate. Additionally, an API key is being sent and compared with the key recorded in appliance settings. Also, the API endpoint may be configured to respond only to a set of IP addresses or subnets. Enabling a self-service feature for users to manage their own devices would significantly save on training and support time. The RESTFul API concept introduces in this thesis is an attempt to enable self-service enrollment keeping the whole concept of RADIUS-based two-factor authentication, as it is a de-facto industry standard. The proof of concept used as an example, Citrix NetScaler and StoreFront based integration, proves that the concept can be integrated with minimum effort and maximize positive user experience. As a part of validation activities, we have been commercializing TOTPRadius under TOKEN2 project and already the initial sales results did show high interest and large potential market rate.

84 Context-Aware Multi-factor Authentication for the Augmented Human

Chapter 5. Validation of the results and comparative summary

A variety of modern multi-factor authentication systems was reviewed in this research. Each of the methods has advantages and disadvantages as well. While some of the methods are more secure, others are more convenient for end users. We have already compared MobileOTP and Google Authenticator in the previous section, in this section we will compare and evaluate some of the multi-factor authentication methods taking into account both its security and user experience aspects. The principle to be used in the surveyed research is often based on beacons of diverse types. The main idea is that beacons transmit the same set of data to both the client and the authentication server. Based on the comparison results the server accepts or denies the authentication request. The research surveyed uses existing technologies to determine the proximity factor, such as BLE-beacons (i.e. Eddystone or iBeacon) as well as innovative types, such as WiFi SSID broadcast beacons, Ultrasound and LiFi [100]. BLE beacons can be enhanced with additional context factors, such as temperature and humidity. As mentioned previously, biometrics-based authentication can also have been used as context, i.e., based on face recognition. This has quoted for comparison purposes only as it does not really fall under determined two-factor authentication as the second factor in this case (user’s face or voice) is also static.

A diagram of all variety of contextual factors reviewed in the previous section. In Table 5 we list factors we reviewed in the thesis and provide a justification of whether a further validation is necessary as a part of the results validation.

Table 5. Justification of context type selection for the validation exercise Context type Justification

Environment

Ambient The technologies described in this thesis are present mostly in sound and academic papers and there are no devices available on the light market to run the test drive with. They are also not reproducible as the papers do not disclose enough technical information. Furthermore, some of the aspects are protected by patents and intellectual property regulations. Access to a device

Mobile app This context is easily reproducible and will be added to the test drive. Google Authenticator [98] and OTPAuth [101] applications both under Android and iOS are free to use. Classic Classic hardware tokens are available to be purchased online. hardware For this test-drive a regular TOTP token purchased from tokens Token2.com will be used. The model is TC201 [102]. 85

Physical location

WifiOTP As this is a concept invented and prototyped by us, we will use it in our test-drive. A physical device based on miniature router will be used Wifi Proximity As per our analysis shown in 3.3.5 the Wifi proximity context is pseudo-dynamic and cannot be considered at the same security level than TOTP based solutions GPS GPS coordinates are more static and not spoof-proof Coordinates BLE Tokens From the users’ point of view these tokens will behave exactly the same as WifiOTP Other factors

IP Address IP addresses are relatively easy to be forged and cannot be considered as a trusted context

Based on these justifications, further in this chapter, we will conduct a user experience survey by proposing to compare a few context factors out of the full range in order to critically evaluate user acceptance of the new modern context- based multifactor authentication methods in comparison with classic MFA systems, such as classic tokens. As a result of the validation, a summary of user experience survey as well as the overall MFA related outcome ideas will be given.

5.1 User experience survey As far as user experience is concerned, the ideal authentication mechanism should require no additional actions from users. The focus of this work is to improve and minimize (ideally to zero) user interaction required to authenticate using additional authentication factors. This concept is described in “Zero- Interaction Authentication” paper [103] and can equally be applied to multi-factor authentication as well. In addition to classic authentication factors such as hardware tokens, this thesis will research modern solutions, many being in line with the Augmented Human concept, hence the title. The concept of using Augmented Human technologies in multifactor authentication is mainly based on using factors belonging to a user as a human being as additional authentication factors.

5.1.1 Purpose of the survey The ultimate goal of the new authentication systems proposed in this dissertation is to improve the user experience. As these are user related aspects, it is important to gather the opinion of a number of end users based on a comparison of the novel systems and classic multi-factor authentication systems. The user acceptance evaluations will be based on the results of user feedback comparing the following to MFA contexts:

86 Context-Aware Multi-factor Authentication for the Augmented Human

1. Classic hardware token – the context of “having something”, i.e. possessing a physical hardware token and having the possibility of pressing the button on it and reading the OTP generated 2. WifiOTP hardware token – the context of “location proximity”, i.e. being physically close enough to the device generating the WifiOTP SSID signals to be able to read and afterwards decrypt the OTP value encrypted in the SSID name. A sub-set of this context is, of course, having the relevant encryption key configured on the end-users’ system for security purposes.

5.1.2 Components The authentication system used for the user experience survey test drive contained the following components: - A web server with a web application - The forms-based authentication requesting the username, password and one-time password (OTP) - Second-factor contexts to be used for comparison (TOTP algorithm based, 30 seconds interval, 6 digits OTP): o Software token (Google authenticator installed on an Android phone) o Hardware token o WifiOTP token - Client system – a client device used to access the web application: a laptop with Windows 10 with a web browser and WifiOTP Client installed

Figure 67 illustrates the test-drive client device station setup as described in this section.

It is important to clarify why only WifiOTP was used as a part of the survey: the concept behind WifiOTP and other methods (i.e. BLE based) are the same from the users’ point of view. The differences between these methods are only the technologies used to transfer the OTP value between the tokens and target client systems. So as far as user interaction is concerned they are equally the same, but WiFiOTP can be created/emulated much easier than other technologies.

87

Figure 67. WifiOTP test-drive station setup

5.1.3 Survey scenario Before starting the test-drive, the concept behind WifiOTP was briefly explained. Each user was given a demo account credential (username and password) and a second-factor device (pre-configured/pre-enrolled). Users were asked to log in to the target web application by using all three methods in a random order.

Method 1. Log in with a mobile application (software token) a) On the laptop open the browser and navigate to the URL below: https://huseynov.com/projects/wifiotp/ b) Enter the demo credentials c) Launch the mobile application and look up the one-time password (OTP) shown on the screen d)In the OTP input field, enter the OTP code displayed on the mobile application and click Login Method 2. Log in with a hardware token a) On the laptop open the browser and navigate to the URL below: https://huseynov.com/projects/wifiotp/ b) Enter the demo credentials c) Press the button on the hardware token up the one-time password (OTP) shown on the screen

88 Context-Aware Multi-factor Authentication for the Augmented Human

d)In the OTP input field enter the OTP code displayed on the mobile application and click Login Method 3. Login with WifiOTP token a) On the laptop open the browser and navigate to the URL below: https://huseynov.com/projects/wifiotp/ b) Enter the demo credentials and click on Log in c) In the OTP input field, press the WifiOTP shortcut key and click Login

Figure 68. Demo web application with MFA login

After that, they were asked to provide a rating for each of the methods based on a scale from one to ten. Additionally, each user was asked to rate their experience in using two-factor authentication. This allows to evaluate the MFA awareness of the participants and adjust results accordingly (i.e. produce a comparison results report based on the feedback from users with MFA experience higher than 7/10). Users were asked to provide a rating (from 0 to 10) for the following: - Their experience with MFA - User friendliness of: • Hardware Token • Software Token • WifiOTP Token 89

5.1.4 Capturing the results Depending on the total number of survey participants and the modality (onsite or remote participation) the results were captured in an online survey form as well as recorded video (in some cases the testing process is was captured as well). The test-drive was be recorded on video for potential behaviour analysis. The participants were asked to answer post-test-drive questions. The following questions were asked: - Was the test-drive organized in a way to allow you to adequately test different methods? - Do you understand the concept of WifiOTP? Can you explain it in one sentence? - In your opinion, which of the third methods is the most user-friendly? - Would you use WifiOTP as your authentication method in production?

5.1.5 Results The feedback gathered during the report was compiled in a table shown in Table 6 and used in the dissertation as a part of results validation.

Table 6. User survey results: comparative summary MFA MFA Hardware Software WifiOTP Solution Experience tokens Token User 1 7/10 7/10 8/10 9/10 User 2 6/10 6/10 8/10 9/10 User 3 7/10 7/10 8/10 9/10 User 4 6/10 6/10 8/10 9/10 User 5 10/10 6/10 9/10 10/10 User 6 7/10 7/10 8/10 9/10 User 7 7/10 7/10 8/10 9/10 User 8 6/10 6/10 8/10 9/10 User 9 6/10 6/10 8/10 9/10 User 10 10/10 6/10 9/10 10/10

5.2 Survey Results Analysis The user survey was organized by 2 different institutions and a total of 15 participants have completed the full survey. The mean time for completing the survey was 10 minutes, which included the preliminary background info on the techniques being tested and the time taken by the test-drive itself.

90 Context-Aware Multi-factor Authentication for the Augmented Human

The survey gained 13 responses, of which 10 were included in the analysis; 2 of the responses were flawed, probably for technical reasons and one response had signs of duplication (all responses were the same as one of the previous respondents). Before the test-drive, a pre-selection was done by asking a question on the respondents' MFA experience as a rating out of 10, which generally showed an elevated level of technological orientation in the context of MFA. Among the 10 respondents selected for the test-drive 4 of them were reporting their MFA experience as 6 out of 10, four respondents indicated as 7 out of 10 and only 2 responded with the MFA experience to be 10 out of 10.

Figure 69. MFA Experience of the survey respondents

After the test-drive, where the users logged in into the same web application using different MFA methods, the respondents were asked to share their opinion by giving a rating (out of 10) to each method they tested.

91

Figure 70. Comparing different MFA methods

As shown in Figure 70, respondents agreed strongly that modern authentication methods (namely, WifiOTP) prevail in comparison with classic methods, which they had a chance to compare with, such as hardware tokens and mobile authenticator app. In this sense, the overall profile of the respondents is in line with our target of gathering user perspectives from early adopters and users who are technologically adept enough to understand the principles and possibilities of modern MFA.

5.3 Commercialization Whilst commercialization clearly represents an important way for academic research to contribute to economy and society, this is also a method of validating the results of a particular research topic. As a part of the validation of the outcomes of this PhD dissertation, some of the products were commercialized and a number of adopters have already started using this in production.

5.3.1 Results To provide results validation we have organized an early adopter-oriented marketing campaign and have managed to sell around 1000 hardware tokens with time-sync and 500 TOTPRadius licenses sold. These results can serve as additional validation of the potential market interest in the new solutions we propose as a part of this PhD dissertation.

92 Context-Aware Multi-factor Authentication for the Augmented Human

Chapter 6. Conclusion and Future work

6.1 Conclusion Credentials comptonization is nowadays a leading cause of security incidents across the world. As per Verizon’s 2016 Data Breach Investigations Report [104], the absolute majority of security breaches were taking place with involving stealing credentials from end-user devices and using them to access different applications, primarily web-based. Such stolen credentials were made available to different types of potential attackers, generally on the dark web or similar, which made the nature of passwords as protection mechanisms no longer effective. The same report [81] also refers to a paradigm of the “inevitability of the click”. The report says that if an email is sent to six different addresses, the probability that one of the recipients will click on the link once is about 80%, which basically concludes that it only takes around twenty emails to get one successful click on a phishing attack, as shown in Figure 71.

Figure 71. The Inevitability of the Click (Verizon Data Breach Report)

Loose cloud adoption can develop this risk even further, as more and more account profiles are created, often using the same password or foreseen and simple passwords. With classic authentication mechanisms, passwords are the most vulnerable component in an attack chain. Once attackers penetrate the organizations with stolen credentials, they use tools like Mimikatz [105] and Pass- the-Hash [106] to compromise more privileged accounts and passwords until they reach their ultimate goals. 93

Implementing multi-factor authentication is a balance of security and user experience. The ideal multi-factor authentication should simplify user’s interaction by minimizing or eliminating completely the actions required to add the additional factor or factors for authentication. We have reviewed several existing multi-factor authentication systems and critically evaluated them from security and user experience points of view. As an outcome of this review, we created a comparative summary of different methods that clearly shows pros and cons of each system, bringing us to a conclusion that while classic methods are still secure and usable, modern methods are providing same or better security, while significantly improving the user experience. As an outcome of our research activities, we have made the following contributions to advance the state of the art: • Using Augmented Human Path as a context factor • Proposing the TOTP-QR solution allowing to avoid manually typing the one-time password thus improving user experience and avoiding entry errors and using this for presence verification systems • WiFiOTP as a method of improving user experience when entering the OTP as the second factor • Addressing time-drift issues of hardware tokens by introducing programmable hardware tokens with time sync feature • TOTPRadius as an effort to minimize administrative efforts of user enrollment

• We can also recommend the following best practices for MFA adoption below.

6.1.1.1 Apply the MFA wherever possible To eliminate classic authentication (i.e. username and password only), it is important to introduce MFA in all systems possible and do it insistently. One of the major risks in implementing MFA is isolation. System architects need to weigh all attack vectors, such as both cloud and on-premise applications and systems, servers and workstations and other resources.

Our research demonstrated that MFA is not necessarily something complex or expensive to implement. Most major online identity providers are already support MFA in one way or another; for in-house developed systems MFA can be implemented within a few simple steps and no additional cost: an example of our Paper MFA concept described in 3.2.3.2.1 clearly demonstrates that simple and cheap solutions, even while being not entirely attack-proof, can significantly strengthen any system, especially when compared to classic, single-factor authentication mechanisms.

6.1.1.2 Use context as an additional factor Verify user by practising an adaptive methodology based on contexts such as physical location, current network, device type and settings and time of day. A

94 Context-Aware Multi-factor Authentication for the Augmented Human

user can authenticate with standard credentials, but unusual context or behaviour – such as logging in from an unknown location or device or logging in at an unusual time of day — should trigger a request to authenticate using MFA. This strategy, sometimes called "conditional access strategy", significantly improves user experience, as well. Instead of being constantly asked for MFA, the user provides it only when truly necessary.

6.1.1.3 Best practice approaches in the areas of user experience and user behavior User experience is important for prosperous MFA use, and it is very important to consider convenience and security. Instead of a single method implementation for MFA, system architects shall analyze an extensive range of authentication methods currently available on the market, such as classic hardware tokens, soft tokens and programmable hardware tokens, SMS message, phone call, modern context and biometrics. It is important, however, to handle some of the methods with care: i.e. SMS, while being the most user-friendly one, is the less secure at the same time.

The ideal MFA behavior, from the user perspective is, of course, is as close to the zero-user interaction as possible, where the MFA procedural part is invisible to users. However, as modern existing solutions being close to zero user interaction, still require user action this may also have some negative impact as the in the example explained below. 95

Figure 72. Push notification-based MFA login approval

We take an example of the popular Office 365 cloud service provided by Microsoft. When enabling MFA using the mobile authenticator app [107] provided by Microsoft, there are 2 methods the app can be configured to operate:

• Method 1- Push notification method - where users must respond on their phone, as illustrated in Figure 72 • Method 2 - Where users must manually enter 6-digit pin when requested (this also acts as a fallback mechanism where Method 1 fails due to data connectivity issues or when hardware token is used in parallel)

While Method 1 is the most user-friendly (the user action is to touch a button on the phone) there is a significantly high risk that some users have a tendency to "approve" all requests coming from Microsoft app, even if it was not initiated by them; and this could potentially lead users with MFA activated to become victims of phishing attacks just like this. With the Method 2 user consent is much more evident - one cannot accidentally look up and enter a 6-digit number just "by mistake".

By the user experience we mean not only the experience of the end users but also support staff and technical teams, such as helpdesk and systems administrators. This aspect plays a significant role in MFA systems deployment and daily operations: the systems should be easy to deploy and maintain. From this point

96 Context-Aware Multi-factor Authentication for the Augmented Human

of view, the MFA system’s user experience evaluation should also include an assessment of the enrollment procedures as well as regular support operations such as deactivating the second factor, providing temporary bypass methods, replacing a stolen or damaged authenticator device or app, restoring access to a profile etc.

As an example of administrative effort needed to enroll a software token for a user, in Table 7 we provide the comparative summary of Microsoft Azure MFA for Office 365 (reviewed in 3.3.1.2 ) and TOTPRadius for Citrix Store Front (reviewed in 4.7).

Table 7. MFA Enrollment procedure comparison Steps Performed by Microsoft Azure TOTPRadius for MFA for Office Citrix Store Front 365

Enable MFA Administrators √ × activation for a user

Enroll TOTP Users √ √ mobile authenticator

Total (Administrators) 1 0

Total (Users) 1 1

As shown in the comparison, in case of TOTPRadius, there is absolutely no action required by administrators to enable MFA for a user, whereas with Azure MFA, this needs to be enabled per every user. Having the enrollment procedures as simple as possible creates an additional stimulus to move towards MFA driven by the administrators of authentication systems, whereas having the necessity to involve administrators in the provisioning procedures can significantly slow down the process.

So, based on the above, we conclude that the possibility (and simplicity) of user self-service and self-enrollment in MFA is also an important advantage of such systems. 97

6.1.1.4 Best practices in the area of addressing MFA targeted risks While MFA efficiently addresses a big number of security risks, such as phishing attacks as well as most of the attacks resulting in password theft there are still risk factors not addressed by MFA. Examples of such attacks include, but are limited to, attacks exploiting vulnerabilities at the client operating system level, for example a “man-in-the- browser” type of vulnerabilities, keyloggers with screen-recording enhancements, compromised trusted root certificates and similar. Although such exploits are quite rare, combined with techniques similar to “real-time” phishing, they make MFA just an additional inconvenience for attackers and does not allow MFA to stop the attack at all. Other risks that could potentially lead to security incidents including account compromisation or having similar symptoms are originating from operating systems and hardware vulnerabilities. Recent examples of such vulnerabilities are processor related Meltdown (Reading Kernel Memory from User Space [108] ), and Spectre Attacks (Exploiting Speculative Execution [109]) or storage related SSD Self-encrypting deception (weaknesses in the encryption of solid state drives [110]) These risks are beyond the scope of this particular research, but worth mentioning to support the idea of MFA being only a part of the complex security strategies. User awareness also plays a significant role in this process. As mentioned in this section, there are cases of users blindly clicking on login approval notifications and the reason for this is exactly the lack of awareness. Furthermore, some of the attacks, especially phishing attacks based on fake captive portals described in 2.5.2.3.1 are based on and gaining success primarily because of user ignorance: the users simply accept the certificate warnings and continue with the login process. In such conditions, the phishing attack can be successful even with MFA enabled. A theoretical exploit published by Wandera [111] is demonstrated on the Figure 73. The left side of the diagram shows the experience from the victims’

98 Context-Aware Multi-factor Authentication for the Augmented Human

point of view. The actions shown on the right side are illustrating the attack steps performed by the attacker.

Figure 73. Phishing landing page used to bypass 2FA

6.1.2 Best practice recommendation : “Passwordless” as an alternative to MFA After describing the risk of 2FA compromisation using the 2FA bypass methods, it would be fair to also mention the initiative of the so called “Passwordless” access method that a number of vendors (Microsoft being the largest one) are now 99

promoting in their offerings, primarily with centralized identity management systems like Azure Active Directory. Microsoft positions [112] the solution as a method of reducing the risk exposure with password alternatives and the principle is based on using the FIDO2 hardware keys which has two factors implemented on the device itself ; the fact of processing a device is considered the first factor, and the factor activating the key, such as a PIN code or a fingerprint is the second factor. The secure authentication flow architecture is shown on the Figure 74.

Figure 74. "Passwordless" authentication flow presented in Microsoft whitepaper

Using the techniques similar to the ones adopted by the FIDO alliance [113], such as U2F and WebAuthN, primarily based on public cryptography significantly increases the security of an authentication system and is, in theory, in a position to protect from phishing attacks better than classic OTP based schemes. However, the way this is implemented and coded plays a significant role, and therefore we picked the Microsoft Azure Passwordless implementation as an example.

100 Context-Aware Multi-factor Authentication for the Augmented Human

Although actively marketed as a technology fully removing the passwords, in reality the passwords are still there. In the implementation guide [114] the following aspects are shown as the advantages of the Passwordless concept:

1. Increased security. Reduce the risk of phishing and password spray attacks by removing passwords as an attack surface. 2. Better user experience. Give users a convenient way to access data from anywhere, and provide easy access to Outlook, OneDrive, office, and more while mobile. 3. Robust insights. Gain insights into users’ passwordless activity with robust logging and auditing.

The main outcome of our security analysis is: while the technology itself is secure and phishing-proof, the way it is implemented is important and if poorly implemented, defeats the whole purpose leaving the security level the same. Needless to remind that that security is a chain; and just as a chain is only as strong as the weakest link, a software security system is only as secure as its weakest component.

6.2 Future work We have conducted an extensive survey and covered the multi-factor authentication solutions currently present on the marked as well as in academic research. The study critically evaluated these solutions as well as new proposed methods, providing both security assessment as well as user experience aspects of the solutions reviewed in the thesis. We have proposed a few novel multi-factor authentication methods for the augmented human that compare favorably with the authentication methods used today. One of the methods, WifiOTP, requires minimal or no user input and provides the strong security of the HOTP/TOTP algorithm. Our validations demonstrated this solution as being secure and user- friendly. However, there is still a lot to improve around provisioning of WifiOTP tokens as current PoC models are done by directly transferring the secret hash to the OTP generation script. The portability of such devices is also to be improved as by improving the battery life as well as miniaturizing the form-factor of WifiOTP tokens even further. We have also recommended mobile operating system improvements, particularly with Apple iOS that would allow seamless integration of the WifiOTP in native applications by allowing WLAN scanning at the OS API level similar to the API currently presented by Android SDK. Along with these APIs, the functionality could ideally be embedded to operating systems as well leveraging the user interaction to be at the minimal level possible.

Along with new MFA solutions, there is room for improvement for classic methods of multifactor authentication, such as OATH hardware tokens in key fob format. 101

We believe that card format tokens such as miniOTP-1 or miniOTP-2, while having the benefits of being programmable, are still not ideal for those users preferring to have the tokens attached to a keyring or similar reasons. Therefore, availability of programmable tokens in classic fob form-factory would be, in our opinion, highly demanded. Additionally, solutions currently existing as concept are less useful to mass users’ production utilization due to lack of presence on the market and higher costs if the devices are manufactured in a non-mass production way. So, having the devices like OTP-USB stick or even WiFiOTP in its current format produced as a mass product would make their utilization more beneficial in both commercial and security aspects

As humans become more and more augmented, we envision that in the near future new types of authentication will be possible, e.g, based on DNA, brain signal recognition. However, these factors are to be used with care as the main principle of the multi-factor authentication is not just having many contexts as the authentication factors, but the context factors of different type. So, assuming the first factor remains the same, a classic username and password-based credential, which is considered a static context, the second (and so on) factor should be dynamic. Introducing the second factor without making it dynamic, may decrease the security level instead of increasing it. So, as an example, if researches are conducted towards using fingerprint as the second-factor context, the authentication implementation should not be using just the fingerprint checksum itself, but rather a dynamic algorithm which uses fingerprint checksum as one of the arguments. The same applies to other similar biometric context factors, such as face, iris and voice recognition, heartbeat pattern etc.

Another method of further securing biometric factors is enhancing them with device possession context, similar to FIDO2 keys with biometric protection. In this scenario, the biometric context never faces the final authentication system and only serves the purpose of unlocking the device itself – thus only the interface between the device and the owner. In this case in the event of the biometric compromisation, device possession is still required for a successful attack, which makes the probability of such attacks low.

102 Context-Aware Multi-factor Authentication for the Augmented Human

Chapter 7. References

[1] Moon, M., "Mandatory keys cut successful phishing attacks on Google to zero," 24 07 2018. [Online]. Available: https://www.engadget.com/2018/07/24/security- keys-google-phishing/. [2] Saito H., Seigneur J.-M., Moreau G. and Mistry P., , "Proceedings of the 1st Augmented Human International Conference," ACM, 2010. [3] Chatzopoulos D., Bermejo C., Huang Z., and Hui P., Mobile Augmented Reality Survey: From Where We Are to Where We Go, IEEE Access, vol. 5, pp., 2017. [4] Rauschnabel P. A., Brem A., and Ro Y., Augmented reality smart glasses: definition, conceptual insights, and managerial importance, Unpubl. Work. Pap., 2015. [5] Stoppa M. and Chiolerio A., Wearable electronics and smart textiles: a critical review, Sensors, vol. 14, no. 7, pp. 11957–11992, 2014. [6] Hassanien A. E. and Azar A. A., Brain-Computer Interfaces, Switz. Springer, , 2015. [7] Obrist M. et al., Touch, taste, & smell user interfaces: The future of multisensory HCI,, Proceedings of the 2016 CHI Conference Extended Abstracts on Human Factors in Computing Systems, 2016, pp. 3285–3292, 2016. [8] Liu W., Yin B., and Yan B., A survey on the exoskeleton rehabilitation robot for the lower limbs, 2nd International Conference on Control, Automation and Robotics (ICCAR), 2016, pp. 90–94., 2016. [9] Seigneur, J.-M., Ahram, T., Taiar, R., A survey on trust in augmented human technologies, Proceedings of the 1st International Conference on Human Systems Engineering and Design: Future Trends and Applications (IHSED). Reims. [s.l.] : [s.n.], 2018, 2018. [10] Washington Post, "OPM says 5.6 million fingerprints stolen in cyberattack, five times as many as previously thought," 23 09 2015. [Online]. Available: https://www.washingtonpost.com/news/the-switch/wp/2015/09/23/opm-now- says-more-than-five-million-fingerprints-compromised-in-breaches/. [Accessed 29 08 2019]. [11] Google, "Gmail Signup," Gmail, 20 08 2018. [Online]. Available: https://mail.google.com/mail/signup. [Accessed 20 08 2018]. [12] ProtonMail, "Creating a ProtonMail Address," 20 08 2018. [Online]. Available: https://protonmail.com/support/knowledge-base/create-a-protonmail-address/. [Accessed 20 08 2018]. [13] Geenens, P., "IoT Hackers Trick Brazilian Bank Customers into Providing Sensitive Information," 10 08 2018. [Online]. Available: https://blog.radware.com/security/2018/08/iot-hackers-trick-brazilian-bank- customers/. [Accessed 20 08 2018]. 103

[14] Fielding, R. & Reschke J., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June: , 2014. [15] Mitchell C. J., Pashalidis A., "A Taxonomy of Single Sign-On Systems," in ACISP'03 Proceedings of the 8th Australasian conference on Information security and privacy, Wollongong, Australia, 2003. [16] Microsoft, "Office 365 for business FAQ," [Online]. Available: https://products.office.com/en/business/microsoft-office-365-frequently-asked- questions. [Accessed 27 08 2018]. [17] Mockapetris, P., RFC1034, RFC1035 Domain names: Concepts and facilities, https://www.rfc-editor.org/info/rfc88, 1983. [18] Raden, R., RFC 1123 "Requirements for Internet Hosts - Application and Support", https://www.rfc-editor.org/info/rfc1123, 1989. [19] Zheng, X., ""Phishing with Unicode Domains"," 14 07 2017. [Online]. Available: https://www.xudongz.com/blog/2017/idn-phishing/.. [Accessed 28 08 2018]. [20] Burton, J., "FIRST PART OF PHISHING WITH EV," 20 07 2017. [Online]. Available: https://www.sirburton.com/ev-phishing/. [Accessed 28 08 2018]. [21] Carroll, I., "Extended Validation Is Broken," 4 11 2018. [Online]. Available: https://stripe.ian.sh. [Accessed 28 08 2018]. [22] Roche, X., Httrack website copier-offline browser, [Computer Software], 2015. [23] McCann, B., "Template Gallery : Phishing Frenzy," Phishing Frenzy, [Online]. Available: https://www.phishingfrenzy.com/templates/index. [Accessed 30 10 2018]. [24] Gophish, "Gophish- Open-Source Phishing Framework," gophish, [Online]. Available: https://getgophish.com/. [25] Hong, J.-J. Kim and S.-P., "A Method of Risk Assessment for Multi-Factor Authentication," Journal of Information Processing Systems, vol. 7, no. 1, pp. 187- 198, 2011. [26] Dahamija R. e.a., "Why Phishing Works," UC Berkeley, 2006. [Online]. Available: https://escholarship.org/uc/item/9dd9v9vd. [Accessed 28 08 2018]. [27] Lamport, L., "Password Authentication with insecure communication," Communications of the ACM, vol. 24, no. 11, pp. 770-772, 1981. [28] Bellare, M., Canetti, R., & Krawczyk, H., "Message authentication using hash functions: The HMAC construction," RSA Laboratories’ CryptoBytes, vol. 2, no. 1, pp. 12-15, 1996. [29] M'Raihi et al., Totp: Time-based one-time password algorithm, (No. RFC 6238), 2011. [30] M'Raihi D. , Salah M., Mingliang P., and Johan R., Totp: Time-based one- time password algorithm, RFC 6238, 2011.

104 Context-Aware Multi-factor Authentication for the Augmented Human

[31] Schwartz, M. J., "RSA SecurID Breach Cost $66 Million," Information Week, 07 2011. [Online]. Available: http://www. informationweek. com/news/security/attacks/231002833. [Accessed 25 08 2018]. [32] Yubico, "The YubiKey Series," [Online]. Available: https://www.yubico.com/products/yubikey-hardware/. [Accessed 25 08 2018]. [33] Ok, K., Coskun, V., Aydin, M. N., & Ozdenizci, B., "Current benefits and future directions of NFC services," in 2010 International Conference on Education and Management Technology (ICEMT), Cairo, 2010. [34] Straub, M., "Mobile-OTP , strong, two-factor authentication with mobile phones," 15 12 2003. [Online]. Available: http://motp.sourceforge.net. [Accessed 25 08 2018]. [35] Straub, M., "Practical relevance of MD5 vulnerabilities for the security of Mobile-OTP," [Online]. Available: http://motp.sourceforge.net/md5.html. [Accessed 26 08 2018]. [36] alternativeTo, "Alternatives to Google Authenticator for all platforms with any license," [Online]. Available: https://alternativeto.net/software/google- authenticator/. [Accessed 25 08 2018]. [37] Dulaunoy, A., "Paper Token: Gutenberg’s version of One Time Passwords," 29 09 2010. [Online]. Available: http://www.quuxlabs.com/blog/2010/09/paper- token-gutenbergs-version-of-one-time-passwords/. [Accessed 26 08 2018]. [38] LaMutuelle, "Procedure to follow to use the secured access of the website," 12 09 2014. [Online]. Available: https://www.lamutuelle.org/amfiweb/free/documents/Information_acces_securise _anglais.pdf?docKey=512236784. [Accessed 20 08 2018]. [39] AzeriCard, "AzeriCard Internet Banking : User Manual," 2014. [Online]. Available: https://www.hbservice.com/instructions/Instruction1-engl.htm. [Accessed 22 08 2018]. [40] PHP.Net, "Serialize : Variable handling Functions," [Online]. Available: http://php.net/manual/en/function.serialize.php. [Accessed 30 10 2018]. [41] PHP.Net, "uniqid : Misc. functions," [Online]. Available: http://php.net/manual/en/function.uniqid.php. [Accessed 31 10 2018]. [42] Protectimus, "Protectimus Slim Mini," [Online]. Available: https://www.protectimus.com/slim-mini/. [Accessed 27 08 2018]. [43] Token2.com, "Token2 | Programmable tokens," [Online]. Available: https://www.token2.com/shop/category/programmable-tokens. [Accessed 28 08 2018]. [44] Microsoft, "OATH hardware tokens (public preview)," [Online]. Available: https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept- authentication-methods#oath-hardware-tokens-public-preview. [Accessed 29 10 2018]. [45] Engelhardtsen F. B., "leostick_otp - DIY Google Authenticator OTP USB token," 2013. [Online]. Available: https://github.com/fritjof/leostick_otp. [Accessed 6 11 2018]. 105

[46] Durresi, A., Paruchuri, V., Durresi, M., & Barolli, L., "Secure spatial authentication using cell phones," in The Second International Conference on Availability, Reliability and Security, IEEE, 2007. [47] Sykes, E. R., Pentland, S., & Nardi, "Context-aware mobile apps using iBeacons: towards smarter interactions," in Proceedings of the 25th Annual International Conference on Computer Science and Software Engineering, Markham, 2015. [48] Omar, L., & Ivrissimtzis, I., Evaluating the resilience of face recognition systems against malicious attacks, BMVA Press, 2015. [49] Wells Fargo, "Biometric Authentication," [Online]. Available: https://www.wellsfargo.com/online-banking/biometric/. [Accessed 25 08 2018]. [50] Gomez, C., Oller, J., & Paradells, J, "Overview and evaluation of bluetooth low energy: An emerging low-power wireless technology," Sensors, vol. 12, no. 9, pp. 11734-11753, 2012. [51] Lardinois, F., "Authy Makes Using Two-Factor Authentication Easier By Connecting Your Phone And Mac Over Bluetooth," techcrunch, 31 07 2013. [Online]. Available: https://techcrunch.com/2013/07/31/authy-makes-using-two- factor-authentication-easier-by-connecting-your-phone-and-mac-over-bluetooth/. [Accessed 30 08 2018]. [52] van Rijswijk-Deij, R., "Simple location-based one-time passwords," Utrecht: Technical Paper, Utrecht, 2010. [53] Google, "Google Beacon Platform," Google, [Online]. Available: https://developers.google.com/beacons/overview. [Accessed 30 08 2018]. [54] SAASPASS, "Two-Factor Authentication and Bluetooth (BLE)," [Online]. Available: https://saaspass.com/about/bluetooth-ble-two-factor-authentication/. [Accessed 03 09 2018]. [55] Huseynov, E. and Seigneur, J.M, "Beacon authpath: Augmented human path authentication," in Application of Information and Communication Technologies (AICT), 2016 IEEE 10th International Conference, Baku, 2016. [56] Seigneur J.-M., ""Wi-Trust : Computational Trust and Reputation Management for Stronger Hotspot 2.0 Security"," Journal of ICT Standardization, vol. 4, no. 3, 2017. [57] Namiot D., "Network proximity on practice: context-aware applications and Wi-Fi proximity," International Journal of Open Information Technologies, vol. 1, no. 3, 2013. [58] Huseynov, E., & Seigneur, J.M., "WiFiOTP: Pervasive two-factor authentication using Wi-Fi SSID broadcasts," in ITU / IEEE Kaleidoscope 2015 International Conference, Barcelona, 2015. [59] Karapanos, N., Marforio, C., Soriente, C., & Capkun, S., "Sound-Proof: Usable Two-Factor Authentication Based on Ambient Sound," in USENIX Security Symposium, Washington D.C., 2015. [60] G., Kumparak, "SlickLogin Aims To Kill The Password By Singing A Silent Song To Your Smartphone," TechCrunch, 09 09 2013. [Online]. Available:

106 Context-Aware Multi-factor Authentication for the Augmented Human

https://techcrunch.com/2013/09/09/slicklogin-wants-to-kill-the-password-by- singing-a-silent-song-to-your-smartphone/. [Accessed 03 09 2018]. [61] Meier, J., Zhang, J., Zou, R., & Mickens, J, "Zero-effort Two-factor Authentication using Audio Signals," in International Symposium on Cyber Security Cryptography and Machine Learning (CSCML 2017), Beer Sheva, 2017. [62] Stajano, F., Security for ubiquitous computing, Cambridge: J. Wiley & Sons, 2002. [63] Estimote Inc., "How does Secure UUID work?," Estimote, [Online]. Available: https://community.estimote.com/hc/en-us/articles/201371053-How-does-Secure- UUID-work-. [Accessed 03 09 2018]. [64] Chen, R., & Guinness, R., Geospatial computing in mobile devices, Artech House, 2014. [65] Souppouris, A., "Bluesmart wants to crowdfund the 'world's first' connected luggage," Engadget, 20 10 2014. [Online]. Available: https://www.engadget.com/2014/10/20/bluesmart-connected-luggage-indiegogo- campaign/. [Accessed 03 09 2018]. [66] iBeacon.com, "WHAT IS IBEACON? A GUIDE TO BEACONS," [Online]. Available: http://www.ibeacon.com/what-is-ibeacon-a-guide-to-beacons/. [Accessed 03 09 2018]. [67] Bosnic, S., Papp, I., & Novak, S., "The development of hybrid mobile applications with Apache Cordova," in 24th Telecommunications Forum (TELFOR), 2016, Belgrade, 2016. [68] Moell, J. D., & Curlee, T. N., Transmitter Hunting: Radio Direction Finding Simplified, Palo Alto: Tab Books, 1987. [69] Raquet, J. F., Miller, M. M., & Nguyen, T. Q., "Issues and approaches for navigation using signals of opportunity," in Proceedings of the 2007 National Technical Meeting of The Institute of Navigation, San Diego, 2007. [70] Merlin, "LOCATION-BASED PLACEMENT," Merlin, [Online]. Available: http://merlintek.com/#location. [Accessed 03 09 2018]. [71] Huseynov E., Seigneur J.-M., "Physical presence verification using TOTP and QR codes," in 34th International Conference on ICT Systems Security and Privacy Protection - IFIP SEC 2019, Lisbon, 2019. [72] Aloul, F., Zahidi, S., & El-Hajj, W., "Two factor authentication using mobile phones," in IEEE/ACS International Conference on Computer Systems and Applications, Tunis, 2009. [73] Fainelli, F., "The OpenWrt embedded development framework," in Proceedings of the Free and Open Source Software Developers European Meeting, Brussels, 2008. [74] Corner, M. D., & Noble, B. D., "Zero-interaction authentication," in Proceedings of the 8th annual international conference on Mobile computing and networking, Atlanta, 2002. [75] Christophersen, T., Zero Interaction Multi-factor Authentication (Master's thesis, Technical University of Denmark), Lyngby: DTU, 2010. 107

[76] K. P. &. B. B. J. Mahaffey, "Mahaffey, Kevin Patrick, and Brian James Buck. "System and method for changing security behavior of a device based on proximity to another device". US Patent 9,432,361, 30 08 2016. [77] A. Varshavsky, A. Scannell, A. LaMarca and E. de Lara, "Amigo: Proximity- Based Authentication of Mobile," in UbiComp 2007: Ubiquitous Computing, Innsbruck, 2007. [78] Zhao, J. X., "Research and design on an improved TOTP authentication," Applied Mechanics and Materials, vol. 411, pp. 595-599, 2013. [79] OpenWRT Community, "Nexx WT3020," OpenWRT, [Online]. Available: https://openwrt.org/toh/nexx/wt3020. [Accessed 03 09 2018]. [80] Flesner A., AutoIt V3: Your Quick Guide, O'Reilly, 2007. [81] Halsey, M., & Ballew, J., "Managing Network Connections," in Windows Networking Troubleshooting, Berkeley, APress, 2017, pp. 15-40. [82] Ghatol, R., & Patel, Y., Beginning PhoneGap: mobile web framework for JavaScript and HTML5, APress, 2012. [83] Google, "Android Developers Documentation Create an Input Method," Android Developers Documentation, [Online]. Available: https://developer.android.com/guide/topics/text/creating-input-method. [Accessed 03 09 2018]. [84] R., Valmikam, "EAP Attributes for Wi-Fi - EPC," [Online]. Available: https://tools.ietf.org/html/draft-ietf-netext-Wifi-epc-eap-attributes-16. [Accessed 03 09 2018]. [85] IEEE, "IEEE Standard for Local and metropolitan area networks -- Media Access Control (MAC) Service Definition," [Online]. Available: https://ieeexplore.ieee.org/document/7875381/. [Accessed 03 09 2018]. [86] Kaur, N., & Devgan, M., "A Comparative Analysis of Various Multistep Login Authentication Mechanisms," International Journal of Computer Applications, vol. 127, no. 9, pp. 20-26, 2015. [87] Raddum, H., Nestås, L. H., & Hole, K. J., "Security analysis of mobile phones used as OTP generators," in IFIP International Workshop on Information Security Theory and Practices, Berlin, 2010. [88] Mousa, A., & Hamad, A., "Evaluation of the RC4 algorithm for data encryption," IJCSA, vol. 3, no. 2, pp. 44-56, 2006. [89] Apple Inc., "iOS Wi-Fi Management APIs," Technical Q&A, 14 04 2017. [Online]. Available: https://developer.apple.com/library/archive/qa/qa1942/_index.html. [Accessed 04 09 2018]. [90] Gupta, V., & Rohil, M. K., "Information embedding in IEEE 802.11 beacon frame," in National Conference on Communication Technologies & its impact on Next Generation Computing CTNGC, 2012. [91] Wired, "RESEARCHERS UNCOVER RSA PHISHING ATTACK, HIDING IN PLAIN SIGHT," Wired.com, 08 2011. [Online]. Available: https://www.wired.com/2011/08/how-rsa-got-hacked/. [Accessed 12 12 2018].

108 Context-Aware Multi-factor Authentication for the Augmented Human

[92] Token2, "Token2 TOTP Toolset - local," Token2, [Online]. Available: https://github.com/token2/totp-toolset-local. [Accessed 12 12 2018]. [93] Duo, "How do I resync a hardware token in the Duo Admin Panel?," [Online]. Available: https://help.duo.com/s/article/1361?language=en_US. [Accessed 11 12 2018]. [94] Rigney, C., Willens, S., Rubens, A., & Simpson, W., "Remote authentication dial in user service (RADIUS)," RFC 2865, 2000. [95] Masse M., REST API Design Rulebook: Designing Consistent RESTful Web Service Interfaces, O'Reilly Media, 2011. [96] Howes, T. A., Smith, M. C., & Good, G. S., Understanding and deploying LDAP directory services, Addison-Wesley Longman Publishing Co., Inc, 2003. [97] Desmond, B., Richards, J., Allen, R., & Lowe-Norris, A. G., Active Directory: Designing, Deploying, and Running Active Directory, O'Reilly Media, Inc, 2008. [98] Google, "Google Authenticator," [Online]. Available: https://support.google.com/accounts/answer/1066447. [Accessed 10 09 2018]. [99] Huseynov, E., & Seigneur, J. M., "Enhancing RADIUS based multifactor- factor authentication systems with RESTful API for self-service enrolment.," in AICT 2017, Moscow, 2017. [100] Haas, H., Yin, L., Wang, Y., & Chen, C., "What is lifi?," Journal of Lightwave Technology, vol. 34, no. 6, pp. 1533-1544, 2016. [101] Hsiaoming Yang, [Online]. Available: https://github.com/lepture/otpauth. [Accessed 11 11 2018]. [102] Token2, "Token2 TC201 hardware token," [Online]. Available: https://www.token2.com/shop/product/token2-tc201-hardware-token. [103] Corner, M. D., & Noble, B. D., "Zero-interaction authentication," in Proceedings of the 8th annual international conference on Mobile computing and networking, ACM, 2002. [104] Verizon, "Data breach investigations report," Verizon, 2016. [Online]. Available: http://www.verizonenterprise.com/resources/reports/rp_DBIR_2016_Report_en_ xg. pdf. [Accessed 27 09 2018]. [105] Mulder, J., Mimikatz Overview, Definses and Detection, SANS Institute InfoSec Reading Room, 2016. [106] Jungles, P., Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft Techniques, Poslední aktualizace, 2012. [107] Microsoft, "Use Microsoft Authenticator with Office 365," [Online]. Available: https://support.office.com/en-us/article/use-microsoft-authenticator-with-office- 365-1412611f-ad8d-43ab-807c-7965e5155411#ID0EAADAAA=Step_5. [Accessed 8+ 11 2018]. [108] Lipp, Moritz, et al., "Meltdown: Reading Kernel Memory from User Space," in USENIX Security Symposium , 2018. [109] Kocher, Paul, et al., "Spectre attacks: Exploiting speculative execution," in arXiv preprint arXiv:1801.01203, 2018. 109

[110] Meijer, C., & van Gastel, B., "Self-encrypting deception: weaknesses in the encryption of solid state drives," 2018. [111] Wandera, "How a phishing landing page can be used to bypass 2FA," [Online]. Available: https://www.wandera.com/bypassing-2fa/. [Accessed 11 11 2018]. [112] Microsoft Corporation, "Password-less protection," Microsoft Whitepaper, [Online]. Available: https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RE2KEup. [Accessed 6 11 2019]. [113] FIDO Alliance, "How FIDO Works," FIDO, [Online]. Available: https://fidoalliance.org/how-fido-works/. [Accessed 6 11 2019]. [114] Microsoft Corporation, "Complete a passwordless authentication deployment," [Online]. Available: https://docs.microsoft.com/en-us/azure/active- directory/authentication/howto-authentication-passwordless-deployment. [Accessed 6 11 2019].