Master Thesis

(1)

Master Thesis

Developing a framework for secure authentication of Web and Mobile apps

Knut Erik Hildre

Thesis submitted for the degree of

Master in Informatics: programming and system architecture

60 credits

Department of Informatics

Faculty of mathematics and natural sciences

(2)

(3)

Master Thesis

Developing a framework for secure authentication of Web and Mobile apps

Knut Erik Hildre

(4)

http://www.duo.uio.no/

Printed: Reprosentralen, University of Oslo

(5)

Abstract

In recent years, methods normally used for authentication has become more and more insecure. Especially the use of static passwords is heading towards its downfall.

To help increase the security in authentication, we will create a framework implementing modern authentication solutions using dynamic passwords and public-key cryptography. These methods remove some of the obvious flaws which occur in static password authentication. The two biggest weaknesses that are removed by using these methods are the vulnerabilities of a simple and static password that is never changing, as well as the storing of a shared secret on the server-side. However, depending on what type of client application is being developed, different possibilities regarding software and hardware are supported. Our task is therefore to create a universal authentication framework, which offers different authentication solutions for multiple client applications and devices, depending on what is being used. This includes support for web, native, and desktop applications. In addition to this, we will introduce Risk-Based Authentication, and discuss how it can be used to add additional security to an authentication process.

(6)

List of Figures

3.1 Symmetric cryptography as second factor . . . 13

3.2 U2F building blocks . . . 16

3.3 UAF building blocks . . . 17

3.4 FIDO2 building blocks . . . 18

3.5 Federation flow . . . 22

5.1 Architecture overview . . . 28

5.2 Authenticators overview . . . 30

5.3 Client device overview . . . 30

5.4 Client application overview . . . 32

5.5 Server application overview . . . 33

5.6 Server overview . . . 34

5.7 OTP flow . . . 37

5.8 Registration flow WebAuthn/FIDO2 . . . 39

5.9 Registration flow WebAuthn/FIDO2 . . . 42

6.1 Structure of a createCredentialOptions object . . . 47

6.2 Supported algorithms . . . 49

6.3 Supported algorithms . . . 50

6.4 Structure of verifying a response from user 1 . . . 52

6.5 BaseVerify . . . 53

(11)

6.8 Structure of assertionOptions object . . . 56

6.11 Structure of verifying a response from user . . . 61

6.12 Generation of secret key . . . 62

6.13 Method for sending the mail . . . 62

7.1 Before adding FIDO2 authentication . . . 64

7.2 Asking for an external key to be inserted . . . 65

7.3 A pin is required by the external key . . . 65

7.4 Console CredentialCreateOptions . . . 67

7.5 Console the created Credential Object . . . 68

7.6 Console the created Credential Object . . . 68

7.7 The stored fido2 credentials 1 . . . 69

7.8 The stored fido2 credentials 2 . . . 69

7.9 The assertion option object . . . 70

7.13 The response verified . . . 72

7.14 The authentication options offered to the mobile device . . . 73

7.15 OTP as 2FA . . . 74

7.16 the users with their OTP and IP . . . 75

7.17 The two pages that RBA redirects the user to . . . 75

(12)

Chapter 1

Introduction

1.1 Motivation

In society today, static passwords are still commonly used. Studies show that most people use less than five passwords for all accounts, and 50% of those have not changed their password in the last five years. It also shows that 39% of adults use the same passwords for multiple online accounts.

25% admits to using less secure passwords because they are easier to remember, and 49% of adults write down their password on paper[1]. This makes for an attractive target for attackers.

In 2017 the Verizon Data Breach Report showed that 81% of hacking- related breaches are due to either stolen or weak passwords [2]. One of the main weaknesses of authentication based on static passwords is that the password is a shared secret, meaning it is known to both the user and the server. Unless you use second factor or multi-factor authentication, this means that the hacker has the capability to fully impersonate you with this information. Due to these types of incidents, companies now need to take a second look at how to secure their users.

In recent years, there has been a significant increase in websites losing consumer data to hackers. Account takeover by bad actors has resulted in losses above 5 billion, and leading customer-facing companies like Google have experienced massive security breaches [3]. Therefore two-way authentication has become more and more popular to increase the security in different services that require some kind of authentication. Luckily, we already have several initiatives for more secure and/or convenient authentication, such as U2F, UAF, WebAuthN, and more. However, different types of client applications (desktop vs. mobile, Web application vs. progressive Web application vs. hybrid application vs. native application) offer different hard- and software possibilities (e.g. fingerprint reader, USB token, secure hardware; iOS vs. Android). This makes the development of universal authentication solutions difficult.

(13)

1.2 Contribution

The task of this thesis is a systematic analysis of the current state of art in authentication for different application types. Further, a universal authentication framework that supports multiple different authentication methods shall be developed. The most important authentication features will be the implementation of authentication solutions that do not rely on the use of static passwords. These are solutions that involve dynamic passwords or cryptography as a replacement. This will give the developer a lot of new options for a good and secure authentication process for future developments of applications. It will also give the developer freedom when it comes to which solutions they want to use for the specific application being developed.

We will develop this framework with the intent to make it possible for a developer to use it in any kind of application development. This means that it should be accessible both when creating web and native applications.

Lastly, we will implement some basic tools for risk-based authentication to further improve the security of the authentication. This information can help the authentication process analyze whether there are any irregularities to the login attempt. In cases where there is, it can prompt the application to require another layer of authentication. Where this is the case, the application can ask for authentication with multiple methods instead of only asking for one of them. Hopefully, these implementations will make it easier for a developer to develop a more secure and customized user registration and login process for future applications.

1.3 Research questions

RQ1

Overall, which of the authentication methods are the most secure?

Does adding multiple authentication methods increase security or is it unnecessary?

RQ2

What are challenges when implementing all of the authentication methods into a universal framework?

(14)

1.4 Overview of chapters

Background: In this chapter, we will go through the technologies that are relevant to know about when creating a universal authentication framework. These are technologies that are relevant when it comes to how to replace or strengthen static passwords, what solutions exist, how to make the framework universal, and other relevant technology that is crucial for the implementation.

Requirement: This chapter includes all the requirements that we set for the framework that is to be developed. It is meant to give a clearer picture as to what has to be considered when designing and implementing this framework.

Design: In the design chapter, we will go through what and how such a framework can be created. We will look into the different actors involved in the authentication process to give a better overview. Thereafter we will show how this framework can be created by using the technology we have today. We will look into the different possibilities, and try to make it clearer what has to be considered when implementing this solution.

Implementation: This is the part where we will describe the solution that we decided to create. Here we will go through the most important parts of the implementation, and try to describe how it makes sense with the previous chapters.

Evaluation: The evaluation chapter will include information and demonstration about whether the implementation fulfills the requirements set for the framework. We will go through different test cases and check whether the requirements we have set is fulfilled.

Conclusion: Here we will look at the introduction, especially the research questions, and summarize the result of this thesis. Thereafter we will discuss what future work can be done.

(15)

Chapter 2

Client application technologies

2.1 Different types of client applications

A normal challenge for developers when creating an application is the creation of proper authentication. One of these problems occurs because of the many possible types of client applications that can be created. This is because different authentication solutions exist for different clients. Often a developer, therefore, has to either make a decision on what type he or she wants to develop or develop multiple applications with different authentication solutions.

With newer technology, this might no longer be the case. In recent years more and more solutions to make this scenario easier have been developed.

In this section, we will try to give a good overview of the different solutions that a developer can choose between when developing an application.

Today, client applications can be divided into a desktop, web-based, or mobile application [4, 5]. These applications can also have several types of ways to be developed. For web-based applications, we have the normal browser type web app, that requires the use of a browser, and we have the progressive web app, that additionally can be added on the desktop of a device. This means that it is not required to open up the browser to use this application.

Inmobile applications, we have what is called native applications, which is an application designed for a specific operating system, whether its iOS, Android, Microsoft, etc. The other possibility is ahybrid application, which runs a web application inside of a native app. This makes it possible for web applications to run on mobile devices and have access to some key features that the device offers.

Another type of application is desktop applications and they run on a PC operating system like Windows, Mac, or Linux. In many ways, it is similar

(16)

run.

Web applications are a type of application that is delivered over the internet with the help of a browser interface. It is the most basic of applications and usually uses HTML, CSS, and JavaScript for its front-end development. These types of languages are considered to be rather simple compared to the languages used for other client applications. Another benefit of web applications is that it works on any kind of device that supports web browsers. So as long as the device has access to a browser, it will be able to run a web application. A web application does not require installation and is available on both mobile and desktop platforms as long as it is responsive. Being responsive means that it has been designed to respond and adapt to the device in use. This basically means that the website will look good and have all the functionality it offers no matter the size of the device being used.

2.1.1 Progressive web applications

These are web applications that load like regular web pages but offer a lot of functionality and access, traditionally available only for native applications. A web application must always be responsive to be able to be called a progressive web app. This means that it will have to be able to adapt its layout depending on the device being used. Some other functionalities a progressive web application uses are; adding an icon to the home screen, launch in full-screen and clipboard access, just to mention a few. Some functionality is also available in offline mode because it caches application data. This is mainly for display purposes. There is still a lot of functionality that native applications have that a progressive web application can not access. These things are mainly “telephony features”, like intercepting SMS or calls, sending SMS/MMS, getting the phone number of the user, and making calls without the dialer dialog. In recent times, however, they have gotten access to different ways of authentication that the mobile devices offer. This has made PWA even more attractive when it comes to security within methods of authentication [6].

2.1.2 Native applications

This is a type of application that is written in a programming language specifically for the platform they are being developed for. iOS uses either Swift or Objective-C, Windows use .NET framework and Android uses Java to develop their native applications. Because native applications are made specifically for one type of platform, their options for optimization are higher than other applications. These kinds of applications have access to all device hardware and support all of the user interface and interactions available for the mobile device.

(17)

Because of the fact that these kinds of applications are only developed for one platform means that several have to be developed if you want them to be used by all platforms. This requires more money and more time to develop than other applications[7].

2.1.3 Hybrid applications

A hybrid application is a mobile application that runs a web application inside of a native application, using what is called a native application wrapper. This is an application that can communicate with both the native device platform and the web view. A hybrid application is made using HTML, CSS, and JavaScript just like a web application, but its content is wrapped in native code to give it native-like functions. The wrapping allows us to access device hardware, like it is a native application, and allows us to publish it in application stores. This means that a web application can run on a mobile device and have access to the device features like the camera or GPS.

Once a hybrid application is written, it can run on any platform, such as iOS, Android, Blackberry, Windows 8/10, and more [8].

2.2 Comparing the different application types

2.2.1 Progressive web application vs native application

Below we will describe some of the key differences between a progressive web application and a native application [9–11].

Low friction of distribution/Universal access: A PWA only requires a single code base to be distributed to both desktop and mobile devices, this saves a lot of work and money if you compare it to a solution where you would have to consider a native solution as well.

PWAs also eliminate the need of going to application stores, search for the app, click install, etc. Progressive web applications do this by being easy to find in any kind of search engine, but it might not show among application store search results.

Even though the distribution and the simpleness of using PWAs are easier in many ways, the fact that native applications can only be found in the application store assures quality and security due to the approval process required to be added there. Google Plays standards may not be at the same level as the application Store, but it also has some kind of control.

Low development cost: One of the biggest pros of developing a PWA

(18)

where the budget is a factor.

Simple updates: PWA is not something you download or update, it will always have the newest version out there. Native applications on the other hand require you to update manually if you want the newest version.

This is not necessarily a bad thing, depending on whether or not you want the newest version.

Security: For PWAs, HTTPS secures the connection between the publisher and the user, ensuring that the information is protected and is not tampered with. A native application can be thought of as an island on the device, called “sandboxing”. This is a separate container that does not communicate with other parts of your device and is therefore not capable of infecting other parts of the systems on your device. As mentioned in the paragraph about distribution, both Google Play and application Store are very strict with what kind of applications they allow to be distributed. A native application, therefore, needs to be secure enough for their standards to be able to be distributed.

Push notifications: When it comes to push notifications, a PWA can only send these in the but only in the browser, since they do not have access to the device ID. Native applications on the other hand you send the push notifications to the device rather than the browser. Push notifications can also be sent in relation to the behavior of the user.

Offline: In offline mode, a PWA can show content, but only if the content you want to see has already been downloaded. This is rather similar to how the native applications do it. In a native application, you can download content in the application that you can use later without requiring the internet.

Support for authentication methods: Native application has a lot of built-in sensors and functionality when it comes to authentication. On your phone, there are things like finger swiping, PIN codes, fingerprint scanning, eye tracker, etc. For a long time, this has been things that a Web application did not have native support for. This gave native applications an edge when it came to authentication methods. Web applications have tried to tighten the gap between them, and in recent years, web applications can use most of the authentication features that are possible on mobile devices.

In conclusion: The biggest difference in these two cases is that a PWA will never have the full accessibility to the native features, and will therefore not be able to offer everything that a native application can.

The biggest downside to a native application is that it requires more code because it needs to be developed for multiple platforms. This also means that the cost and length of the development will be higher. PWA on the other side can be built for every platform with a single code base, which is cheaper.

(19)

The PWA can never compete with a native application in terms of speed either because a native application is built with optimization for the specific device. A PWA on the other hand is built with the intent to be usable from any device.

We can, therefore, see that there is no clear winner in this scenario, both native and PWA applications can be useful depending on the situation. A PWA is however getting closer to what a native application can offer in terms of functionality.

2.2.2 Compare hybrid and native applications

Whether you want to make a hybrid or native application relies on what kind of requirements you have for the application. Like we did in the last chapter, we will try to through the more important differences[12–14].

Distribution: A hybrid solution offers what we call a single code base, meaning that the code only needs to be written once for it to work on multiple mobile platforms. For a native application, a developer needs to use specific code languages depending on the OS it is being built for.

This means that if the developer wants to develop native applications for multiple OS’s they would have to write multiple code bases.

Development costs: For developing a hybrid application, one of the major advantages is the fact that it uses a single code base. This also means that the developer requires less time for development, which results in less money spent by customers to purchase these services. If you compare this to a situation where the developer has to write code for multiple native applications, a hybrid solution takes a lot less time to develop. Therefore the amount of money spent on the developer is noticeably lower in the case of a hybrid solution.

Maintenance:In the case of the application needing maintenance work, a hybrid application would always offer an easier solution. This is simply due to the fact that it only requires one code base to be updated. The logic of this argument is also relevant when it comes to building and testing the code because it only needs to do it once.

Performance: The performance of a native application will always be one step ahead of a hybrid application, but we can see that the gap is getting smaller and smaller as time passes. When it comes to security, a hybrid application will be susceptible to vulnerabilities affecting both web browsers and native applications.

Conclusion: If time and money are essential for the customer or developer, making a hybrid application seems to be the better option. On

(20)

2.2.3 Compare progressive web applications and hybrid applica- tions

In many ways when comparing these two technologies there will be a lot of similarities to how we compared PWA with a native solution. This is because a hybrid application is in many ways just like a native application.

We will, therefore, try to compare these solutions in a way that makes the differences as clear as possible [12–14].

Distribution:When it comes to the distribution of the application both of the types have a single code base. The difference when it comes to distribution is how they are being distributed. For a PWA, it uses browser technology to function, meaning it does not depend on the device being used. A hybrid application on the other hand will specifically be developed for different devices, meaning the solution has a different target in a sense.

Other than finding a PWA on the web, it also uses an option called "Add To Homescreen", which lets the user download the PWA to the home screen of the device. For a hybrid application, the distribution is done through the Play store and application store just like a native application.

Development cost: When it comes to developing, a PWA is designed to fit the browser requirements, whereas the hybrid application needs to adjust to the different native structures. A PWA solution is therefore the more attractive solution if the budget of the developers is low. A PWA is a web application that offers the possibility of a mobile and desktop devices adding it to its home screen and has functions available in offline mode. A hybrid application on the other hand is an application that uses technology to translate the written code into being treated as native code. This way a hybrid application can be distributed via a native application store, and must therefore also undergo the application store review process.

One of the biggest differences between these solutions is access to the functions of the mobile device. A progressive web application will not have access to hardware API and functionality, but a hybrid solution will.

Conclusion:In a lot of ways these two solutions offer a lot of the same functionality. They are both developed using the same languages and they work cross-platform. The biggest difference between these two is that a hybrid application is specifically made to be a native solution. As PWA solutions are being more advanced by the minute, hybrid solutions are mainly useful if the intent is to develop an android and iOS application with the same code.

(21)

Chapter 3

Authentication technology

3.1 Different authentication technologies

After looking at the different possibilities for developing client applications, we will now look into the different authentication technologies.

3.1.1 Static Password authentication

When it comes to password authentication several types exist. At a high level, we can divide them into static and dynamic passwords.

Static passwords are passwords that the user combines with a username.

This password will never change and is usually stored on the application server. For a long time, the use of static passwords has been the standard way of authenticating the user. In the past decades, this way of authenticating has shown more and more weaknesses as the technology kept getting more and more advanced[15].

One of the first and most obvious flaws with static passwords was a correlation between the user having to remember it and this often results in the user choosing something familiar to them. For the same reason, the password was usually pretty short. This made it easy for attackers to narrow down and use different attacks to crack the password.

To try and improve this security, websites tried to enforce stricter rules upon the user. This included adding requirements to how many letters must be used, having capital letters, and adding special signs like exclamation marks and question marks. This did increase the security, but it also added additional hurdles for the user. It required the user to create passwords that were harder to remember. Non the less, technology once again caught up with the changes, and static passwords are today

(22)

password, given they have unlimited time.

Static passwords are therefore not considered secure by itself, and in recent years many websites and organizations have required an additional way of authentication to go with it, namely two or multi-factor authentication.[15].

Attacks on static passwords

One of the attacks that caught up with the security of static passwords was brute force and dictionary attacks. Brute force attacks would go through every single combination of letters and eventually crack the password.

Dictionary attacks, which are rather similar to brute force attacks, use predefined brute force dictionaries to crack the password. This type will not go through every combination but will choose from a list of most common password combinations. Even though some of these attacks could take a really long time if the user has indeed created a long and to some degree random password, it would be cracked in the end. The reason for this is that the static password will never change, and this method of hacking would, therefore, find the result in the end.

This weakness led to organizations thinking of replacements or two- factor solutions to cover the weaknesses of static passwords. One of the solutions that got developed was dynamic passwords.

3.1.2 Dynamic Password authentication OTP - third-party service

Dynamic passwords is a solution to fix the problem of static passwords by changing the passwords of the user regularly. Compared to the static passwords that will stay the same after every login, a dynamic password will always change. The change can occur right after the password was used, or within a certain amount of time. A solution like this would of course make it impossible for a user to keep track of the passwords in their head. Solutions to handle this problem is therefore the core of development within dynamic passwords.

A good example of such a solution is an OTP, also known as a One Time Password. OTP usually works by the server-side of the application generating an OTP and sending it to the user.

How this code is generated and how it is verified depends on what technology used behind constructing the OTP solution. No matter what technology is being used, a way to verify the code must be made.

A common way to generate this code is for the server to generate a code and send it to a user’s registered Email or Phone. This code will then be used to gain access to the website by typing it into some kind of login

(23)

form. What is important after the code has been entered, is that the server- side application needs a way to confirm that this code is the one that was generated by the server initially. This can for example be done by storing the code in a session or the server’s database. An important security measure that needs to be considered here, is that this code is only supposed to be used one time. This is due to preventing replay attacks. The server will, therefore, have to implement some functionality to make sure that the same code is only valid one time.

A weakness with this type of OTP solution is the fact that the code is being sent over a network. Even though the OTP can only be used once, an attacker intercepting communication with a MITM attack has the chance of entering the code before the user. Using OTP as authentication, therefore, requires the use of technology to encrypt the message. One way of doing this is through an HTTPS connection between the user and the Relying Party (RP).

OTP - Symmetric

One way of dealing with this problem is the use of symmetric cryptography in an OTP solution. This relies on a user already having a registered account with the RP and is therefore only viable as a second or multi-factor authentication solution.

Symmetric cryptography is based on the same key being used for both encryption and decryption. This means, that if the user and the relying party have the same symmetric key, they will always generate the same key.

This solution also relies on the user and the RP using the same algorithms for generating the secret codes. Algorithms are therefore often predefined by global standards, or the developer of the site will also develop an authenticator application which the user can download and use. This is something we see a lot of the bigger organizations do.

The verification of the code is done by the RP comparing their code to the one sent by the user. If they match, the RP knows that the user is sitting with the same secret key.

The downside of this method is that it faces a lot of security issues if it were to be used as an authentication method on its own. This would mean that the server would have to send the secret key over the internet. This would make it an attractive target for a lot of modern type attacks. If an attacker managed to get a hold of this key, they could impersonate the user completely. In many ways, this key can be directly compared to a static password. If you have it, you have full access to all the functions the user has.

The only way a symmetric cryptography solution could work as authentic-

(24)

the device and the RP by the same people. An example could be that Google created an external device that included a key that can be used to authenticate to a Google server. This is because Google manually inserted this symmetric key into both the server and the external device.

Even though symmetric cryptography is not a good way of authentication on its own, it could be included as a good second-factor authentication method. Let us give a short example.

Figure 3.1: Symmetric cryptography as second factor 1. The user login to a website that they have already registered to.

2. Thereafter the user navigates to an option within the website that is called "enable second or multi-factor authentication". This will then lead the user to a page where the user can click a button to generate a code (in our case this is the black square). After this has been done, the website will generate a secret key that the user can use to generate passwords at a later point.

This way of sharing the secret key will ensure that the key is never being sent over any network. Meaning that codes generated with this key as its secret will avoid all kinds of attacks related to MITM attacks.

3.1.3 Asymmetric cryptography authentication

A possibility as a replacement for a static password is the use of asymmetric cryptography, also known as Public-Key Cryptography (PKC).

This technology uses what is called an asymmetric key pair to register, and then later login a user.

The idea behind this technology is to have a private and public key. These keys are connected by math but are indeed two different keys. Guessing or calculating this private key is also considered to be close mathematically impossible[16, 17]. What this means in theory, is that encryption done by the private key can only be decrypted by the public key and vise versa. This

(25)

type of cryptography is game-breaking when it comes to security and offers many different possibilities, one of them being as a way of authenticating.

When you use PKC between two actors over the internet it is important to know how this key pair can be used. In the case of a user initiating a registration with a RP, the user wants to sit with the private key while sending the public key to the RP. This way, the RP has no idea what the user’s private key is, but it can decrypt messages that have been encrypted by it. Since the users private key never left the user, no one else will have a key that can communicate with the public key. This logic is what makes PKC a very attractive tool in the world of authentication.

The fact that the private key never leaves the user, also makes it close to impossible for an attacker to get a hold of it. This means that even if an attacker can read the communication between the user and the RP, it will not be able to modify it without ruining the message structure. This will let the server know that the message has been tampered with, and throw an error.

3.1.4 Possible attacks on authentication methods

Today there are multiple more advanced attacks than the brute force type that we have to consider when building a secure authentication framework.

The problems no longer only lie within the password, but also in the way of how communication is done and how the password is stored.

Replay attack

A replay attack is an attack where a hacker intercepts communication between the user and a relying party and uses the same credentials to log into the service. This can either be a password or a hash password that the user sends to verify its identity. In an authentication framework, it is therefore important to take this vulnerability into consideration when implementing a solution. We will, therefore, go through the most relevant ways of handling this situation.

One way of doing this is by using a unique identifier for that specific transaction/session. In this case, a hacker trying to replay the copied values stolen will open its own connection with the RP. The RP will then create a new unique identifier for this section, in which the hacker will reply with the identifier they stole from the user. When the RP compares these two identifiers, it will see that they are different and therefore decline the hacker’s login attempt[18].

(26)

Man in the middle attack

A MITM attack is a broad form of an attack that takes many shapes. It includes a user, a hacker, and an RP. Normally when a user communicates with a RP, user sensitive information is being sent. The point of a MITM attack is that the hacker gets a hold of the private information being sent back and forth between the user and the RP.

One of the normal ways to perform this attack is by listening to the communication between the user and RP. This is mostly used when the hacker is sitting on the same network as the user, by listening to all the ongoing traffic between the user and the RP. Tools like Wireshark gives a good example over how such an attack can be like, since its a tool meant to see all the transmitted data within a network[19].

Phishing

Phishing is defined as the act of tricking a user by either disguising malicious sites and/or tricking them into giving up sensitive information.

One example can be that an attacker creates a fake replica of your bank account. The attacker can then trick you into leaving them your username and password. With this information, the attacker can enter your bank and access all your information. A normal way of mitigating this is through multi-factor authentication. In the case where an attacker would obtain the username and the password, a second factor would not necessarily be something an attacker obtained through phishing. This could, for example, be the case if the user used an OTP solution using symmetrical cryptography[20].

3.1.5 Universal Second Factor (U2F)

Universal Second Factor is a standard that combines the normal static way of authenticating with a username and password, with a secondary authentication. This is typically done by using specialized devices that use USB, near-field communication(NFC) or Bluetooth on U2F-enabled sites and applications. These devices have been designed to be as simple, inexpensive, and interoperable as possible.

In recent years, the development of a “key” that offers contactless, tokenless, and passwordless authentication for both PC’s and mobile phones has been further developed. The most known one is called a YubiKey and is a key made by a company called Yubico.

U2F provides two functions, which are key generation and signature verification. It can generate a new key for every site the device is used on.

The U2F standard does not verify that the user is who they say it is, but

(27)

only registers that the presence of a user is registered. It is therefore reliant on username and password to work so that user verification is included in the authentication [21]. As we can see in the figure, the U2F protocol only works between the external authenticator and the device. If communication with a RP is wanted, the developer has to take this into consideration.

Figure 3.2: U2F building blocks

3.1.6 UAF

UAF is a passwordless standard. The service works by the user registering their wanted authentication method to the online services provided by UAF. UAF uses the native capabilities of the device being used. This can be finger swiping, PIN-code, face biometrics, and much more. This service can also combine multiple authentication methods to create multiple layers of authentication. Once the user has registered the mechanisms to be used for authentication, it simply repeats that mechanism every time authentication is required. This way the user will no longer have to insert username and password when authenticating with the registered device.

Different to the U2F standard, UAF uses built-in functionality for user verification while U2F uses a hardware key like the YubiKey to verify the presence of a user[22].

Because it uses functionality built into the device, calls to the authenticator can be made directly from the Relying Party.

(28)

Figure 3.3: UAF building blocks

3.1.7 FIDO2

FIDO2 is an open authentication standard created by the FIDO alliance and Web Consortium to solve the global password problems in the world and addresses all of the issues in traditional authentication. In a way, you can say that FIDO2 is a combination of U2F and UAF. It takes a lot of the same functionality and further enhances them. In this section, we will describe the details of how it works, but first, we will give a short introduction to the two organizations that developed the standard.

The FIDO Alliance was founded with the purpose of finding good authentication solutions as a replacement for passwords. Over the years they have created many different methods of doing so, like the UAF and the U2F protocol that we mentioned earlier. A big problem in replacing the standard password solution on a grand scale has been many, including bad user experiences, expensive solutions, and so on. The Fido alliance goal is to create solutions with open standards that are more secure than the passwords solutions, easier for users to use, and simpler for services to deploy and manage [23].

The Web Consortium was created in 1994 to bring some structure and order into the web. Back when it was created there were few standards as to how things like a browser should be developed. W3C took the job of creating web standards so that websites would look the same in all web browsers. The mission of W3C is to lead the World Wide Web to its full potential by developing standards, protocols, and guidelines that ensure long term growth. Today some examples are HTML, CSS, and of course WebAuthn just to mention a few. The fact that WebAuthn is created by W3C is therefore a clear indicator that the specification is meant to function for all of the browsers in the long run. This makes it an attractive

(29)

authentication solution for developers looking to develop for the long term.

[24].

FIDO2 consists of the World Wide Web Consortium’s (W3C) Web Au- thentication (WebAuthn) specification and FIDO Alliance’s corresponding Client-to-Authenticator Protocol (CTAP). WebAuthn is a browser JS API made to ease the integration of strong authentication for a web service, that supports both passwordless and second-factor authentication. Together with CTAP2, which handles the negotiation with the external authenticator, they form FIDO2.

One of the differences between U2F and FIDO2 is that U2F only worked as a second-factor authentication method. FIDO2 has taken it a step further and included support for the use of external keys as first-factor authentication as well as second. What this means is that FIDO2 has combined the user presence that a U2F key offers, with user verification methods like PIN, fingerprint, etc. In a way, they have taken the best from both U2F and UAF and developed it even further. FIDO2 also includes backward compatibility to both U2F and UAF.

In the FIDO2 specifications, WebAuthn and CTAP control the communication between the relying party, the client/browser, and the authenticator. To get a proper understanding of how FIDO2 works it is important to have some knowledge regarding these standards. In this section, we will go through these standards, as well as the technologies they are used between.

Figure 3.4: FIDO2 building blocks

An important thing to note about FIDO2 is that it can both use a two- part and a three-part trust model. The trust parties involved in a two- way trust model are the User and the RP. In the cases where a three-way trust model is used, a third party for confirming the attestation key pairs on the authenticators is required. Such a service is often referred to as a metadata service. This will sit with the information regarding what types of authenticators exist and identify them with unique codes. This will be discussed further later in the chapter

(30)

WebAuthn

WebAuthn is an authentication API that was officially announced as a W3C standard in march 2019. It is a web-based API that allows websites to add FIDO-based authentication on supported browsers and platforms. A lot of the motivation behind developing WebAuthn was to reduce the reliance on password or authentication methods that are easily phished.

WebAuthn allows for a simpler way to secure user authentication on a web application, by using registered devices such as phones, laptops, external keys, etc as factors. Among the authentication methods possible with WebAuthn, we have biometrics, Bluetooth, NFC, and external keys such as YubiKey. WebAuthn is simply put an interface to talk to different FIDO authenticators. This includes support for both old and newer FIDO authentication solutions such as U2F and UAF.

The API allows servers to use public-key cryptography to register and authenticate users instead of passwords. Among many things, this reduces the chances of phishing attacks. As shown in figure 4.4, the WebAuthn API works between the Relying Party and the browser. WebAuthn defines two new Java Script calls available to web applications, namely navigator.credentials.create() and navigator.credentials.get(). The create method is used to register a new authenticator and in the process store a user credential along with the authenticator on the server. This call can either be made for registering a user or add a new asymmetric key pair as an additional way of authenticating. When an already registered user wants to log into the application, the navigator.credentials.get() call is made, which uses the already registered credentials to perform a verification process with the user trying to log in. If succeeded, the user will be allowed access by the navigator.credentials.get() call. These two calls are the essence of what the WebAuthn API offers [25].

CTAP - Client to Authenticator Protocols

The first version of CTAP is essentially just another name for U2F. In this section, we will be talking about CTAP2 which is an essential part of FIDO2, so when we are talking about CTAP we are referring to the second version.

While WebAuthn is a way for the RP/server to communicate with the client/browser, the CTAP protocol handles communication between the client and a roaming authenticator.

Both of the CTAP versions communicate via Bluetooth, Near Field Communication (NFC), and USB. The difference between the two lies in the fact that CTAP1 was only meant for second-factor authentication, whereas CTAP is meant to enable passwordless, second factor, or multi- factor authentication experience. This means that it does not rely on a user already having registered any user information on the account [26].

The biggest difference from this version to previous versions is its

(31)

use of CBOR for encoding structures. This technology is used in the communication between the browser and the external authenticators and allows for more authenticator options than CTAP1.

CBOR is a binary data format based on JSON, that like JSON allows for the transmission of data objects that contain name-value pairs. The difference to JSON is that it does this in a more concise manner, which increases the processing and transfer speeds at the cost of human readability. This is because the method of communication like Bluetooth and NFC relies on concise and faster transfer speeds for the information[27].

3.2 Singe Sign-On solution

A Single Sign-On solution (SSO) design is where the user is only required to sign in once to get access to multiple related, yet independent software systems. This is done by using something called a three-party trust model.

This model includes a user, a third party for authorizing users, and a website or service that the user wishes to access. A user will in this scenario use a password of sorts to log into a third party that handles the authorization between the user and the website that the user wishes to access. This way, the user will only have to remember the password for the third party that handles the authorization of the user. This model relies on the fact that the website trusts the information received from the third party.

When created, this was meant to remove the problem of users having to re- authenticate every time they wanted to access something new within the trusted environment.

A good way to describe the classic SSO model would be to take Office365 as an example. When a user wants to access Office365 text editor

"Word" in the cloud, they will have to authenticate to Office365 to gain access. If the user also wants to start Office365 "Excel", they will not have to re-enter their password if SSO was used. This is because the Office365 SSO service will re-authenticate the user with the username and password used in the initial login. The SSO solution then spared users of having to re- authenticate every time they wanted to access a service within the Office365 website.

3.3 Federation protocol

The purpose of developing federation protocols was to create protocols using the SSO model as a template but implementing further improvements.

While normal SSO offered access to all the services within a single organ-

(32)

One of the main improvements that were necessary for this change to be viable was adding more security to the model. The federation model was developed with the idea of two or more parties could establish mutual trust, hence allowing one service to attest to another about the identity of the user [28].

Federation added a token-based system for the authorization and authentication of the user. This system made it so that the Identity Provider (IdP) had more power when it came to authenticating over the web. IdP could now store information for several independent RP’s and allowed for the same sense of login as the Office365. Instead of having to log in again every time a unique website is accessed by the user if the website trusts the IdP, the website can allow the user instant access without having to re-authenticate.

A good example of a modern IdP is Google. Website or applications can allow sign in with the use of your Google account. As a user, if you trust the website you want to log into, you can log in with your Google account.

For this, it was implemented several solutions that we will give a better overview of in this section.

3.3.1 OAuth 2.0

OAuth 2.0 is the industry-standard protocol for authorization. It is a protocol that follows the federation model, meaning it was designed to replace the standard SSO model.

OAuth 2.0 uses a token system to solve a lot of the issues by storing and using static passwords. Instead of using passwords received from the third party, the user now receives a token that he or she uses for login. This removes the necessity of the relying party knowing anything about the user logging in. A good example of this would be when you log into a site, the site can allow you to log into the site by using your Google account.

This way the user does not have to send or allow anything directly with the application, instead the application will get this information through Google. This, of course, relies on the application and Google trusting each other.

The thing with OAuth is that it does not have authentication naturally implemented in the solution. OAuth only does authorization of the user, meaning no user information is used with the protocol [29].

3.3.2 OpenID Connect and SAML 2.0

OpenID Connect is the latest federation protocol and is used by a lot of the larger companies, like Amazon, Google, Microsoft, and PayPal. It is an identity layer on top of the OAuth 2.0 protocol that allow clients to verify

(33)

the identity of the end-user based on an authentication process performed by an authorization server.

SAML on the other hand is an XML-based protocol that handles both authorization and authentication without the help of another protocol.

Both protocols allows all types of clients to request and receive information about authenticated sessions and end-users[30].

Both of these protocols offer the same end result, but with different technology. They also have their preferred area of usage. While OIDC uses JWT to authorize and authenticate the user, SAML uses assertions. The end result is practically the same but based on the organization or user one or the other might be a better solution.

Figure 3.5: Federation flow

In figure 4.5, you can see the three actors in a federation protocol.

Within an OAuth solution, the IdP will only include authorization for the user. In an OIDC or SAML 2.0 solution, this IdP will also include authentication of the users.

3.3.3 Conclusion Federation protocol vs FIDO2

If you compare these federation protocols they all with FIDO, they have some similarities. They both try to improve the end-user experience when dealing with multiple relying parties. The difference between these two technologies is how/where they do it. A federation protocol allows the user to sign in once, but still gain access to multiple relying parties. FIDO2 on the other hand has a unique key for every relying party, which requires a new confirmation from the user every time access to a new relying party

(34)

and authorization. The federation protocols do not specify the method of authentication that is being used between the IdP and the user. This means that the IdP accepts static passwords, two factor, and multi-factor authentication methods.

Because of this, we can say that FIDO2 and federation are complementary.

FIDO2 can be used as the way of authentication between a user and an IdP.

This works well with the fact that the federation protocols do not specify how the authentication process with the user should be done [31].

3.4 Entities involved in the authentication protocols

3.4.1 Relying party

The relying party consists of at least a web server and the server-side of the web application. This is the entity that requests the authentication of the user. It can either be done through the use of IdP or it can be done directly with the help of FIDO2. In the case of FIDO2, it stores all the necessary information about the users, including information about the authentication method. An important note here is that the private key is not included in this information.

The RP can also have external services to help verify data such as an Attestation Trust Store. This Trust Store is only necessary if the RP cares about attestation metadata. The relying party only communicates with the client or an IdP, thus leaving the job of communicating with the authenticator to the client.

3.4.2 Identity Provider

The Identity Provider is the entity that is used within federation protocols to store the user information. The user will store their information here safely, and the RP will know that authentication through the IdP is to be trusted. It is therefore considered an important entity for both users and RP.

3.4.3 Client

The client can be considered the bridge between the RP and the authenticators. It implements ways for communication with different authentication methods and establish a connection with the RP. The best examples of clients are hardware devices like PCs and Phones. A PC typically runs a web application that runs within a browser. This web application/browser connection is how the PC communicates with the RP. For a RP to be able to

(35)

receive information from an authenticator, the PC needs to have a way of authenticating. For a PC, the most common option is by inserting an external key into the USB input.

For mobile clients, such as android and iOS, authentication methods are also included in the client directly. This means that mobile devices are usually both a client and an authenticator.

3.4.4 External authenticator

In general, an external authenticator is something that is used to confirm the identity and presence of a user. Because this authenticator is usually a physical device that the user has on or close to them, it is considered a good addition to user security. This is because a lot of malicious attacks involves impersonation. With a device like this, an attacker would have to get a hold of the device in order to connect to the user account, even if he knows other user information.

When we are talking specifically about FIDO2, an external authenticator is usually some kind of dongle that can either be used with USB, NFC, or Bluetooth. A good example is the YubiKey, which offers a one-time password, public-key cryptography, and authentication, as well as being supported by the U2F and FIDO2 protocols developed by the FIDO alliance. It allows users to authenticate themselves by either using an OTP or a public/private key pair. The private key will never leave the security key, only the public key will be sent to the server to be stored. With the YubiKey it is required that an authorization gesture in the form of a tap is done to confirm user presence [32].

Within FIDO2 supported authenticators there is something called an attestation private key. This key is burned into the authenticator device when created, to use for signing credentials including the public key, which is later used in the FIDO2 process. The attestation is specific to the type and model of the device used, meaning a YubiKey 5 and a Samsung Galaxy s10 would both have its own unique key. It is used to prove that the user has the specific model of the device when they register. The purpose of attestation is to secure the integrity of the message that is being sent by the user.

This is the case because an attacker would not be able to change the public key without changing the signature. This is because the public key has been signed by the private key stored on the device. This allows the service to trust that whatever is being sent from that user is indeed secure.

3.4.5 Platform authenticator

Platform authenticators are methods of authentication included within the

(36)

platform authenticator can only be used on the device it is implemented in.

Some requirements are also set to the device if it is to be able to use the platform authenticators. One of these is a Trusted Platform Module (TPM) security chip to handle the public and private keys that are used in the authentication process.

Another requirement is a camera or biometric reader that supports the type of input that is required for the authentication method. An example would be if you want to use fingerprint as a way of authentication, the device would have to have some sort of sensor for this to be possible. This is also the case for other biometric solutions. Note that this is not a requirement for a platform authenticator, but in the case where a fingerprint scan wants to be used, a solution for this must be implemented.

3.5 Risk-based authentication

The purpose of Risk Based Authentication (RBA) is to collect information about every login attempt and analyze that information to figure out how the login attempt should be treated. Normal information to gather includes location, IPs, time, and what kind of device is used just to mention a few. With this information, the risk-based authentication solution will either allow the user to log in, prompt them to submit another form of authentication or deny them access to the service.

A normal way to implement RBA is to create a dynamic profile and create a sort of point system to calculate the level of threat that the login attempt shows. An example would be to have a threat system that goes from 1 to 100, where 100 is the highest possible threat. For this kind of system to work properly some kind of behavior algorithm should be implemented to analyze multiple logins for more accurate data.

To this day, most enterprises are not convinced that this is a solution that they want to implement into their services [33].

(37)

Chapter 4

Requirements

In this chapter, we will discuss the requirements for the universal authentication framework we want to develop. In the two previous chapters, we discussed different technologies that are relevant when it comes to making an authentication framework. Now we want to give an overview of the requirements that we set for the framework that we are going to develop.

The design of the framework developed shall be intuitive, so that it can be used effectively by any user. It shall also offer solutions that do not have obvious or many weaknesses. The solution offered shall be secure and practical so that the users feel comfortable using it.

We are going to divide the requirements into two categories,functional andnon-functional.

4.1 Functional requirements

R1 - Web programming languages support

The framework that is going to be developed need to support common/standard web programming languages to give the developer less re- strictions when it comes to what languages they want to use for their application.

R2 - External key support

The framework shall support the use of external keys as a means of authentication. These are keys that use USB, NFC, or Bluetooth to communicate with the client device. Some keys also offer multiple of these solution within the same key.

R3 - Native authentication support

(38)

offered natively on mobile devices. Examples of this is a fingerprint scanner and PIN-codes.

R4 - Dynamic authentication solution

The framework shall support a dynamic password solution as an authentication method. This is meant to offer an additional authentication possibility for the developer.

R5 - Risk-Based Authentication A basic Risk-based authentication solution shall be made. This is meant to help the application assess the threat of the login attempt.

4.2 Non-functional requirements

R6 - Make framework developer-friendly

It should be easy for a developer to use the functionality implemented in the framework. It is therefore important that the framework includes most of the functionality required to have a proper authentication flow.

R7 - Preventing attacks on authentication methods

Measures towards preventing the attack types we discussed in section 3.1.4 - Possible attacks on authentication methods, shall be implemented. This is to decrease the chance of any malicious attacks on the authentication methods being used.

(39)

Chapter 5

Design

5.1 Overview of all actors

When we want to design a solution for how to develop a universal authentication framework there are multiple things that needs to be considered. First, we are going to give an architectural overview of all the essential actors included in the authentication process.

Figure 5.1: Architecture overview

As we can see, there are multiple actors that needs to communicate with each other. Each actor has their preferences and requirements, as well as requirements for how they communicate. We will go through each one of them and describe what has to be considered when interacting with them.

We will start with the left side of the figure (Authenticators), and work our way towards the right side (Server). This way, we will describe step by step how they interact with each other.

(40)

5.1.1 Authenticators

Authentication can be done by the user with the help of a platform, native, or an external device. These devices can offer everything from a static or dynamic password to PKC solutions. The job of the authenticator is to be able to provide proof that the user is who they say with some kind of secret.

If static passwords are being used, we can refer to the users themselves as the authenticator. Because the authenticators sit with the information to verify a user identity or/and presence, it is important that this information is well secured. In the case of static passwords, the weakness is mainly its simplicity, because it is physically impossible to break into someone’s brain. For solutions like dynamic passwords or PKC, this is not the case.

These solutions use secret keys/dynamic passwords as a replacement to static passwords. Since these secrets are hard to remember for a user, a place to store them is necessary. Therefore an authenticator, or ways of storing authentication information has become increasingly important when it comes to security.

When thinking about external keys such as YubiKey, we need to consider that these devices use their own technology. This demands that whatever type of client device that communicates with them needs to have a language in which they can speak with each other. Luckily, we have two protocols that are meant for dealing with this communication, namely U2F/CTAP1 and CTAP2. This combination makes external keys a strong option for a secure PKC solution. In newer versions of the YubiKey, they also have user verification included in their solution. This is now combined with the registration of user presence, which makes it an excellent option for authentication on its own.

Another option when it comes to PKC is the use of functionality already built into a device. This is referred to as platform authenticators earlier in the thesis. Many of these authentication methods also work in the combination with PKC. These solutions often include some kind of biometric methods, such as fingerprint scanning and facial recognition. As we can see in the figure, built-in authentication methods do not require CTAP1 or CTAP2 to be used by the client. This is because they are natively supported by the client device.

(41)

Figure 5.2: Authenticators overview

In the figure above we have illustrated how the authenticators and their flow works. What comes after this interaction leads us to what the authenticators are connected to, namely the client device.

5.1.2 Client device

Below you can see a figure showing the actors in which the client device communicates.

(42)

The client device is used by the user to access an application. As shown in the figure, it works as a connection between authenticators and the client-side of the application. When designing a universal authentication framework, knowing what possibilities lies within the device is important.

This is because the client device often dictates what kind of authentication solutions are possible to execute from it. If we look into the different client devices that exist, we can see that they support different standards and authentication methods.

If we look at a mobile client like an Android or iOS phone, it can include built-in support biometric solutions such as fingerprint scanning and facial recognition. Windows 10 also has something similar called Windows Hello, which offers authentication with the help of facial recognition, fingerprint scanners, and PIN codes. Having this built into the client’s functionality makes it easy for client applications to make use of them. For Windows 10, external devices are used to achieve some of the supported authentication methods. Examples of this are YubiKeys, USB with a fingerprint scanner, or a web camera for facial recognition.

When it comes to the CTAP2 and CTAP1 protocols we discussed earlier, these are important protocols if authentication with an external device is something that wants to be implemented in the framework. It is therefore important that the client devices support the CTAP protocols. As per today, CTAP is supported by almost all browsers and platforms to some extent.

Browsers can access all of the functionality, while platforms like iOS have more limited options. Non the less, this is currently under development and will most likely change in the future.

We have now talked about how the devices have built-in support or not for different authentication methods. This also includes the CTAP protocols for communicating with external devices. For an application to make use of these features, the client device needs to be able to communicate this information somehow.

This leads us to the other part of the architecture that the client device communicates with, namely the client application. Knowing which languages can communicate with the different devices and their authentication methods is required to make a working framework.

Every client device has its own type of application designed for them. For mobile devices, the best examples are either Android or iOS applications, for desktop, we have Windows, Mac, and Linux applications.

A third option is web applications, which works on all of the clients as long as they have internet and a browser available. If a web application wants access to natively supported features, they might not necessarily have the required support. It is therefore important to figure out what to do if authentication methods within the device are desired to be used by a web app.

The communication between a client device and application will be possible as long as the device either has a browser, or a native application installed.

Master Thesis

Master Thesis

Developing a framework for secure authentication of Web and Mobile apps

Knut Erik Hildre

Thesis submitted for the degree of

Master in Informatics: programming and system architecture

60 credits

Department of Informatics

Faculty of mathematics and natural sciences

Master Thesis

Developing a framework for secure authentication of Web and Mobile apps

Knut Erik Hildre

Abstract

Contents

List of Figures

Chapter 1

Introduction

1.1 Motivation

1.2 Contribution

1.3 Research questions

1.4 Overview of chapters

Chapter 2

Client application technologies

2.1 Different types of client applications

2.2 Comparing the different application types

Chapter 3

Authentication technology

3.1 Different authentication technologies

3.2 Singe Sign-On solution

3.3 Federation protocol

3.4 Entities involved in the authentication protocols

3.5 Risk-based authentication

Chapter 4

Requirements

4.1 Functional requirements

4.2 Non-functional requirements

Chapter 5

Design

5.1 Overview of all actors