Authenticate Me

The importance of passwords

Nima khademi

Thesis submitted for the degree of Master in Information security 60 credits

Department of Informatics Faculty of mathematics and natural sciences

UNIVERSITY OF OSLO

Spring 2021

Authenticate Me

The importance of passwords

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

Printed: Reprosentralen, University of Oslo Abstract

Authentication is the process of verifying that an individual, entity, or website is who it claims to be. Authentication in the context of web applications is commonly performed by submitting a username or ID and one or more items of private information that only a given user should know.

Passwords have become the universal remote control of our digital authentication, yet they are taken lightly by the users. In this essay, I want to examine how password policies correlate to different attacks. Understanding how different password policies can have different impacts on security with regards to being too strict or loose with its requirements.

i ii Contents

1 Introduction 1 1.1 Brief History ...... 2 1.2 Motivation ...... 2 1.3 Problem Statement ...... 3 1.4 Structure of Thesis ...... 3 1.5 Research Method ...... 4

2 Background 5 2.1 Authentication Cycle ...... 5 2.1.1 Web Application ...... 5 2.1.2 Linux(Unix) ...... 6 2.1.3 Microsoft Windows ...... 8 2.2 Storing Passwords ...... 9 2.2.1 Plaintext ...... 9 2.2.2 Encrypted Passwords ...... 9 2.2.3 Hashed Passwords ...... 10 2.2.4 Multiple Iteration Hashes ...... 12 2.2.5 Salted Hashes ...... 13 2.2.6 Dynamically allocated salt ...... 13 2.3 Password cracking methods ...... 13 2.3.1 Brute Force ...... 14 2.3.2 Dictionary Attack ...... 16 2.3.3 Hybrid Attack ...... 16 2.3.4 Lookup Tables ...... 17 2.3.5 Rainbow Tables ...... 17 2.4 Obtaining Passwords ...... 17 2.4.1 Shoulder Surﬁng ...... 18 2.4.2 Keylogger ...... 18 2.4.3 Phishing Attack ...... 18 2.4.4 MITM (Man In The Middle) ...... 18 2.5 Common Safety Measures ...... 19 2.5.1 Creating Passwords ...... 19 2.5.2 Password Manager ...... 20 2.5.3 Enable Multifactor Authentication ...... 21 2.5.4 Protect Your Email ...... 22 2.6 Personal identiﬁcation number (PIN) ...... 22 2.6.1 Patterns ...... 23

iii 3 Password Policy 25 3.1 Policy Criteria ...... 26 3.1.1 Password length ...... 27 3.1.2 Special characters ...... 27 3.1.3 Numerical characters ...... 27 3.1.4 Reusing passwords ...... 27 3.1.5 Time ...... 27 3.1.6 Uppercase/Lowercase ...... 28 3.1.7 Positional ...... 28 3.1.8 Login attempts ...... 28 3.1.9 Slowdowns ...... 28 3.1.10 Strength barometer ...... 28 3.1.11 Dictionary ...... 28 3.2 Policy examples ...... 28 3.3 Threats ...... 29 3.3.1 Brute force attack ...... 29 3.3.2 Ofﬂine attacks ...... 30 3.3.3 Known passwords ...... 30 3.4 Security vs Usability ...... 30

4 Password alternatives 41 4.1 Something the individual possesses ...... 42 4.1.1 Yubikey ...... 42 4.1.2 Cautions ...... 46 4.1.3 Beyond identity ...... 46 4.1.3.1 Making SSO more secure ...... 47 4.1.4 General pros and cons ...... 50 4.2 Something the individual is ...... 51 4.2.1 Taking biometrics to the next level with Windows Hello 51 4.2.2 General pros and cons ...... 52 4.3 Something the individual does ...... 53 4.3.1 Keystrokes ...... 53 4.3.2 Draw a secret ...... 54

5 Data analysis 57 5.1 Findings ...... 57 5.2 Q&A ...... 58 5.2.1 What are the characteristics of the passwords that are cracked first? ...... 58 5.2.2 What are your thoughts about the basic16 policy? . . 59 5.2.3 Do you think basic16 presents the most difficult challenge in cracking passwords? ...... 60 5.2.4 To what extent do the criteria in a policy matter for your approach with regard to cracking passwords? And How do you alter your approach based on the criteria? More specifically, does the basic16 policy compared to the comprehensive8 policy change the way you start cracking passwords? ...... 60

iv 5.2.5 How do you calculate password entropy, is the Shannon calculation recommended? And how does this change your approach to cracking passwords? . 61 5.2.6 Do you see the “forgot password” function often used in exploitation? ...... 62 5.2.7 What alternatives do you see as the future of authentication? ...... 62 5.3 Experiment ...... 63 5.3.1 Results ...... 65 5.4 Discussion ...... 69

6 Conclusion 73

7 Future work 75

8 Terminology and Glossary 77 8.1 Password Strength ...... 77 8.2 Password characters ...... 77 8.3 Entropy ...... 77 8.4 Character classes ...... 78

v vi List of Figures

2.1 Web authentication process ...... 6 2.2 Entry from passwd ﬁle ...... 7 2.3 Entry from shadow ﬁle ...... 7 2.4 Linux authentication process ...... 8 2.5 Windows authentication process ...... 9 2.6 Symmetric key encryption ...... 10 2.7 Asymmetric key encryption ...... 10 2.8 Hash authentication process ...... 11 2.9 One way hash ...... 12 2.10 Different value hashes ...... 12 2.11 Multiple iteration hashing ...... 13 2.12 Salted hashing ...... 13 2.13 Main In The Middle Attack ...... 19

3.1 User experience ...... 32 3.2 User experience ...... 34 3.3 Character positions ...... 35

4.1 Biometric modalities ...... 42 4.2 Example of different Yubikeys ...... 43 4.3 Kerberos workﬂow overview ...... 48 4.4 Hierarchical chain of trust ...... 49 4.5 Mesh chain of trust ...... 49 4.6 Beyond identity ﬂow ...... 50 4.7 4 step plan for Windows Hello ...... 52

5.1 Result of password analysis basic12 vs basic16 ...... 65 5.2 Result of password analysis basic12 starting with uppercase character and ending with a digit ...... 66 5.3 Result of password analysis basic12 starting with uppercase character or containing an uppercase character ...... 67 5.4 Result of password analysis basic12 ending with a digit or contain a digit ...... 68 5.5 Result of password analysis basic12 contain a special character 69

8.1 How to Calculate Password Entropy ...... 78

vii viii List of Tables

2.1 Hybrid dictionary ...... 17 2.2 Factors ...... 21

3.1 Attack resistance ...... 34 3.2 Policy A ...... 36 3.3 Policy B ...... 36 3.4 Policy used at UiO ...... 38

ix x Chapter 1

Introduction

Computer security is often associated with three main areas. Conﬁden- tiality, is about ensuring resources are not read by others (read access), In- tegrity, which is about ensuring resources are not edited/changed by others (write access), and Availability, which is about ensuring the resources are accessible. This is often abbreviated to the CIA model. In the authentication process still, the most common way is by providing a username and password. This can be seen as a two-step process

• Identiﬁcation - who you are (username)

• Authentication - proving you are who you claim to be (password)

Proving user identity is usually done by using one or more of the following four means, something the individual knows (e.g. password, PIN, answers to pre-arranged questions), something the individual possesses (token, e.g. smart-card, electronic key-card, physical key), something the individual is (static biometrics, e.g. ﬁngerprint, retina, face), and something the individual does (dynamic biometrics, e.g. voice pattern, handwriting, typing rhythm).

Of these four means, passwords are the most used. Passwords are therefore an important personal security entity that needs to be chosen with some prerequisites in mind. There are many attempts to set password policies to help users pick a more secure password. Policies that set rules for how many characters a password can have, some minimum requirements for characters both special and regular to be included, and so on. Yet password cracking is still a major problem. In these big data times, we have a vast amount of different data that can help us understand the different ways passwords are being used by regular users. How users react to policies that differentiate between the level of security that is taken into consideration. The key for system administrators is to ﬁnd a balance between usability and security. We will see that more rules/requirements do not necessarily mean that the password would be stronger. If the policy is too complex for the users, they can take countermeasures like writing the password on paper or storing it online. But still, passwords are the most used

1 entity when it comes to authentication.

[21] [36]

1.1 Brief History

The concept of passwords is often linked with computers but is something that can be traced back hundreds of years. As an example from Martin Paul Eve’s book “Password” it reads

‘This was acutely developed in Ancient Rome, where an elaborate system of “watchwords” was deployed that shares many of the characteristics of contemporary passwords (most notably, a secure second channel). “Halt, who goes there?” is the canon-ical challenge.’ [14]

It is not only the password that is credited to the Romans. The cryptography method “Caesar cipher”, which I will get into later, got its name from emperor Caesar which is also from the Roman era.

The password used in computer security that we are more used to today was developed by Fernando Corbat. Fernando is widely regarded as the godfather of the modern computer password, he introduced the idea to computer science while working at the Massachusetts Institute of Technology (MIT) in 1960. [67]

Throughout the years there have been several kinds of tips and guidelines for the use and creation of passwords. What might have been a good idea at the time would later be uncovered as a security risk. Bill Burr the writer of “An inﬂuential guide to computer passwords” who is also known as the “Password Guru” gave the advice to muddle up words by adding capital letters, numbers, and special characters e.g "protected" might become "pr0t3cT3d4!". This as will be shown later is very easy to crack and it is safe to say Mr. Burr regrets giving this advice. [6]

1.2 Motivation

The Internet has become such an important tool in our lives and a lot of time is spent on using the Internet. We watch movies, do some shopping, pay our bills, stay in contact with friends, conduct our professional work, and so on. For a large part of Internet services, there is a need to create a user account. Be it using your email, online bank, online stores, or even your hair salon. According to research made by the password manager company NordPass a single user has up to 80 passwords [45]. All of these passwords belong to a user account and broadens the attack surface of the

2 users. This makes passwords an important step in the authentication process. They are so important that it is developed strategies to help users create strong and secure passwords. But still, we can read in the news about passwords being leaked.

This has made me want to dive deeper into what is done to help users with their use of passwords and why they are still not strong enough to prevent being hacked. I’m also curious about why passwords have lasted so long and why it is not replaced by a more easy and secure way to authenticate a user. Which led me to the topics of “Password Policy” and “Authentication alternatives”.

By the end of this paper, the reader will get an insight into the difﬁculties of creating password policies. Readers will also be presented with the challenges that lie in making a policy that the users will adhere to and not be tempted to make shortcuts that will result in a weaker policy than intended. The reader will be given examples of the pros and cons of the different aspects of password policies and the effect it has on users. This will help readers be more conscious about their choices in creating a password policy. I will also in the end present my own recommended policy.

1.3 Problem Statement

Through this thesis I want to know more about

• Why are the speciﬁc requirements included in the policy?

• What are the policies meant to be protecting?

• Why is there a need for password policy?

• What can be done to minimize or completely eradicate the use of passwords?

• How to use these results to create a password policy that is user- friendly and generates strong passwords

I intend to answer these questions through extensive research in published articles and research papers, a questioner with people in information security, and practical analysis on already leaked passwords.

1.4 Structure of Thesis

Before we dive into the topic of password policy I want to go over some of the histories behind passwords and the workﬂow/cycle of an authentication process. This is to show an overall picture of what happens after you type in your username and password and hit enter. Then we go

3 into the world of policies to find out their role in authentication and try to find a policy that would satisfy both security and usability. Next, we look at the alternatives to passwords to find out if we need to depend on passwords in the future. After this, we will go through the results from the questioner and password analysis, and finally, draw a conclusion and present the suggested policy.

1.5 Research Method

The research method used in this thesis consists of three steps. The first step consists of reading up on published research papers and articles covering different policies and how users relate to the different policies and passwords created with the different polices, and alternatives to passwords. The second step is to conduct a questioner of the findings from the first step with people working within information security to see if they agree or disagree with the data collected. The third and final step is to perform an analysis using different policy criteria on already leaked passwords to see if the results are the same as in other research and to verify the information given by the participants in the questioner. The results from all these steps will be used to compose our policy.

4 Chapter 2

Background

2.1 Authentication Cycle

In this section, we are going to look at some examples of the parts that are involved in the authentication process. Depending on the system in use and the service that is being accessed different steps are being taken to ensure the authentication is done securely. We are going to look at a typical modern web application using up-to-date and recommended methods, and two modern operating systems in Linux and Microsoft Windows.

There is some terminology that is being used in the next section that will be addressed in a later chapter.

2.1.1 Web Application

When it comes to authentication in web applications we can boil it down to three components, client, service, and storage. Where a client typically is a browser, service can e.g be Spotify, Facebook, or Twitter and storage are databases. In our case, we are going to add an authentication service that handles the storing of passwords and veriﬁes credentials. In a web-based application the authentication credentials usually consist of a username and password.

5 Figure 2.1: Web authentication process

Let’s say the client wants to access some resources from a service. To access these resources the service provider requires you to authenticate yourself. The user then enters its credentials which it sends to the authentication service. Because the user credentials are sent as plaintext the communication has to be on a secure line encrypted by SSL/TLS or better. The authentication service then performs the hashing using approved hashing algorithms (hashing algorithms will be covered later) on the password and looks in the database if it can ﬁnd a match with the username. In this example, the database and authentication service are on the same local network, and therefore there is not SSL/TLS encryption between these parties. The plaintext is never stored anywhere in the process. Only after the authentication is veriﬁed does the client receive a token from the authentication service which is used by the client to authenticate itself to the service. The service can then validate this token with the authentication service because there is a trust relationship between the service and AS.

2.1.2 Linux(Unix)

In this case, we are assuming we are on a local private machine and part of a larger network. In Linux authentication is done by the combination of username and password as in the above example. This is needed to get access to the system. When a user is registered the password needs to be stored. In the beginning, Linux passwords were stored in a file called passwd. This file contained different data like username, password, and hashing algorithm. An example of an entry from the passwd file would look like this.

6 Figure 2.2: Entry from passwd ﬁle

The details of this are not important, just that this is where the password hash is found. The passwords in Linux are hashed using different algorithms like MD5 which was used in the beginning and SHA512 which is more common on newer systems.

A major problem with this setup is that the passwd file was world- readable meaning all users can see the content of the file. This was done on purpose because much of the details stored were needed for the system to function properly. If the permission of the file was changed so only the root user would have access it would be possible to change users, find the home directory, custom shell, etc. This caused security issues that needed to be solved. Therefore the shadow file was created. An example of an entry from the shadow file would look like this.

Figure 2.3: Entry from shadow ﬁle

With the shadow file, the password was removed from the passwd file and stored in the shadow file that is only accessible by the root user. Now when a user is registered the password goes through the hashing process like before but gets stored in its own separate file. In addition to the

7 password hash other information like hashing algorithm, number of days the password has been used, number of days after which its necessary to change the password, and of course username so the system knows which password is belonging to which user.

Figure 2.4: Linux authentication process

[53]

2.1.3 Microsoft Windows

With the windows authentication system, two of the main components are the LSA (Local Security Authority) and the SAM (Security Account Man- ager). These are the two components that we will focus on.

In the same way as the two previous looked at systems the authentication is done by a combination of username and password. The username that is provided is cross-checked with the credentials stored in the SAM. To prove the identity of the user they must provide a piece of secret information, in this case in the form of a password. When a user signs in to a Windows computer and provides the user credentials (username and password) it is sent as plaintext. The plaintext is then converted to the correct encryption that is required by the authentication protocol. It is also important to point out the plaintext is never stored anywhere in the computer including the memory. The LSA queries the SAM where the credentials are stored and returns the necessary user information needed like the user’s SID (security identiﬁer) and SID of any groups the user belongs to. This is then used by the LSA to create an access token.

8 Figure 2.5: Windows authentication process

[38] [41] [17]

2.2 Storing Passwords

Authentication is considered an important security aspect, it is used to ensure that only authorized persons are allowed to enter and use the system. As mentioned in the introduction passwords are the most popular authentication method. It is the main method used for verifying the authentication and authorization of a user before entering an IT system. Because passwords are such a critical part of authentication the way we store them is of the highest importance. The username is usually the same across multiple accounts but it is the password that is unique (or at least should be unique). Therefore storing passwords differ from the way usernames are stored. Usernames are many times stored as plaintext while passwords have gone through several methods for keeping the conﬁdentiality and integrity from unauthorized users. We are now going to look at some of the methods used for storing passwords.

2.2.1 Plaintext In the beginning, passwords were stored in their plaintext version. This means that passwords are stored the same as what is typed by the user. Entering i.e "password1" as password would be saved as "password1" in the database. Having the password stored in plaintext made the security risk of potential data breaches critical in the sense that all the users passwords are shown. This is seen as the worst solution.

2.2.2 Encrypted Passwords Cryptography has become an important aspect of information security. With cryptography, it is possible to turn plaintext into something unreadable in the form of a random string of characters, also known as ciphertext.

9 This is called encryption, encrypt some plaintext into ciphertext. We do this mainly in two different ways called symmetric and asymmetric encryption. Both methods have in common that it is a key that is used for encryption and a key used for decryption. The main difference is that with symmetric encryption the same key is used for both encrypting and decrypting.

Figure 2.6: Symmetric key encryption

With asymmetric, there is one key for encryption called the public key and another for decrypting called the private key.

Figure 2.7: Asymmetric key encryption

By using encryption we can turn the passwords into ciphertext. This way we use an encryption function that only stores the ciphertext and not plaintext in the database. So in the case of data breaches the passwords are not shown. The downside of this method is that if the attacker gets access to the encryption key, then they will be able to decrypt all of the passwords.

[5]

2.2.3 Hashed Passwords This method uses a cryptographic hash algorithm instead of an encryption algorithm as the previous method. In the same way as encrypted passwords, the hashes are the only value that is stored in the database. The plaintext is never written to disk. By performing a hash function it takes in a message and outputs a value known as the hash value. In the same way, as with encryption, the output value is an unreadable string of random characters. The reason why this is not called encrypting is that with

10 encryption you are meant to be able to get the plaintext value back easily with the encryption key, while with hashing the goal is to make it impossible to get back the plaintext.

The general workﬂow for authentication in a hash-based system is that every time the user tries to log in, the system takes the password, performs the hash function on the password, and then compares it to the one that is stored in the database, as follows

• The user creates an account

• Their password is hashed and stored in the database. At no point is the plain text password ever written to the hard drive.

• When the user attempts to log in, their entry is found based on username, the hash of the password they entered is checked against the hash of their real password (retrieved from the database).

• If the hashes match, the user is granted access. If not, the user is told they entered invalid login credentials. And the two last steps are repeated

Figure 2.8: Hash authentication process

The size of the hash depends on the algorithm that is used. The most common sizes are between 128-512 bits. The most common hash algorithms are Message Digest 5 or MD5 and Secure Hash Algorithm 1, 2, and 3 or SHA1/2/3. Though it should be emphasized that MD5 and SHA1 are no longer deemed secure.

11 One of the main properties of hash functions is that they are Preimage Resistant (one-way) functions. That means that they are designed in a way that makes it easy to calculate one way but almost impossible to calculate the other way. In other words, given a value x and a function f(), it is easy to compute the value f(x). However, knowing the value f(x) and the function f(), it is very difﬁcult to ﬁnd the value x.

Figure 2.9: One way hash

Another important property of hash functions is collision resistance. Because the hash functions have fixed sizes independent from the size of the message, or password in this case, as output there will eventually be a scenario that you will find two identical hashes that have different message values. This means that an attacker could use another password that would give the same hash value as another password and authenticate itself this way. Collisions are directly related to the security of hash functions and password storing. This is why it is important to choose an algorithm with sufficient size.

Also, the ability to make hashes completely different given minor changes in the message is also one of the main beneﬁts. This means that given the passwords "hello" and "hbllo" would give very different hash values as shown in the example from [55]

Figure 2.10: Different value hashes

2.2.4 Multiple Iteration Hashes

This method is very similar to the "hashed passwords" method, but it runs additional runs through the hashing function. By doing this re-hashing you would in theory make it more difﬁcult for the attacker. The re-hashing can be done by the same or different algorithm and the number of iterations is also up to the developer. This is still seen as not secure given that the attacker can ﬁnd the number of iterations and algorithms chosen and create rainbow tables.

12 Figure 2.11: Multiple iteration hashing

2.2.5 Salted Hashes

Salted hash is a concept that was needed given the problem of rainbow table attacks. A method was needed to mitigate against this. Thus came salt to the rescue, adding salt to the password is a way to counter this attack. A salt value can be any random string that is added to the password before hashing. By doing this the attacker’s rainbow tables become obsolete. Given the salt is a random value, which also should be different for every password, the attacker would need to make a rainbow table for every salt value. This is of course still possible but time-wise it is not seen as feasible. It should also be mentioned that you can always also add some “pepper” to the mix as well.

Figure 2.12: Salted hashing

2.2.6 Dynamically allocated salt

This is a newly proposed method developed by [8] that I wanted to share. This method tackles the problem that salt values are usually stored at the beginning, middle, or end of the password. The "Dynamic allocated salt" method calculates for each password where the salt is placed. The salt value is also split into single characters before being placed and as such it gets spread between the entire password.

[55] [8]

2.3 Password cracking methods

Password cracking is a form of attack where the goal is to ﬁnd the plaintext version of the stored password value. Since passwords remain the most widely used form to authenticate users, obtaining the passwords through data breaches is sadly still common. Thus approaches and methods for attacking passwords are still as relevant as before. The traditional password cracking methods include among others brute force, dictionary attack, and a hybrid attack.

13 2.3.1 Brute Force This is the most comprehensive form of attack. It will go through every possible combination of characters that it is fed (attacker can decide what kind of characters). This can be a very time-consuming method and also one that most likely would have to be performed ofﬂine because of countermeasures like only being able to type incorrect passwords three times. But it will ﬁnd your password in the end. Although this method is very time-consuming, the hardware that we have today is so powerful that it may still be feasible. Take for example a PC running with an AMD Radeon HD7970 GPU, it can on average try an astounding 8.2 billion password CES (combinations each second) depending on the algorithm used to scramble them. Start adding more expensive GPUs, and also newer, the number of CES could easily be multiplied by two or three. Brute-forcing will still have its limitations due to the exponential growth in the total number of possible passwords when the password length increases. Let’s take a look at some attack examples with different password policies.

To give an example of the challenges that lie within making a policy, I will make an example of two different policies. This is to show the total number of passwords that can be created using the policies and how long it would take to brute force attack these passwords given the two different policies. The policies are made up of four different groups, ﬁrst is all lowercase letters, second is all uppercase letters, third is numbers from 0-9 and the fourth is special characters, the number of special allowed is 15. The three policies are as follows

• Policy 1: The password length must be 8 characters but no other restrictions, meaning the user is free to choose whatever they want from the four groups

• Policy 2: The password length must be 8 characters and the user needs to use at least one character from each group.

• Policy 3: This is the same as policy 1 with no demands but, users can only use a maximum of 6 characters.

Also, we can make the assumption that the hardware being used is capable of calculating 10 billion passwords per second. And as we will see later, 10 billion calculations per second is not an expensive achievement with the hardware we have at our disposal today.

Policy 1 To ﬁnd the total number of passwords that can be created by the ﬁrst policy we need to add the number of characters allowed by the different groups (26 + 26 + 10 + 15) and then calculate the password length of 8 characters (778) this will give us 1.24 * 1015 number of passwords that can be created. Now if the attacker uses brute force attack, that would as worst-case scenario (for the attacker) use approximate 144 days and averaging to about 77 days.

14 Policy 2 The second policy gives us some constraints that the ﬁrst did not handle. Because the policy demands that we use at least one character from each group. We also need to exclude the possible combinations that do not fulﬁll the requirements.

This gives us, using the same approach as the previous example (778) a total of 1.24 * 1015 passwords. Then we need to calculate the number of combinations that have to be excluded. First, we exclude all combinations that do not include at least one character from each group. For lowercase letters, we get 518. Then we exclude uppercase letters, 518. We do the same for digits and special characters, 678 and 628 respectively. Now that we have calculated all the possible combinations that need to be excluded we can subtract that from the original total, 778 - 518 - 518 - 678 - 628. Then we need to take into account the multiple exclusions that cover the same scenario, this is done by using the inclusion/exclusion principle

1. no lowercase or uppercase

2. no lowercase or digit

3. no lowercase or special characters

4. no uppercase or digit

5. no uppercase or special characters

6. no digit and special characters

Then we subtract the single combinations that are not allowed. Calcu- lating all these steps gives us a total of 5.9 * 1014 The time used to brute force this amount given the same one second per attempt restriction would give us the same approximation of 69 days and averaging to about 35 days.

As we can see, we have signiﬁcantly reduced the time it takes to crack the passwords. This might seem counterintuitive but, this is to help the user create a less predictable password. Since humans are not that good at creating random passwords, having such constraints on your password policy will aid your users.

[46] [25]

Policy 3 The third policy is to show the difference when we lower the maximum limit of characters allowed but with no other restrictions. Using the same mathematical approach as in scenario 1 we get 776 which amounts to a total of 2.1 * 1011 number of passwords that can be created. The time we would use to brute force this amount of passwords is at a worst-case about 35 min and averaging to about 18 min.

15 2.3.2 Dictionary Attack

With this attack, the attacker creates a list of keywords that get used as passwords. For e.g a list of the most used passwords or the complete set of words from an actual dictionary. Another approach is to take a full background check of the victim’s social media accounts, workplace, and so on to make dictionary-based words the person uses and is associated with. By doing this the attacker can signiﬁcantly reduce the time of successfully cracking a password. This is because sadly people’s choice of password is more predictable and less random than it should be. A report from 2019 done by CNN shows a list of the top 10 most used passwords are.

1. 123456

2. 123456789

3. qwerty

4. password

5. 111111

6. 12345678

7. abc123

8. 1234567

9. password1

10. 12345

[52]

2.3.3 Hybrid Attack

With this approach, the dictionary attack method is a little altered. It uses the dictionary method but also adds rules for changing/adding/removing characters from the password. This is based on the fact that users often used the same password with small modiﬁcations. For example, a password could include the current year, which would mean only one to two character changes for every new password. Let’s look at an example using “password” as the password.

16 Table 2.1: Hybrid dictionary Rule Mangled password Adding characters password123 123password Replacing characters p@ssword pa55word passw0rd Capitalizing or upper-casing Password passWORd

2.3.4 Lookup Tables

Lookup tables are an effective way of cracking hashed passwords. By pre-computing the hash values of the passwords and storing them in a lookup table with their corresponding password you can process hundreds of hashes per second.

2.3.5 Rainbow Tables

With the use of rainbow tables, we are able to speed up the password cracking process by using pre-calculated hashes instead of calculating them on the fly. The hashes are stored in a compressed form to speed up the process and lower the computing requirements needed to brute force huge numbers of hashes. Rainbow tables are best described as a list of chains, and with each list, they are assigned different characters to use for combinations. With the use of a special mathematical algorithm, it is possible for rainbow tables to start with a password and then calculate the hash, check if it is correct and if not it calculates the hash back to some other clear text password combination and repeats the process. Using this approach rainbow tables only store the first and last value which saves space and makes it so that it can be loaded into memory for increased speed. By saving the last element when we crosscheck for matches and if found we can use the first element to recreate the entire chain. This is a simplified explanation of rainbow tables just to get an understanding of the concept.

[55] [18]

2.4 Obtaining Passwords

In the previous section we discussed some ways to crack passwords, but how do we obtain them in the ﬁrst place? There are different ways to obtain someone’s password. Either by going the simple way in the form of shoulder surﬁng or plain old guessing, or the more advanced way with methods such as MITM or Phishing attacks.

17 2.4.1 Shoulder Surﬁng

Shoulder surfing is a relatively simple method to get access to your victim’s credentials. Let’s take an example where you are sitting in a coffee shop minding your own business focused on your work conveniently done by using a laptop. Another customer is of the more curious kind not minding his own business and takes a look over your shoulder, hence the name shoulder surfing, the culprit is then able to see you type in something that is supposed to remain confidential. By doing this he gets enough information to perform his attack.

2.4.2 Keylogger

Keylogging is a method that records all of the keystrokes a user makes on their keyboard and saves it to a log ﬁle. This can be done either by using software or by a hardware device. With software, the attacker is able to install malware on the victim’s computer. This can for instance be done by the malware acting like a Trojan that downloads the keylogger through some harmful software. Other ways include purposefully being installed by other people like employers keeping track of their employees, parents wanting to know what their kids are up to, or suspicious spouses. As you can imagine keyloggers are able to give the attacker a vast amount of information from the user.

The other way an attacker can use keyloggers is by hardware. As many keyboards are connected by USB, an attacker can install a middle piece between the keyboard and computer. This piece of hardware acts as the keylogger and contrary to using the software cannot be detected by anti- malware protection. After some days the attacker can come back or and detach the hardware it previously installed containing the logs.

[22]

2.4.3 Phishing Attack

This method is when attackers make a fake website that users often visit e.g online banking or social media sites. The attacker needs the victim to visit this site thinking it is legit. This can be done by i.e sending the victim an email with some reason for them to visit your site and log in. Added in the email is a link that looks very close to the real link. If the user uses the link and login then the attacker has the victim’s credentials.

2.4.4 MITM (Man In The Middle)

Man-in-the-middle attacks are the practice of intercepting communication between two parties. Also called eavesdropping. With this form of attack, the attacker is able to see all the information being sent between the parties. The attacker can choose to be passive and just “listen” or be more active and

18 intercept. By intercepting the attacker can take one message from subject A and alter it before sending it to subject B.

Figure 2.13: Main In The Middle Attack

Even though we have methods of encrypting the communication between parties MITM attacks are still relevant. Some companies even do this on purpose for advertisement purposes, “surprise surprise”, like in the Superﬁsh incident when Lenovo had a piece of software pre-installed on their customer’s devices. This software was designed to inject ads to your browser as well as intercept encrypted communication and thus acting like a MITM.

[64] [56]

2.5 Common Safety Measures

As cyber-attacks became more common, there have become some standard recommended safety tips that users can follow.

2.5.1 Creating Passwords When creating passwords there are some things to keep in mind besides the restrictions applied by password policies.

• Do not use common words when creating a password. As we have seen there are methods like a dictionary attack that can crack these passwords. Having a random set of characters adds protection against dictionary attacks.

• Do not use personal information. Attackers can create a proﬁle of their victim by using sources like social media to get to know things like workplace, hobbies, and interests. Attackers can then make a list of words and use e.g dictionary attack

• A strong and secure password requires some degree of complexity. Password strength and entropy are two important factors in this. The length of the password is the easiest to accomplish, although a long password doesn’t necessarily mean it would take longer to crack it is

19 still a strong form of defense. Entropy is the next thing to take into consideration which may be more difﬁcult. As such it is important to include special characters and numbers when creating a random password. Password managers could be a good solution, which we look at later.

• Do not reuse passwords. If an attacker gets hold of your password they would most likely try that on all your accounts. This is also why it is important to have unique passwords because attackers if found one password can try to apply small changes and crack your password this way. Having your passwords unique from one and another adds protection against attacks like e.g hybrid attack.

• Do not write down your password or store it online. This is pretty obvious but storing passwords online in places like Google Drive or Dropbox is also regarded as not safe. If you must write it down, write down something that is associated with the password that can help you remember.

2.5.2 Password Manager

A password manager is a tool that helps users with their password management that can be seen as the vault of all of the user’s passwords. Lastpass is one of the more popular password managers and provides different features that aid to the ease of use with having to deal with all of the online accounts. Features like

• Storing all of your passwords using strong encryption in the form of AES-256 bit with PBKDF2 SHA-256 and salted hashes.

• Creating random password with the options to choose between what kind of characters to include, how many characters, if it should be easy to read, easy to say.

• Reminding you to change the password after a set time.

• Gives notice if you have duplicate passwords.

A password manager is set up with one master password, boiling down all the passwords you need to remember down to one. You still have to create one strong password but after this, the manager will take care of storing and creating the rest of the passwords with as much strength and entropy you like. Password managers also often come as browser plug-ins or mobile applications prompting you to ﬁll out your credentials for you. Making them very convenient to use. This is one of the exceptions to storing passwords online.

But a password manager uses, as earlier mentioned, a single master password, if this password gets cracked then the attacker will have access

20 to all of your passwords. And, as it also can be used as a browser plug- in the safety and security features of your browser will play a role since the attacker could get access by attacking your browser. Taking these risks into consideration a password manager is still recommended. Though one should be wary of which password manager you end up using. Password managers that are built-in browsers have come into some criticism over the years. Google’s Chrome browser has been storing passwords in its plaintext form for years. Even to this day, it is possible to see all of your stored passwords without needing a master password. One simple way is to choose to export all of your saved credentials which will then create a .csv with all the information shown in plaintext. So an important takeaway from this is to think carefully before choosing which manager you are going to be using. As a rule, built-in browser password managers are better left alone.

[1] [47]

2.5.3 Enable Multifactor Authentication

2-factor or multi-factor authentication adds an extra layer of safety to the authentication process. The three different types to prove authentication was.

Table 2.2: Factors Factor Examples Something you know Password PIN Security question Something you have Hardware or software tokens Certiﬁcates Email SMS Cellphone calls Something you are Fingerprints Facial recognition Iris scans and hand-print scans

By using a multifactor way of authentication you have to at least com- bine two of these factors. It should also be noted that requiring two examples of the same factor, e.g password and pin does not constitute being multifactor. Because the most common way an account is compromised is through passwords, adding another layer of authentication that has to be

21 done is a great way to increase safety. There are several ways that this is taken into use. To name a few e.g some send an SMS with a pin number to your cell phone, others use an authentication application that gives you the code, using one-time passwords as we do with our online banking. If possible, enabling this you always have a minimum of two steps that are needed for authentication.

The downside of using this is the usability for the users. As it often is, with increased security there is a decrease in usability. Users will always have to take an extra step for authentication which can become quite cumbersome after a while. Also if the user loses their second way of authenticating it usually is not as simple as hitting the “forgot password” link to get access again.

[50]

2.5.4 Protect Your Email

Your email is the key to all your accounts. Email is one constant factor in all your online accounts. Getting your email hacked gives the attacker a lot of possibilities to inﬂict damage. As an example if you ever forget your password and hit the "forgot password" link, most likely you will get a link sent to your email enabling you to change the password. Protecting your email is therefore also an important factor to take into consideration. This is another example where enabling multifactor authentication on your email would have protected you.

2.6 Personal identiﬁcation number (PIN)

PIN numbers are another widely used alternative to passwords that ﬁt in the category of something the individual knows. PIN numbers are usually a sequence of numbers that consist of 4 or 6 digits (though 5 is possible). As a way of authenticating, PINs are already used in many sectors e.g in ATMs, door locks, and SIM cards. In this case, we are focusing more on the use of PINs in PCs and smartphones. In contrast to passwords, PINs are usually much easier to remember due to the relatively short length. Many would argue that PINs are safer to use than passwords despite the lower number of possible combinations, as with 4 digits there are 104 combinations and 106 using 6 digits that result in 10 000 and 1 000 000 respectively. This is because PINs are stored locally on your device in contrast to passwords that have to be compared to a hash stored on a remote server. This means that if somebody is shoulder surﬁng your PIN they cannot go home and use this pin to unlock your device, they would have to steal your device in addition to getting hold of your PIN to be able to any damage. This greatly reduces the number of attacks that can be done and thereby decreasing the attack surface.

22 2.6.1 Patterns As an alternative to PINs, there are some manufactures that have implemented the possibility to use patterns. With patterns, you can draw a consecutive line between the numbers on your device creating a symbol and thereby making the experience more graphical e.g creating a square by drawing a line that goes from 1-7-9-3 and back to 1. The only constraint being your line cannot break at any point. The security aspect is the same as with PINs in that this is something that is stored locally on your device.

[59] [40]

23 24 Chapter 3

Password Policy

Password policies are known to many users, sadly often as a source of frustration. We have all been there trying to make a secure password only to get a message that your password does not cover all criteria. Often it feels like it is unnecessarily difﬁcult to make a password satisfying all criteria and when you do manage to create a password it is too hard to remember. But besides causing people frustration there is a reason why password policies became necessary and why they seem to have so many criteria.

[16] Password policies are used by many sectors and not just for online accounts. There are also policies for e.g user authorization in operating systems, access restricted rooms, access restricted appliances, and so on. The focus of this paper will be more on online accounts, but the ﬁndings and approaches should be applicable to other sectors. As online accounts became more and more in use there became a need to help guide users to create stronger passwords. Because of this password policies have become an important security aspect.

There are many different ways to approach password policy creation. As it should also depend on what the assets are. You have to think about what it is you are offering the users, i.e is your site making money on users, is it only for information, is it a tool...? We see that in [15] policies tend to vary based on what the site is offering. Sites that base their revenue on selling products like Amazon have looser requirements for their password policies. This is because Amazon makes money from people buying products, and users need to be logged in to be able to do so. And therefore any policy criteria that might cause the user to get frustrated and make them use another site, has to be reconsidered. Often we see user convenience being more important than strict password policy to these types of sites. For sites at universities or in government sectors the research found that password policies had more criteria. These are sites where the user needs the information and the services provided by the site, users are usually locked to the one site without alternatives. And so the user experience, as far as password policy goes, can be taken more lightly.

25 But users must still be able to make passwords, so policies cannot go overboard. The study showed that the minimum required password bit strength was for most of the commercial sites between 15-25 bits and for most of the university and government sites were between 45-55 bits. And so by making password policies tailored to the sites’ needs, companies can help users create more secure passwords.

An example of a password policy could be e.g "Password must contain three of the ﬁve criteria classes"

• Lowercase character

• Uppercase character

• Numbers

• Special characters

• No dictionary words

Further in this chapter, we are going to take a look at how different policies are put together and their criteria to see the password strength they provide the users. We are going to analyze different threats to get a deeper understanding of how policies can help prevent these. An important question when it comes to opposing strict policies on users is to which degree it should depend on users being able to make a sufﬁciently strong password or system administrators following best practices.

Passwords are part of the concept of having “defense in depth” which dictates that there should be more than one layer of security so that an attacker has more hoops to go through to complete a successful attack. A simple example that might make it easier to understand is if you think of the front door of your house, this door requires a key to open, now let’s add another door that would require a pin number and another (different) key to unlock the door, and we add a third door that would require your ﬁngerprint to open the door and then after unlocking all three doors you are ﬁnally able to get inside your house.

So should the fault when a password is cracked lie on the administrators or users? Further in this chapter, we are going to take a look at some policy examples and the subsequent result of set policies.

[31]

3.1 Policy Criteria

There are many different approaches to making policy. One policy could only have the criteria of a minimum of 8 characters while others might

26 demand the addition of numbers and special characters. Let’s look at some examples of different criteria.

3.1.1 Password length

Password length is the number of characters that are allowed to be used. Could be either upper or lower limit or both at the same time. I.e a password should have at least 8 characters but not more than 20.

3.1.2 Special characters

Special characters, also called non-alphanumeric characters are characters such as !, @, %, <, >, and so on. There are a lot of different special characters to choose from, so the number of different special characters and which ones to use vary from policy to policy.

3.1.3 Numerical characters

Numerical characters are numbers that range from 0-9.

3.1.4 Reusing passwords

This criterion makes it so that the system checks if the user is trying to use a password that is formerly used and denies them to do so. There could also be a check to control that the password is sufﬁciently different from the others used, i.e changing "password" to "password1" would not be allowed.

3.1.5 Time

This criterion is so that after a set period of time the password would no longer be valid, e.g that the password must be changed once every month, forcing the user to change their password. This can be by e.g sending the user an email reminding the user to change the password or by prompting the user to change the password at the next login. Another time restriction that could be set is on the minimum allowed time. This means that the user cannot change the password before a minimum amount of time has passed, i.e the user must wait one hour before changing the password again.

This is a criterion that can quickly cause user frustration and therefore must be considered how and if it should be used. Because by forcing users to change passwords too often it will be difﬁcult for users to make up a strong password by themselves. This can lead to users trying to use the same password with minor tweaks or by completely abandoning the system. This criterion in combination with the “Reusing password” criteria will also ensure users cannot just make minor tweaks to the new password.

27 3.1.6 Uppercase/Lowercase This is in relation to alphabetic characters, requiring an upper or lower case letter to be included. Could also be requirements on how many times it must occur.

3.1.7 Positional This requirement means that there are requirements on where some characters should occur, e.g that there should be a number in the middle of your password. Now let’s say that your password is "password", using this rule we would need to change it to something like "pass1word" to satisfy the requirement.

3.1.8 Login attempts Having a limit on login attempts makes it so that if a user enters the wrong credentials e.g three times, the user will get locked out for x amount of time or until the admin grants access again.

3.1.9 Slowdowns Slowdowns are a way of making the login process slower each time a login attempt fails. One approach could be by adding a couple of seconds to process time each time an attempt fails. This can also be done by using a method called key-stretching.

3.1.10 Strength barometer A strength barometer is a way to give users feedback on the strength of the password they have chosen, i.e how secure is the password. This has been shown to be an effective method in helping users create more secure passwords. Though this has also been shown that it can be a vulnerability in that it can give an indication about what kind of passwords are created in that it can create a pattern for attackers to exploit.

3.1.11 Dictionary With this criterion, the policy has a blacklist dictionary that is cross-checked when a user creates a password. If the password is in the dictionary, common passwords or earlier breached passwords the password gets rejected.

[15] [28] [36] [20] [72]

3.2 Policy examples

There are several ways to create and customize policies. In this section, we are introducing some examples of different policies. These policies give

28 each a different result in security and user-friendly ratio and will be looked at later in this chapter.

Basic8 - The password must have at least 8 characters.

Basic16 - The password must have at least 16 characters.

2word16 - Is like Basic 16 only that it has an added criteria that states it should contain two words, that is to say, letter sequences separated by a non-letter sequence.

Dictionary8 - The password must contain at least 8 characters and can not contain a word in a dictionary. One way this can be checked is by removing all non-alphabetic characters from the password and looking up the remaining letters in a dictionary, ignoring case.

Comprehensive8 - Passwords must have at least 8 characters including an uppercase and lowercase letter, a symbol, and a digit. It may not contain a dictionary word.

[35]

Dynamic Password Policy What this method proposes is to have several different policies stored as to not give all users the same policy. This is to not let attackers be able to conduct training-based password attacks. By not having one speciﬁc policy the attacker will not know for sure what policy is in use.

[72]

3.3 Threats

Another reason for using password policies is to reduce certain threats to revealing or cracking passwords. These attacks are, but not limited to.

3.3.1 Brute force attack

Some password policies can include a restriction on how many attempts the user has to enter passwords i.e if the user tries a wrong password three times, the user gets locked out for x amount of hours. It could also be a case of slowing down the login process i.e making it so that after each failed login attempt it takes an additional two seconds to log in.

29 3.3.2 Ofﬂine attacks

If the attacker gets hold of the password ﬁle containing all the password hashes they can crack the hashes without any restrictions in terms of timeouts or by slow-downs mentioned in the above brute force section. Creating strong policies that will help create strong passwords will help make this kind of attack infeasible.

3.3.3 Known passwords

Depending on the policies the problem of reusing passwords can also be addressed. Because some policies can have a requirement that your password cannot be one that you have chosen before. This can be checked by storing the hashes of the previous passwords and compare to see if they match. There could also be a restriction against common passwords found in the “top 100 used passwords” lists found online.

3.4 Security vs Usability

One of the main issues that we experience when creating a password policy is that they are too difﬁcult and complex for users to adhere to. Yes, there are many focal points that we have to think about and take into consideration when we are creating a password policy. But, by far the most important aspect is the effect the policy will have on its users. That is to say, how will the users go about when using the policy. It is no point in creating a policy that makes users “cheat” their way into making a valid password that checks all the criteria. It is of the utmost importance that we focus on the balance between security and usability.

We will see in this section that both can be achieved, creating a policy that generates strong passwords and usability that will make users create passwords in an intended way. As an example let’s use the incident in 2016 when 32 million Twitter accounts and 360 million MySpace accounts were hacked and as a consequence, their passwords got leaked. Most of these passwords were either dictionary words, names, or simple numbers e.g “12345” appeared 120,417 times, and the word “password” appeared 17,471 times. This is the result of a policy that focused more on usability than security, because these are passwords that should not have allowed in the ﬁrst place. In another research with nearly 500,000 participants, re- searchers found that users have an average of 25 accounts and 6.5 different passwords.

There have been done many studies about the correlation between password policies and user experience. We are going to take a look at several of them to get an understanding of why users react the way they do and what can be done to make it easier for them to follow the policies.

30 [24]

In a study done by the Department of Computer Science and IT at Jin- nah University, they studied the password management of people. They performed surveys to ﬁnd out what type of passwords users create in relation to the policy they had to follow. This would help understand user preferences for security or usability. That is to say how much would the users “cheat” the policy in order to create a password.

The tests were done by asking users to create passwords using different types of websites such as social media and online banking sites. There were four different policies used in the survey, Basic8, Basic 16, Comprehensive8, and Dictionary8, which are all described in their own section earlier in this chapter. The study was done with 240 participants which consisted of mostly people between the age of 15-45 which amounted to 89% of the participants. It shows a distinct difference between people under the age of 45 and people over 45. People of the age 45 and under were taking the security aspect more into consideration when creating passwords, while people over were more concerned about remembering the passwords they created thereby opting more for usability. This is an interesting ﬁnding that shows instead of creating just one policy, we could tweak the original policy to create another policy to reach out to different age groups. A summary of the user experience of the different policies can be seen in the table below.

31 Figure 3.1: User experience

Using these policies most of the passwords were created by using a predictable approach. The participants used names of people that have some sort of association with them, be it a person that is closed to them or a celebrity they like. They also used dictionary words, personal information, or phrases. All in all, these kinds of passwords were used by 69% of the participants. This shows that these types of policies did not guide users in creating what would qualify as a secure password. Even though the passwords were generated by content that is easy to guess the participants were largely satisﬁed with their choice. From the questioner, we can see that based on the policies Basic16, Basic8, Comp8, and Dic8 56%, 85.5%, 74%, and 84% respectively, answered “yes” if they were satisﬁed with their passwords. This can indicate two things, either that the participants are not

32 aware of what constitutes a secure password or that they do not think it is of that much importance.

The survey also shows that the policies the users found most helpful were Comp8 and Dic8 with 73% and 76% respectively answering yes to it being helpful. Another interesting ﬁnding is that with policy Comp8 only 40% would want to use this policy in the future. This was also something that was shown in [35] where 68% of the 5000 participants using the Comp8 policy dropped out on the ﬁrst day while trying to create a password. This goes to show that cramming more criteria in a policy in an attempt to make a more secure password is not always the right way to approach the matter, as also shown by [35] where it was found that increasing the minimum length was more effective than applying content constraints.

When [35] tested the difﬁculty in creating a password they had 5000 participants, and the comprehensive8 policy proved by far the most dif- ﬁcult, as only 17.7% of users in this condition could create a password in one try. By contrast, 52.7%, 56.6%, and 88.6% of participants in the basic16, dictionary8, and basic8 conditions respectively created an acceptable password in one try.

In the study done by [35] they focused more on entropy estimates de- rived from a large-scale empirical study. This would allow for comparison of entropy across different password-composition policies. The policies that were used in this study were the same that as in [24], that being Basic8, Basic16, Comprehensive8, and Dictionary8. We can ﬁnd several interesting takeaways from this study. For instance, it was made a comparison between the two policies Basic16 and Dictionary8, and according to guidelines made by NIST, these two policies should result in passwords of more or less the same entropy. However, in the study, they found that the Basic16 policy yields signiﬁcantly fewer predictable passwords and that it is less troublesome for users.

Another estimation made by NIST is that Basic16 and Comp8 should result in passwords of the same entropy, however, after testing, the results showed that Basic16 has signiﬁcantly more entropy compared to Comp8 with 44-bits vs 34-bits respectively. This is also something that can be found in [58] where they compared the number of guesses it would take to crack a password using Basic16 compared to Comp8. It shows that with a 106 guess limitation Basic16 revealed more passwords but given a limitation of 1014 guesses Comp8 showed to be the weaker policy. This suggests that Basic16 would reveal more passwords in the short run but be more resilient in the long run. But then by contrast, if we compare with 2word16 then it would perform better than both Comp8 and Basic16 given the same limitation on guesses as described above. After 1014 guesses 50% of the Comp8 passwords were cracked, 30% of the Basic16, and 22% of the 2word16 passwords.

33 Figure 3.2: User experience

In the NIST guidelines, it is stated that adding a dictionary check would increase entropy. But results from [35] where the Basic8 and Dictionary8 were added to verify this they found that it resulted in a non-statistically- signiﬁcant increase in the observed entropy. However, it should be mentioned that adding a dictionary (also checking substrings) check does strengthen the password even though it may not do so in entropy it showed that it was strengthened in making it more resilient to being cracked. For example, passwords containing the substring 1234 were twice as likely to be guessed as those that did not. This is also shown by looking at the number of cracked passwords of Basic8 compared to when there is an added dictionary check to the policy, by it being reduced from 188 cracked passwords to 99 with a dictionary check. To perform this test the popular tool called “John the Ripper” was used, by setting this to use a heuristic-mode that transforms dictionary words into password guesses. The chosen dictionary is also an important factor, the larger the dictionary the more password can be caught, in [35], it was used a dictionary containing 3,9 million entries. What is also interesting is how resilient Basic16 was to being cracked, where the only restriction is a minimum of 16 characters.

Table 3.1: Attack resistance comp8 bas16 d8 bas8 Cracked 0/997 9/971 31/963 188/972 Cracked + pass dict. check 0/997 6/971 26/963 99/972 Cracked + not in large dict. 0/997 1/971 3/963 28/972

[35] Adding numbers to passwords is thought to reduce predictability only slightly, due to the assumption that the digits will occur in easily predictable locations within the passwords. However, [35] shows that a sig-

34 niﬁcant amount of the entropy of passwords is contributed by the portion of numbers that the passwords contained. This is a result of several factors. First, that the entropy per digit is higher than the entropy per lowercase letter (e.g., 2.82 vs 1.75 in the Comp8condition), indicating that there is less consistency in which digits users choose than which letters they choose. This is important because as we took a look at earlier, checking substrings containing predictable sequences of digits like “1234” were more likely to be cracked. Despite the fact that there are 26 lowercase letters and only 10 digits they did add more entropy.

Second, the participants in [35] used a larger than expected number of digits in their passwords. In all conditions, participants’ passwords had an average of at least 2.20 digits. In particular, Basic16 passwords used on average 3.76 numbers, signiﬁcantly greater than in any other condition.

Finally, it was a big variability in where the users chose to put digits. As with numbers, it was also found that participants used a variety of symbols. The symbols ‘@’ and ‘!’ were the most common, but many others were also used. Only a small fraction of participants made use of symbols when they were not forced to do so by the password policy. Even when required by policy to use both symbols and numbers, participants favored numbers. Equal results can be found in the study from [58] where users often select symbols from only a small fraction of the symbols that were made available. It is also found that when users employ digits, symbols, and uppercase letters in their passwords, they often do so predictably.

Further, passwords that were required to have multiple character classes rarely began and ended with lowercase letters. Instead, participants tended to put special characters at the start or end of their passwords. Those passwords that did begin and end with lowercase letters were quite strong.

Figure 3.3: Character positions

A study conducted by the Department of Computer Science at Univer- sity College London was focused on designing the policy based on HCI (Human-Computer Interaction) principle. They used 32 participants made

35 up of staff members for two organizations. The two policies used in the study were.

Table 3.2: Policy A Restriction Criteria Length 7-8 characters Character sets At least one character from 3 of the 4 classes Character classes Lowercase letters (a-z) Uppercase letters (A-Z) Numbers (0-9) Special characters Password must not Consist of words or proper names, including foreign language words, or variants produced by exchanging I’s, L’s, or O’s for 1’s and 0’s Expiry 4 months History Must not be similar to 12 previous passwords Password management Password synchronization - one password for many organizational systems Impending password expiry is signaled to users by email sent to their organizational address

Table 3.3: Policy B

Restriction Criteria Length Minimum 6 characters Character sets At least one character from 3 of the 4 classes Character classes Lowercase letters (a-z) Uppercase letters (A-Z) Numbers (0-9) Special characters Password must not Include parts of user’s name or other common words Expiry 90 days History Must not be identical to 9 previous passwords Password management SSO for most organizational systems Impending password expiry is signaled to users by a warning at login time for two weeks prior to expiry

In regards to policies, there is something that is called a breaking point which is one of the key elements that need to be calculated. The breaking point is about the maximum effective entropy. A study done by [4] shows this to be 18-bits for all types of passwords.

[29] emphasize is on the passwords that are used in organizations. By studying organizations we can observe how users differ in their password approach compared to commercial sites. In an organization, the conse- quences of a poorly chosen password could be directly linked to the em- ployee and as a result, put their jobs in jeopardy. Maybe they will lose their job, maybe they could get suspended, or demoted if they are found guilty of actively compromising their account with poor password management, that is to say how they choose and store their passwords. It could also cost the company in an economic sense and in the sense of damaging the company’s reputation. All of this gives a different basis for how the users/employees are creating their passwords.

36 Participants in the study [29] showed to be more security conscious but had to use coping mechanisms with the policy demands. This is a consequence of what can happen when policies do not consider the human aspect of the password generation cycle. Even though this policy is made for an organization we still have to remember that the users are still human. Thereby creating difﬁcult policies, can and probably will result in unin- tended reduced security that the policy was originally meant to achieve.

One of the requirements that created problems for the users was the criteria that the password had to be changed frequently. This was because users had already struggled to create and learn their passwords and then they had to do this again on a regular basis based on the fixed period that was set in the policy. This caused frustration for the users which resulted in coping mechanisms that compromised the security that was originally intended by e.g writing down passwords or choosing some password that was comprised of objects found on their desk or the office. This could be a flower, picture, or maybe a book they had, anything that would help make it easier to remember the password. This is a well-known coping strategy that attackers know about and can easily create a dictionary to perform a dictionary attack. The same is also often done by going through the users/victim social media accounts where you can find the person’s likes and dislikes, family and friends, and other interests to dig deep and gather as much information as possible to create a dictionary. The study [29] also showed that users rarely changed their password if they did not have to, and often it was changed because it was forgotten. This was another consequence of that the passwords were too difficult to create.

Another requirement that made it difficult for the users was the fact that they could not use the same or similar passwords as chosen before. Of course, it was not meant to just keep using the same password but in these specific policies, it went back to the last 12 passwords in policy A and the last 9 in policy B. These might seem like reasonable and good requirements from a security perspective but what the study [29] showed is that this made it so difficult for the users that they had to write down their passwords. One exception to this is if the password that the users created had to be used frequently on different services. This showed that it made it simpler to remember due to fact that it was repeated so often.

The users also had this fear of forgetting their passwords. When users had forgotten their passwords they often got locked out of the system due to too many attempts. This caused wasted time and subsequently made the only option to reset the password which meant contacting “helpdesk”, this wasted more time. In this organization, after changing the password you had to wait an additional 2 hours before you could start using the services again. All of the combined downtime this created made so that users became anxious when it came to forgetting their password. This of course also affected productivity. Users that wrote down their password did so in a way they thought of as “safe”. This could mean that they stored it in their

37 diary or wallet, this also showed to be the case in [16]. Keeping your password in a safe place if you write it down could be sufﬁcient enough but, if this is the strategy then password managers, as discussed earlier, would be more recommended.

At the University of Oslo, they conducted a study on the user expe- 1 rience surrounding their password policy where just 8 of the users that consist of students and employees found it to be the solid average grade of “OK”. This led to a change of approach in the way they asked users to handle their passwords, both in creating and resetting. This was a study that showed how to change a failed policy and make it into something the users were able to use.

One feedback from a student made it clear that there were criteria in the policy that was not made clear how to achieve what was intended as a source of frustration. When a student thought they had covered all areas and after they were done they got a message telling them that the password was rejected. Why it was rejected was not previously stated. As an example, the policy did not specify that it was the first eight characters that were part of the validation, meaning that all of the criteria had to be ful- filled in the first eight characters. This also has to do with security, because it is intended to keep the attackers guessing in what kind of passwords are created, that is to say, what the passwords consist of in terms of policy criteria. This showed that some sort of indicator that gave feedback while typing would help the users. This was also something that was found to be true in a study made by [35] where they had a policy that did a dictionary check, but it was not stated how they checked this. The way they checked for words in the dictionary was by stripping the password for all symbols and numbers and then make a crosscheck with a dictionary. So let’s say a student uses the password “p1a1s1s1w1o1r1d”, this would end up being “password” when it is checked.

The policy that the University of Oslo used before they changed it was

Table 3.4: Policy used at UiO

Restriction Criteria Length 8 or more Character classes Lowercase letters (a-z) Uppercase letters (A-Z) Numbers (0-9) Special characters Password must Contain characters from 3 of the 4 classes and it has to be among the ﬁrst 8 characters. If the password only contains one uppercase letter it cannot be the ﬁrst character. If the password only contains one number or special character it cannot be the eighth character. Password must not Contain space or a null character. Contain a sequence of related characters. Contain repetitive characters. Be your username even in reverse order. Contain 5 or more characters from your name. Be similar to a previous password

38 [16] The University also said the policy does not differ between students and staff members.

The fact that many of the users were using their smartphones when they were using the services also had to be taken into consideration given the limitation a smartphone introduces. On smartphones, the keypads are much smaller and you often have to slide to a different keyboard to ﬁnd the keys you are looking for. Therefore it is easier to make mistakes and typing in the wrong characters which, in a combination that you do not see the characters you are typing can easily become a source of frustration. A solution to this problem was to add a “show password” button.

After conducting much research they decided to try to change the criteria and instead require that the password must exceed a password strength of X. The reason for this was that the length of the password was more important than the complexity. So to reach the desired password strength users could choose from

• Sentences

• Words

• Numbers

• Special characters

• Space

The more of the classes that were included in the password the faster the password strength went up. This was thought to make it more user- friendly. Still, the password could not contain the date of birth or your name. Also, the option of showing your password while typing made it easier for the users to repeat the password and to possibly ﬁnd where you have made errors. By also adding a password strength barometer to show by graphic how strong your password is while typing also helps the users with a visual aid. A password barometer can be as simple as showing by color-coding the different strengths of the password, e.g stretching from red to green. Where red symbolizes weak and green symbolizes strong. This shows that simple changes can make big differences. This is also something that was found to be true in studies made by [35] and [24]. A further function that can be added to the strength barometer is a comment that shows how long or easy it would be to crack their chosen password and a list of tips to make it stronger. This way users are made more aware of how safe their passwords are and as a consequence how safe their accounts are in case of data breaches. Of course, this is not something that is recommended for workplaces but in those situations, the usability can be taken differently compare to commercial sites. Also, having an adaptive policy based on users/employees’ access rights is an idea worth exploring, this

39 way different staff members have different policies based on their authorization level.

[9] [57]

40 Chapter 4

Password alternatives

Up until now the way of authentication that we have focused on is something the individual knows in the form of passwords. This is only one of the four means that can be used for authentication. As discussed earlier in the intoduction the other three are something the individual possesses, and something the individual is, something the individual does. As we have seen there is a lot of pros and cons to using passwords. One of the most serious issues in regards to passwords is the level of security or rather lack of, they provide, as 80% of all data breaches are caused by breaking passwords [68]. Also, by using passwords for authentication there is no form of proving the identity of the user i.e the same password for the same account can be used by several people without any issues. As a result alternatives for passwords have been in the works for quite some time. In this chapter, we are going to look at some of the alternatives available that are used. As an example, Microsoft has been investing a lot of resources in their “Windows Hello” system, and Samsung started with the use of patterns instead of PIN codes on their Galaxy devices. Smartphones, both for Android and iOS, now have the capability to use face recognition and fingerprint scanning. The use of biometrics is not something new but since passwords are so convenient, easy to implement, and low on cost it has not been taken in by the industry. There is cooperation between several companies that work together in finding a solution to passwords that can completely replace it which is called FIDO. The FIDO Alliance is an open industry association that is working towards helping to find alternatives to passwords. FIDO is a collaboration with several leading tech companies which includes among others Microsoft, Amazon, and Apple. FIDO is comprised of two standardized components, a web API (WebAuthn) and a Client to Authenticator Protocol (CTAP). The two work together and are required to achieve a passwordless experience for login. This technology is in use in e.g Yubi-keys and the aforementioned “Windows Hello” so it has already started gaining a lot of traction.

41 Figure 4.1: Biometric modalities

[48] [2]

4.1 Something the individual possesses

In this section, we will discuss how to authenticate with something the individual possesses. A user can perform the authentication process with a device that does not require the user to enter any credentials i.e no username and password. This is something different from the 2-factor authentication where e.g you would get a message/code sent to your phone. Examples of alternatives can be in the form of a Yubikey or with the use of certiﬁcates as done by the “Beyond Identity” project. Many of these systems take advantage of asymmetric cryptography.

4.1.1 Yubikey

Yubico is a company that has created an authentication system that uses something they have called a Yubikey to be used as an alternative to passwords. A Yubikey looks much like a USB ﬂash drive, and just like ﬂash drives it also comes in different sizes.

42 Figure 4.2: Example of different Yubikeys

[73]

The general idea can be compared to an everyday key. As a key is used to unlock different doors and appliances, a Yubikey is used to unlock your accounts. And just like the key to your house or car, it is something that is usually always with you and something that is kept safe. It is not something that you leave lying around or leave in public places. The thought of Yubikey is similar. You carry it everywhere. To unlock a device whether a desktop computer, a smartphone, a manufacturing control system, a healthcare portal, or some other device you simply plug the YubiKey into a USB port or place the key near a NFC (Near Field Communication) sensor. Then, when prompted, you tap the key and optionally enter a PIN or use a biometric control, depending on the application or service. This process has then performed the same authentication that we are familiar with when using a username and password. As mentioned Yubikey also adds the possibility to be used on its own or in conjunction with a PIN or gesture to provide strong passwordless authentication, in addition, two- factor authentication with a password continues to be a supported authentication mode.

43 The Yubikey system comes in different variants. • Single Factor (Passwordless) Use of the security key on its own as a strong ﬁrst factor of authentication, requiring only the possession of the device, allowing for a tap and go passwordless experience • Two Factor (Password + Authenticator) Use of the security key as a second factor in a two-factor authentication solution Multi-Factor (Passwordless + PIN or Biometric) Use of the security • Multi-Factor (Passwordless + PIN or Biometric) Use of the security key for multi-factor authentication requiring possession of the device AND a PIN or Biometric, to solve high assurance requirements Yubikey is based on the asymmetric cryptography method which we discussed earlier in the introduction section. It uses a public/private key pair to authenticate users. The public key is stored on any service or computing device supporting the FIDO2 authentication protocol, while the private key is kept by the user and is protected on a physical security key, such as the YubiKey. A special security chip that is known as a Trusted Platform Module (TPM) can also handle the public and private keys. TPM technology is designed to provide hardware-related security functions. The TPM chip is designed to carry out cryptographic operations. The most common TPM functions are used for system integrity measurements and for key creation and use. In our case, this is the handling of the private and public keys. The chip includes multiple physical security mechanisms to make it tamper-resistant and also resistant to malicious software. Most recent devices such as laptops and smartphones include a TPM. The Yubikey unlocks the FIDO security key and enables it to initiate a key exchange with whatever it’s authenticating to the local device, a remote directory service, a website, a social network, or some other IT service. In a business context, employees would be able to be more productive in the sense that the time that usually would be used on creating, memorizing, resetting, and creating passwords would no longer be an issue. Not to mention the time-savings this extends to help-desks and support centers that no longer have to devote time to helping users reset passwords. In a case study done by Google, they reported a reduction of 92% in calls made to the support center saving thousands of hours per year in support costs [19]. Other companies report massive savings between 5M−20M due to the reduction of calls to support. This was all done by changing the authentication process to use the Yubikey system. By switching to Yubikey you also remove the weakest link in a security system, the password. Two of the most important security issues to tackle in regards to the authentication process are phishing and man-in-the-middle attacks. Both of these issues are countered with the use of Yubikeys.

Defense against phishing In the case of phishing, using the Yubikey system instead of passwords makes it so that there are no credentials for the attacker to steal. The at-

44 tacker cannot get hold of any information needed to authenticate by using traditional phishing attacks. The Yubikey system does not rely on passwords and therefore the attacker would need to get hold of the physical key to have a chance to hack the account. Since over 7% of users receiving emails are fooled into opening an attachment or clicking on a link, which is usually a login link just confirms the severity of the problem. Most of these attacks eventually lead not only to credentials being stolen but also to the installation of malware that leads to data breaches. Even if users create complex passwords that are difficult to guess, their accounts can be compromised once hackers harvest their login credentials through phishing. This just emphasizes the great benefit that the use of Yubikeys will do to tackle this security issue.

In 2017 Google launched its Advanced Protection Program (GAPP) for those users they regard being at the highest risk including journalists, business leaders, and political campaign teams. The GAPP program further tightens up security for Google account users by requiring the use of hardware-backed security keys for secure login versus making them op- tional. To provide the strongest defense against phishing, Advanced Pro- tection goes beyond traditional 2-Step Veriﬁcation. Participants in GAPP are required to sign in to their account with a password and a physical security key i.e the Yubikey. Other authentication factors, including codes sent via SMS or the Google Authenticator app, will no longer work, since these forms of 2-factor authentication have been shown to be prone to phishing.

The TPM mentioned earlier can also be conﬁgured in a variety of ways. This is something that can be used to mitigate phishing attacks because it prevents the key that is used in regards to the asymmetric cryptography from being copied and used without the TPM. TPM-based keys can also be conﬁgured to require an authorization value to use them. If too many incorrect authorization guesses occur, the TPM will activate its dictionary attack logic and prevent further authorization value guesses.

The downside of 2-factor authentication

The idea behind 2-factor authentication is something that we have looked into earlier. It is a method that adds a layer of security in addition to the password that is needed to complete the authentication process. This feature is recommended to enable anywhere it is supported. Let us use the example where you get an SMS message. In addition to entering your password, there is a message sent to your phone with a code that you have to enter. This works in theory, but in practice SMS- based 2-factor authentication has been shown to be vulnerable to hijacking, enabling attackers who have discovered users’ passwords to intercept the transmitted code sent to your phone and masquerade as the owner of the phone. Another problem is that SMS messages sometimes fail to arrive, or that the user is trying to log in but has no service or is out of power. In these cases, the user must ﬁnd some other way, if possible, of providing a

45 second factor for authentication. Another serious problem is man-in-the- middle attacks that interpose themselves between users and the websites they’re trying to reach, and trick users into entering usernames, passwords, mobile numbers, and SMS codes sent to those mobile numbers. By the time the attack is complete, the attackers have gleaned login credentials and an SMS code that can be used to access the legitimate site the user was trying to reach. Nearly all traditional strong authentication mechanisms, including mobile push authenticators, are vulnerable to these attacks. This is another issue that is solved by using the Yubikey system.

General pros and cons Pros

• Longer codes can be used, which may provide a higher level of security.

• Users can simply press a button rather than typing in a code.

• Resistant to phishing.

Cons

• The use of physical tokens introduces can in some cases cause signiﬁcant costs and administrative overheads.

• Stolen tokens can be used without a PIN or device unlock code.

• As the tokens are usually connected to the workstation via USB, users are more likely to forget them.

4.1.2 Cautions Even though these solutions sound good and are used by many companies, they are still proprietary solutions that could hide some, intentionally or not, backdoors that would give them access to your system. So you have to take into account that you still put your trust into the hands of someone else. Open source solutions would give anybody the chance to take a look at the code and to verify themselves if it is good enough and even make their own implementation, this is not the case when it is proprietary. [73] [74] [75] [39] [49]

4.1.3 Beyond identity Beyond identity is another company that is developing an alternative solution to password authentication. They are basing their approach on self-signed certiﬁcates in an effort to deviate from, what they consider to be one of the biggest weak points, a shared secret. The shared secret in this context is a piece of data known only to the parties involved in the authentication process that communicates over a secure channel. This is

46 in our case most often the password, but also PINs or different forms of biometrics, as biometrics often are more just for convenience in that it is transformed to a hash in a similar way a password is. It is, in essence, just exchanging one type of shared secret (password) for another (fingerprint). Anything shared also means that there is an administrator who knows about it and that it is stored in a database that can be vulnerable to compromise. The systems storing e.g fingerprints, retina, or face patterns can also be hacked, and if that happens, you can’t change these biometrics like you can with a password. This makes it so that there is a far greater consequence if the database is compromised. The Beyond Identity approach to authentication does not share secrets with anyone and does not use unreliable and insecure channels for authentication (no SMS, push notifications, or email links). They are using industry-proven public key infrastructure (PKI), TLS, and hardware enclaves to give users the best of all worlds. By doing it this way they are trying to minimize user inconvenience and improve security. Beyond identity build their approach on the SSO (Single Sign-On) concept.

4.1.3.1 Making SSO more secure

Single Sign-On makes it possible for users to authenticate themselves using a single set of credentials. This is developed to make it more convenient for users to manage different passwords to different accounts by allowing, as the name implies, a single sign-on to access all accounts. The idea is to make it so that if the user signs in one place and then visits another site that supports SSO would not need to sign in again i.e when a user is authenti- cated it is not necessary to reauthenticate.

SSO is based on the Kerberos key management system. More correctly Kerberos is what is called a key distribution center (KDC) and is a way to manage authentication and communication over a network. Kerberos enables clients to securely access other services in a secure way. Clients need to access the KDC to get “tickets” that allow them to talk to other services they wish to access. So in the context of SSO the client authenticates itself only once and gets a ticket it can use to access a service, and then when it wants to access another service it can get another ticket without needing to reauthenticate. You could think of it as for example when you go to an amusement park, at the gate you pay for a ticket giving you access to the park after you have this ticket you are able to access different rides without the need to go back to the gate to get another ticket (reauthenticate) each time you want to take a ride. This is of course a whittled-down explanation but the basic idea still stands. An overview of the workﬂow looks like this.

47 Figure 4.3: Kerberos workﬂow overview

[11] SSO is a great first step to ease user frustration caused by passwords, but it does not solve the underlying security issue. The session token that enables subsequent authentication can be hacked and used for an evil purpose. And session tokens are often configured to remain valid for a long time to make it more user-friendly increasing the window for it to be compromised. Also, the passwords needed to access the SSO and for any applications that do not support identity management integrations are often still stored on servers. Beyond Identity is designed to eliminate passwords and the risk that comes with them, using the concept of the personal certificate authority. Beyond identity, much like Yubikeys, leverages secure industry-standard asymmetric-key cryptography for authentication. And one of the key aspects is that instead of a password, it uses self-signed certificates (x.509). This is the same trusted technology used by websites all over the world recognized by the keylock icon in the address bar.

Certificates are built upon the concept called “chain of trust”. By having a certificate you prove that you are who you say you are i.e when you access google.com the only way you can be sure this is the correct google.com is that it has a valid certificate. Certificates are issued by a certificate authority (CA) that signs certificates to different services. This CA is something you just have to trust is not an evil entity issuing certificates with an incentive to do evil in the same way you trust your bank to not steal your money. The CA is the first or what is called a “root” entity of the “chain” when you have this entity that you trust it can then delegate other certificates enabling you to trust other parties and thereby creating a chain of trust. In a chain of trust, there are different infrastructures e.g a hierarchical or mesh infrastructure.

48 Figure 4.4: Hierarchical chain of trust

Figure 4.5: Mesh chain of trust

[61] [10]

Beyond identity uses a cloud solution that employs an app on endpoint devices to create and manage keys to change the way users authenticate into networks and applications. The private key is stored in a TPM and never leaves the device. In addition to providing the highest levels of

49 authentication, the system collects and sends critically important device security posture information in a signed package (JWT – JSON Web Token) with each authentication transaction. The application delegates to the SSO provider and the SSO subsequently delegate authentication responsibilities to Beyond Identity. Beyond Identity integrates with existing SSO solutions making it less of a hassle for companies to use. This makes the cost savings more signiﬁcant than e.g buying extra hardware needed to support an alternative solution.

Figure 4.6: Beyond identity ﬂow

4.1.4 General pros and cons Pros • There is no need to purchase and manage hardware tokens. • Once installed, certificates are very simple for users. • Certificates can be centrally managed and revoked. • Resistant to phishing. Cons • Using digital certificates requires a backend PKI system. • Installing certificates can be difficult for users, particularly in a highly restricted environment. • Enterprise proxy servers that perform SSL decryption will prevent the use of certificates. • The certificates are stored on the user’s workstation, and as such can be stolen if their system is compromised. [49] [70] [71] [60] [27] [26]

50 4.2 Something the individual is

Up until now, we have looked at two of the four concepts of authentication, that being, something the individual knows and something the individual possesses. Now we are going to look at the third concept, something the individual is. What is often heard when it comes to this concept is “biometrics”, which is explained as “body measurements and calculations related to human characteristics” [7]. That includes, but is not limited to, your fingerprint or thumbprint, palm, handprint, retina, iris, voice, and face. Out of these the most used are fingerprint and face. Almost all smartphones now provide the option for enabling fingerprint authentication although not as many support face recognition. Computers, mostly laptops, have long supported fingerprint scanning, and now many support face recognition e.g Microsoft has put a lot of effort into their Windows Hello feature and is the feature we will be taking a further look at.

[49] [12]

4.2.1 Taking biometrics to the next level with Windows Hello

As mentioned Windows Hello has long been in development and started being shipped to selected computers in 2015. Making it able for users to sign in to the computer and other different services after login with other methods than a password. Users can use pin-code, ﬁngerprint, or face recognition. As mentioned, after a successful sign-in users can sign in automatically to different services like e.g email. With this solution Microsoft wants to deliver on two key promises, 1. is that users should not have to deal with passwords in their day-to-day lives, and 2. user credentials cannot be cracked, breached, or phished. This is something that they are going to achieve by the 4-step plan they created.

1. Develop password-replacement offerings, i.e., replace passwords with a new set of alternatives that address the shortcomings of passwords while embracing their positive attributes.

2. Reduce user-visible password-surface area, i.e., upgrade all expe- riences related to the entire life-cycle of a user’s identity (including provisioning of an account, setting up a brand-new device, using the account/device to access apps and websites, recovery, etc.) and ensure these work with password-replacements.

3. Simulate a passwordless world, i.e., enable end-users and IT admins to simulate and transition into a passwordless world.

4. Eliminate passwords from the identity directory, i.e., the ﬁnal frontier – delete passwords from the identity directory.

51 Figure 4.7: 4 step plan for Windows Hello

Windows hello is based on a minimum 2-factor authentication. This is done by using a private/public key pair in junction with e.g a face scan. The private/public key pair is developed much in the same as it is done by Yubikey in that the private key is stored on the device’s TPM and a public key is available to the different services. If the device does not have a TPM chip, the private key is encrypted and protected by software. This also makes it so that an attacker would need the physical device it is trying to compromise because the private key is stored on the device itself. Another feature of Windows Hello is that users can link their phone to the computer via bluetooth. So when you sign in the phone must be in proximity of the computer to be able to unlock, this also means that if you leave the computer without locking it ﬁrst it will automatically lock when the connection to the phone is no longer in reach. This is handy in public places as well as the work environment and more secure than a time-based locking that there already is a function for.

The webcam is also a factor when using face recognition. The camera used by Windows Hello is not like a standard webcam. It requires a speciﬁc RealSense depth camera module and infrared sensors.

Windows Hello is now being used by over 47 million users worldwide. More than 5,000 businesses have deployed Windows Hello for Business, with adoption on over one million commercial devices.

4.2.2 General pros and cons

Pros

• Well-implemented biometrics are hard to spoof and require a targeted attack.

Cons

52 • Require manual enrolment of the user’s physical attributes.

• Custom (sometimes expensive) hardware is often required to read biometrics.

• Modern browsers do not have native support, so custom client-side software is required.

• If compromised, biometric data can be difﬁcult to change.

[59] [62] [63] [49]

4.3 Something the individual does

The methods of authentication that are based on something the individual does are not as much used as the others we have looked at. Something you do refers to a few things that you do to unlock or gain access. Examples based on this factor can be, among others, the use of voice recognition i.e the way one talks, gait i.e the way one walks, or keystrokes. The concept of using keystrokes is that it registers how a person writes on a keyboard, using parameters that will be stored and analyzed, e.g typing speed, pauses, the length of time that keys are held down for, and pressure. These parameters are then compared with previously registered patterns. Authenticating with something the individual does is cheaper to implement in comparison with static biometrics and usually does not require special hardware. On the other hand, these features are often hard to repeat in exactly the same way. This introduces information noise. Both valid users may find it difficult to repeat the activity, in the same manner, to fit into their stored patterns. This would require much data to be able to identify the user accurately and the more data is stored the higher the accuracy it will have. On the other side, impostors may also be close to imitating valid data and be falsely accepted. In this section, we will look at some examples of authentication done by something the individual does.

4.3.1 Keystrokes The handwritten signature has a parallel on the keyboard. The same characteristics that make a written signature unique are also exhibited in a user’s typing pattern. When a person types on a keyboard, he/she leaves a digital signature in the form of keystroke latencies and the other factors mentioned in the previous section. For well-known, regularly typed strings this signature can be quite consistent. The keystroke dynamics of one person are signiﬁcantly different from those of others due to several factors, such as, among others, age, primary language, and familiarity with the input device. Thereby this can be used as an additional factor that is being checked when used in combination with username and password. This can be implemented in different ways, for instance when a user types the correct password, the keystroke signature also has to be valid to be able to complete the authentication. It can also be that the user is allowed access

53 with the correct password but failed the keystroke signature and this will result in restricted authorization, so if the user wants to perform a certain task being deemed with a higher risk then the user must be able to give the correct signature, this can, for instance, be in an online bank where the user would be allowed to pay an invoice that has been done every month for a long period of time but if the user tries to transfer money to an account that it has never done before it will be rejected and would require further authentication. Because it is based on a behavioral biometric feature it can be fully implemented in software, which in turn, can be applied to any systems without installing additional hardware. When a user creates an account in addition to providing a password the user is asked to provide a certain number of typing patterns that are then stored and used for comparison.

4.3.2 Draw a secret Another way of authenticating based on something you do is the concept of drawing a secret. This was originally intended to be used so that users could draw a shape from a grid view. This would allow users to use a more graphical way compared to passwords. People are known to being able to remember visual aids easier than long phrases. Given that grids are made of identical squares with no uniqueness it became clear that it was difficult for users to use. As a result of this, there came an addition to this approach by adding a picture background to help the user when drawing given unique features of images to aid in correct placement of the drawing. Microsoft developed a variation of this they call picture-based authentication (PGA) that was used in their Windows 8 release. This came about in regards to the challenges that come with the use of keyboards on smartphones or tablets. In these instances, the use of keystroke signatures will become challenging and not work quite as intended due to the difficulty in using a touch-based keyboard with restricted space. With these types of devices, it would be in many cases difficult to give the same signature even by the same user. Windows 8 was shipped with a new method of authentication based on picture gestures where the user could upload a picture and draw different gestures with the use of a tap(indicating a location), line(connecting areas or highlighting paths), and circle(enclosing areas). If the user draws a free-style gesture, the system will convert it to one of the three recognized gestures. For instance, a curve would be converted to a line and a triangle or oval will be stored as a circle.

As with any method of authentication, there are weaknesses in this one also. In a research done by [76], they found that there are many similarities in the weaknesses as there are in passwords. They were also able to create a dictionary and perform a dictionary attack, as they found that much like passwords there are features where users are drawn to like eyes and nose. Some of the results they got where

• 60 percent of subjects ﬁnd locations where special objects catch their

54 eye

• 86 percent of subjects drew on the eyes at least once

• 45 percent of subjects drew on the nose

• 82 percent of gesture types were taps

• 15 percent of gesture types were lines

• 7 percent of gesture types were circles

[44] [13] [32] [37] [54] [51] [33] [69]

55 56 Chapter 5

Data analysis

In this chapter, we are going to analyze data collected from a survey done with people working within information security. The previous chapters have gone through and looked at different studies on password policies with the purpose to determine how they impact users when it comes to creating passwords. One of the objectives of this paper is to find what criteria we should use to create a policy with the goal being to guide users in creating secure and easy-to-use passwords. With this in mind, the questions asked were directly related to this. The questions that were asked are • What characteristics do the passwords that are hacked first have? • What are your thoughts about the basic16 policy? • Do you think base16 presents the most difficult challenge in cracking passwords? • Does the basic16 policy compared to the comprehensive8 policy change the way you start cracking passwords and if so how does your approach differ? • How do you calculate password entropy, is the Shannon calculation recommended? And how does this change your approach to cracking passwords? • To what extent do the criteria in a policy matter for your approach with regard to cracking passwords? And How do you alter your approach based on the criteria? • Do you see the “forgot password” function often used in exploitation? • What alternatives do you see as the future of authentication?

5.1 Findings

Based on the ﬁndings in chapter 3 we can argue that policy base16 is a policy that gives users a good foundation to create a strong password with

57 sufﬁcient usability without noteworthy complications. The base16 policy was tested against many other policies and there were, of course, other policies that would yield more resistant passwords with regards to time used to crack it but, it would be at the expense of usability. Therefore the policy base16 resulted in a good middle ground for security and usability. Because of this, I wanted to use it as the root when creating my recommended policy. I wanted to keep the policy as simple as possible and keep the constraints at a minimum. The goal is also to make the policy so that all the sectors can use it, that being e-commerce, universities, government, and so on. Given the answers from the survey, I was able to gather information to design a policy with the objective being to generate strong passwords in a way that is user-friendly. Because as we have seen ease of use will have a direct impact on the quality of the passwords, that is to say, how easy they will be to crack. The contributors have different roles in the information security sector, one is working as a password researcher, which I will refer to as respondent A, one is working as an Information Security Research Scientist (respondent B), and the third is a head engineer for a security company (respondent C). In the next section, we’ll go through the questions from the survey and discuss the answers given by the participants.

5.2 Q&A

5.2.1 What are the characteristics of the passwords that are cracked ﬁrst?

Question (background) This question was to get a general understanding of what is regarded as weak passwords and what those weaknesses are. By getting more knowledge of this we can see which criteria of a policy are part of these passwords. This will also help to show certain weaknesses of different criteria.

Answer All of the participants were in agreement that one of the characteristics was that the password is short, by that they mean eight or fewer characters. Respondents A and C also said that in combination with being short the passwords also use dictionary words and permutations of this, words that have a special relation to the person, in relation to some of their interest, something associated with the company they are using the account for, association with the company they are working for, or one of the classic top 1000 most used passwords. It was also said by respondents A and C that users had a tendency to use an uppercase character at the beginning of the password, followed by lowercase characters and digits, and ending with a special character. This was also something we saw found in other researches in chapter 2.

58 Conclusion The characteristics explained resemble the comprehensive8 policy, in that all four character classes are used (table 3.4), which is a policy we see often used. As this is a common policy, users have developed a known approach that makes it easy for them to include all the necessary criteria. This could also be the reason why we see the sequence in which the passwords are composed the way they are. Since comprehensive8 requires all four character classes would indicate that these requirements do not always result in stronger passwords. This is also one of the reasons I wanted to do this thesis as the common thought would be that the more requirements there are the more secure the password will be.

5.2.2 What are your thoughts about the basic16 policy?

Question (background) My thought was to use the base16 policy as the foundation. I was interested in hearing the thoughts the participants had about this policy to ﬁnd out if they did agree this was a good policy to use as a starting point and what they see as the strength and weaknesses.

Answer All the participants did agree that base16 would generate strong passwords especially with regards to brute force resilience, with the general understanding being that the longer the password is the better. Respondents A and C did also say that reducing the minimum length from 16 to 12 would still make brute force attacks infeasible. All three said that it was more important to think about what the password, or the more recommended passphrase, should be. By using a phrase instead of a word that had no relation to the user would make guessing harder. Getting used to passphrases instead of words makes creating long passcodes easier. Re- spondent C also emphasized that long words do not equal a phrase giving the example if you chose the password “Sommerferie2014”, which is the Norwegian word for summer vacation, is not a strong passphrase even though it is 15 characters long since it is still predictable in that it is still a word that starts with an uppercase letter followed by lowercase characters and ends with digits. Also, it is associated with the season that was probably that time of year.

Conclusion So, based on this we can say that the participants did agree that base16 would be a good starting point and even to might as well reduce the minimum limit to 12 characters and instead focus on guiding the users to create phrases instead of words. The length of the passcode will not have much beneﬁt if it is still predictable as the example the participant gave of “Sommerferie2014”.

59 5.2.3 Do you think basic16 presents the most difficult challenge in cracking passwords? Question (background) My thoughts when it came to this question was that I wanted to find out if the base16 policy actually made it more difficult to crack the password for people that had experience in this field. What is calculated in theory is not always how it is in practice. This is a significant factor when it comes to deciding the length criteria in a policy.

Answer Respondents A and C, which were the ones that had the most experience with cracking passwords, said it did not prove to be much of a difference because users were still predictable in their approach, like the example of “Sommerferie2014”. The difference is just how long it took them to crack it, and they were speaking in the sense of hours and days, not months and years. The last participant did not have enough knowledge to weigh in on this.

Conclusion This goes to show that the emphasis should be focused more on what the password is compared to what it should contain with regards to the character classes. So if users put more time in the recommendation that tells us to use a phrase instead of a word is followed, then that would lead us a step in the right direction.

5.2.4 To what extent do the criteria in a policy matter for your approach with regard to cracking passwords? And How do you alter your approach based on the criteria? More speciﬁcally, does the basic16 policy compared to the comprehensive8 policy change the way you start cracking passwords? Question (background) After learning what kind of challenge base16 posed when it came to cracking passwords I was curious if their method change when compared to the comprehensive8 policy since this policy has more restrictions. How do each criterion alter their approach, with the goal being to understand if there was any speciﬁc criterion that caused them extra headache when they saw that this was included in the policy. If it was then this should be taken into extra consideration when creating the policy.

Answer Respondents A and C which had the most experience with cracking passwords told that it did not change their approach and their procedure was the same. One explanation was that even though it had more restrictions it was still predictable how the password was composed which

60 is what was discussed in the first question. Meaning the users made the minimum effort to just fulfill the requirements. All the participants said the criteria that mattered most was the length, in that it required more thought. Respondents A and C also said that requiring the user to change the password after a fixed period of time is rarely a good solution because it usually results in small changes to the password, e.g “password1”, “password2”, and so on. Educating users on how to create passcodes is the greatest handicap since policies will only get us so far.

Conclusion So, because the added criteria in comprehensive8 compared to the single restriction in base16 did not alter the approach in cracking the passwords created gives us more reasons not to include restrictions just for the sake of it. The criterion that mattered most was the length of the password which is also what I was taking into account when using base16 as the foundation to build upon. The focus should be more in the direction of adding guidelines, with the use of phrases instead of words being an important factor.

5.2.5 How do you calculate password entropy, is the Shannon calculation recommended? And how does this change your approach to cracking passwords?

Question (background) Through my research, I have seen some different ways of calculating entropy with the Shannon calculation being the most used. The calculation is explained in the chapter about Terminology and Glossary. Since I found some different ways of calculating this, I was interested in hearing to what extend the participants use password entropy when cracking passwords.

Answer All The participants said they did not calculate entropy and did not ﬁnd it useful. Respondent A also said that the Shannon calculation is not recommended. Respondent A did however recommended using a password strength barometer to help users when creating passwords, making it more of a gamiﬁcation experience. This is also something found in the research done by the University of Oslo (section 3.4).

Conclusion I found it surprising none of the participants calculated password entropy and also did not ﬁnd it useful. This makes it so that I need to research this further. My initial thought was that having a way to calculate the strength of a password should be helpful in some way. But it seems the theory of calculating entropy does not transmit to how it is in practice.

61 5.2.6 Do you see the “forgot password” function often used in exploitation? Question (background) The option that lets you reset your password by sending a link to your email is something that is seen as a weakness. It would be easy for users to create a strong password and then just reset it frequently, but this is not recommended. For this reason, I wanted to know if the participants often saw this used when hacking accounts.

Answer They all said this is not something they use or often see other use.

Conclusion As the participants did not ﬁnd this to be a common practice. It could be that there is not as much need to discourage users to use this function. This is of course something that must be considered case by case.

5.2.7 What alternatives do you see as the future of authentication? Question (background) In chapter 4 we looked at some alternatives to passwords with different approaches being developed to try and find a way to have a password-less future. So my final question was with regards to this and finding out what the future of authentication mechanisms looks like for our participants and what their recommendation would be. Do they believe abolishing passwords completely is achievable?

Answer They all did agree that it would be nice to have a biometric way that could replace passwords but it was not something they thought would happen in at least their lifetime. There are too many complications with this and other approaches. Factors such as cost play a big role in any alternative that is taken into consideration, also with regards to biometric, all the participants mentioned that it is still easy to fail the authentication e.g when you have a sweaty finger the scanner will on many occasions not recognize your finger, the same goes when your recently out of the shower or if your finger is burned. In the case of the retina, it can be changed for instance in cases where people have epilepsy. These and other factors were looked earlier at in chapter 4. The way of the future is 2MA or MFA. All of the participants think that multifactor authentication is the best option to use going forward. Respondent A did say that if we only look at the security perspective he would choose a concept YubiKey uses.

Conclusion For now, all the other alternatives are exactly that, they are just alternatives

62 to passwords. Passwords will always be an option in case the other alternatives do not work. By so having the downside that they aid in increasing the options hackers can target which results in an increased attack surface.

5.3 Experiment

In this section, I performed some tests against a large number of leaked passwords given different criteria. For this, I have gathered over 70 million passwords, without duplicates, from the RockYou, LinkedIn, SecLists and, Have I been pwned data sets that we can use to gather some additional data which we are later going to use when creating the password policy. It is not mentioned what kind of policy was in use when the breach occurred.

RockYou RockYou is a social networking application maker that offers widgets to sites like Facebook, MySpace, and Friendster, the company bills itself as a leading provider of application-based advertising services with more than 130 million unique users using its applications monthly. In 2009 they fell victim to a data breach that reportedly exposed some "personal identiﬁcation data" for about 30 million registered users. The breach was caused by a SQL injection attack that gave the attacker access to the database in which the passwords were stored in cleartext (section 2.2.1), which means the attacker did not have to have to perform any cracking procedure. Out of the total 30 million accounts, I was able to ﬁnd around 14 million unique passwords. [65]

LinkedIn The professional social networking site LinkedIn was in 2012 also subjected to a data breach that reportedly caused the attacker to get access to 6.5 million password hashes. Though LinkedIn did not want to comment on how or what was the reason for this breach, it was found that the way LinkedIn stored their passwords was by using the SHA1 algorithm only without salting (section 2.2.5) meaning the hashes were not unique to each password. It was not reported how many of these passwords had been cracked but I was able to ﬁnd about 5 million of them. The passwords that were made available for download were in cleartext. [43]

SecLists The data set I found from SecLists is from a Github account maintained by people working within cybersecurity. These lists are meant to be used

63 for testing purposes. It is not speciﬁed from where the data sets are taken, that is to say, which data breach is used when composing the lists. It only mentioned that it is from a number of very popular lists in cooperation with their maintainers and I was able to gather 11.9 million passwords from this repo which all was in cleartext. [42]

HIBP Have I been pwned (HIBP) is a website that consists of over 613 million passwords gather from a number of data breaches like MySpace, Wattpad, and NetEase to name a few. The website offers a service so users can check if their password has been included in a data breach. The passwords used by the HIBP are generated by real users and are a mix of plaintext passwords and passwords that was hashed using different hashing algorithms such as SHA1 and bcrypt based on which data breach it was. HIBP has made their data set available for download containing all passwords that they have been able to crack themselves. These have then again been hashed using SHA1 or NTLM because some passwords contained personal information. The passwords are stored in order of how many times that password had been seen in the source data breaches. Out of the total 613 million passwords, I used the ﬁrst 70 million and was able to crack about 40 million of them by using a combination of PCFG and John the ripper cracking tools. [23] [66] [30]

By using a Python script I created we can ﬁlter the passwords given conditions we choose ourselves. In the next section, we will go through the data that was gathered. The script I used is available on my GitHub account that can be accessed using the link added as a reference. [34]

Before we take a look at the results I want to mention that some of the results do seem surprising and even suspicious in some cases, e.g with the RockYou dataset. All the tests have been run multiple times also using smaller datasets to make it easier to verify the functions used in the script are working as intended, especially the function calculating percentage. There have also been in some cases written to different functions performing the same task to see if the result is the same, e.g when checking if a string ends with a digit it can be done by using a python function isdigit() and also by using regex. The dataset from RockYou and LinkedIn were encoded using iso-8859-15 so I converted it to UFT-8, using the charset_normalizer package, to see if that affected the results and the results were the same. The RockYou dataset was downloaded from several different sources, including the one that comes with Kali Linux, and they all give the same results.

64 5.3.1 Results The most significant factor I wanted to test was the length of the password. My initial thought was to use a minimum length of 16 characters, but since the response from the survey suggested that shortening it to 12 characters would yield a non-significant difference in security while adding some ease of usability I wanted to test first how big of a difference there were of passwords that was leaked given the minimum length of 12 vs 16.

Figure 5.1: Result of password analysis basic12 vs basic16

We can see in the chart that there is a significant difference in all the data sets between the two. The results from the total of all the password sets combined show that only 1.13% of the passwords found had a minimum length of 16 in contrast to 15.36% that were found when cutting it down to 12 characters. This results in an approximate difference of 10M revealed passwords. Even though there is a measurable difference the point that the participants in the survey wanted to convey was that the difficulty in cracking the passwords is the factor that is insignificant. But as we can see in the chart the difference between the plaintext passwords found in the RockYou data set is almost the same as the difference in LinkedIn and HIBP, which are hashed. The result from HIBP is particularly interesting because they come from a list of the top 70M most found passwords and show that almost 20% of the passwords with basic12 policy were cracked. Though it should be taken into consideration that the list does not contain duplicates so the graph would look different if all the occurrences of the passwords were used. For instance, the top password was found over 24M times alone. I am interested in finding the strength of the password, so when a password is found once it does not matter how many times it is

65 used, and it is also for this reason I have removed duplicates in all the data sets.

Another signiﬁcant factor that weakened passwords was that they were predictable in that they often started with an uppercase letter and ended with a digit, so I wanted to do some tests exploring this.

Figure 5.2: Result of password analysis basic12 starting with uppercase character and ending with a digit

The results were very surprising, with the criteria of a minimum length of 12 characters, starting with an uppercase character and ending with a digit, only 0.2% of all the passwords match this compared to 15% that was found with only basic12. This was signiﬁcantly less than expected and shows that actually just adding a digit and uppercase character lowers the number of passwords to the levels of basic16. It also shows that, at least with basic12, that starting with uppercase and ending with a digit would still result in strong passwords resistant to being cracked. This is also con- ﬁrmed by the fact that it was zero passwords found in the HIBP data set with these criteria.

Because of these ﬁndings, I was interested in testing with passwords starting with uppercase or just containing an uppercase character and also testing passwords that end with a digit or just contain a digit.

66 Figure 5.3: Result of password analysis basic12 starting with uppercase character or containing an uppercase character

We can see that it is considerably fewer passwords found compared to just plain basic12. We can also see that indeed if there is the use of uppercase character it is often used at the start. So by encouraging users to just add one uppercase character would take the password to the strength level of basic16.

67 Figure 5.4: Result of password analysis basic12 ending with a digit or contain a digit

Comparing this to the previous chart showing use with uppercase we can see that using digits is signiﬁcantly more common. We can also see that the statement saying digits are more commonly found at the end of a password does show true. This indicates that encouraging users to add an uppercase character would yield more strength to the password compared to adding a digit.

Since I did tests with 3 of the 4 classes I decided to performed tests with the 4th class containing special characters to get a better overall picture. What I have deﬁned as a special character is one of the following 33 characters " !"#$%&’()*+,-./:;<=>?@[\]_‘| ". ˆ

68 Figure 5.5: Result of password analysis basic12 contain a special character

These tests gave some different results with HIBP differentiating itself significantly from the others. I ran the test several times to confirm that the results are correct. The result from HIBP is the same with or without the use of a special character in the password which means that all the passwords with a minimum length of 12 characters contain at least one special character. The fact that the use of special characters is so popular in the data set from HIBP is very unexpected, as we can see in the other data sets it is decreased significantly. This reaffirms that recommending adding an uppercase character compared to a digit or special characters is more significant to the strength.

In the next section, we will discuss the result from the survey and experiment to conclude how the new policy should look.

5.4 Discussion

With the data gathered from the survey and experiment, we can start composing a policy that is both secure and user-friendly. My initial thought was to set a character length limit to a minimum of 16, but from the results, I have chosen that lowering this to 12 characters is more sensible. The character length is a considerable factor in the difficulty when it comes to generating a password from the user’s perspective. In regards to cracking the passwords the approach did not differ with the length being 12 or 16, and the difficulty difference was not significant. Also, encouraging users to include at least one uppercase character will increase the strength to the

69 level of basic16.

In regards to adding the criteria that the user must use upper and lowercase character, digit, and special character would, in theory, result in stronger passwords but as we saw from the experiment by only adding an uppercase character would be enough to signiﬁcantly increase the strength. Because of this, including all these classes will not be a criterion but more of a guideline for the users and not used as restrictions. The users will need more guidelines than restrictions when creating passwords aiding them in learning how to create strong passwords and it is also because of this that the use of a “strength barometer” is something that must be included when implementing this policy, helping the users with visual assistance.

One thing that will be set as a restriction is the use of phrases instead of words. This was initially meant to be a guideline but since all the participants emphasized this to be of such importance for the strength of the password I see it necessary to make it a criteria. One way to enforce this is to use a dictionary check and also check that users do not duplicate the same word several times e.g “hellohellohello” which would defeat the whole purpose. Since it will not be criteria that enforce a time limit on the password should not make this restriction difﬁcult. There will also be checked if the passphrase chosen is in the list of leaked passwords from e.g https://haveibeenpwned.com/. How strictly you should enforce this should also depend on what the value of the account is, but this will be the recommended approach.

As mentioned I want to make this policy as simple as possible, I want it to contain more guidelines than restrictions. So with that in mind, this will be all the requirements. The guidelines are meant for the users to help educate them in password creation. The remaining guidelines that will be added in addition to the ones mentioned already will be to consider using the space character and to mix up where you position a digit, an uppercase letter, and special characters if chosen, and also to consider letters outside the English dictionary e.g for us in Norway æ,ø,å. The suggested policy will look like this.

The suggested policy will look like this.

70 New Policy Length 12 or more characters Character classes No restrictions Use passphrase and not password. Password must Not contain standalone dictionary word. Not be in list of revealed passwords Use uppercase, digit, or special character. Use space character. Guidelines Use letters outside of the English dictionary. Mix where you position uppercase and digits Must have password strength barometer

71 72 Chapter 6

Conclusion

Creating a password policy is not an easy task, we have seen that there has been done a lot of research in this field to try and understand why and what users find difficult about different policy criteria. In this researches, we ex- plored in-depth the relation between users and password policies to find a way in composing our own policy that will give users the ability to create strong passwords as a result of the policy being sufficiently user-friendly. We have looked at the pros and cons of different criteria and why other policies have failed in creating a user-friendly policy that produces secure passwords. Criteria such as forced password change and the requirement to include all four character classes is something that has failed to show the intended results. By contrast, the focus on creating passphrases rather than passwords is something that is of more importance and shown to be more useful.

We have also looked at alternatives to using passwords like e.g face recognition or Yubikeys. We have seen how dangerous it can be to rely solely on passwords as the main source of security. This has emphasized the importance of using a defense-in-depth strategy by e.g using MFA. Completely eradicating the use of passwords is not something that seems to be possible any time soon. The alternatives being developed are all well and good but a mix of ﬁnancial cost and hardware requirements makes it difﬁcult to completely remove passwords from the equation. Therefore, educating users in creating passwords is important, and giving them an easy- to-use policy is a great starting point. The focus should also not only be on passwords but equally or maybe more importantly on the correct implementation of the system in use. It is important to follow best practices and common guidelines. Examples of this can be from the OWASP foundation and The National Institute of Standards and Technology (NIST). Focusing on security-by-design is something that should be a priority for all system developers.

In this thesis, an alternative password policy has been suggested that will result in stronger passwords than the widely used comprehensive8. With the cooperation of the participants in the survey and the analysis done

73 on the dataset containing over 70M unique passwords have we been able to compose a solution that will yield a user-friendly password policy pro- ducing secure passwords.

I believe the resulting policy from this thesis is something that can be used by any company where user accounts contain sensitive information. This policy will aid users to create a strong password in a way that is more manageable, than especially the comprehensive8 policy, for them to follow.

74 Chapter 7

Future work

This thesis addresses the challenges behind creating a password policy. We have focused on the challenges users face with regard to different criteria used in different policies. As a result, we have created a password policy that will be easy for users to follow and at the same time being able to generate strong passwords they can remember.

The next step in this research will be to perform an examination on a large group, the more the better, of participants using this policy to gather more data on the passwords created.

75 76 Chapter 8

Terminology and Glossary

8.1 Password Strength

Password strength is the ability of your password to withstand any form of Internet hacking or password cracking. This ability depends on many factors, one of them being password characters and length. Length is the most important characteristic of password strength.

8.2 Password characters

Password characters are the combination of keyboard characters that make up the password. These must usually satisfy some password policy.

8.3 Entropy

Entropy is the measurement of password randomness. The more random your password is the longer time it would take to crack. Entropy is based on the password characters that may include lower/uppercase letters, numbers and special characters. It is calculated by log 2 of number of possible combinations.

77 Figure 8.1: How to Calculate Password Entropy

[3]

8.4 Character classes

In this sense when we are talking about character classes we mean uppercase, lowercase, digits, and special characters.

78 Bibliography

[1] Inforamtion about LastPass password manager. URL: https://www. lastpass.com/how-lastpass-works. [2] Overview of FIDO specification. URL: https : / / fidoalliance . org / overview/. [3] Image of calculating password example. URL: https://generatepasswords. org/how-to-calculate-entropy/. [4] A Allan. “Passwords Are Near the Breaking Point.” In: (2004). URL: http://www.indevis.de/dokumente/gartner_passwords_breakpoint.pdf. [5] Himanshu Arora. “Introduction to Cryptography Basic Principles.” In: (2012). URL: https://www.thegeekstuff.com/2012/07/cryptography- basics/. [6] BBC. Password guru regrets past advice. 2017. URL: https://www.bbc. com/news/technology-40875534. [7] Biometrics. URL: https://en.wikipedia.org/wiki/Biometrics. [8] Sirapat Boonkrong and Chaowalit Somboonpattanakit. “Dynamic Salt Generation and Placement forSecure Password Storing.” In: paper (2016). URL: http://www.iaeng.org/IJCS/issues_v43/issue_ 1/IJCS_43_1_04.pdf. [9] Sonia Chiasson and P.C. van Oorschot. “Quantifying the security advantage of password expiration policies.” In: (2015). URL: https : //link-springer-com.ezproxy.uio.no/article/10.1007/s10623-015-0071-9. [10] Sunny Classroom. PKI - chain of trust -why, who and how? 2018. URL: https://youtu.be/LPxeYtMDxl0. [11] Computerphile. Taming Kerberos. 2020. URL: https : / / youtu . be / qW361k3-BtU. [12] Renan Dias. “The 5 Factors of Authentication.” In: (2017). URL: https: / / medium . com / @renansdias / the - 5 - factors - of - authentication - bcb79d354c13. [13] Paul Ducklin. “Windows Picture Passwords – are they really as “easily crackable” as everyone’s saying?” In: (2013). URL: https : / / nakedsecurity.sophos.com/2013/09/09/windows-picture-passwords-are- they-really-as-easily-crackable-as-everyones-saying/. [14] Martin Paul Eve. Password. Bloomsbury, 2016.

79 [15] Dinei Florencio and Cormac Herley. “Where Do Security Poli- cies Come From?” In: microsoft.com (2016). URL: https : / / www . microsoft . com / en - us / research / wp - content / uploads / 2016 / 02 / WhereDoSecurityPoliciesComeFrom.pdf. [16] Rikke Julie Foss-Pedersen. “Endelig ny passorddialog ved UiO.” In: (2017). URL: https://www.usit.uio.no/om/organisasjon/bnt/web/ux/ blogg/2017/passorddialogen.html. [17] ALL TECHNO GEEKS. “Security Architecture of Windows.” In: (2013). URL: http://all-techno-geeks.blogspot.com/2013/06/security- architecture-of-windows.html. [18] Dan Goodin. “Why passwords have never been weaker — and crackers have never been stronger.” In: arstechnica.com (2012). URL: https://arstechnica.com/information-technology/2012/08/passwords- under-assault. [19] Google Defends Against Account Takeovers and Reduces IT Costs. Case study on Google. 2018. URL: https://www.yubico.com/wp- content/ uploads/2018/10/Yubico-Case-Study-Google.pdf. [20] Roger A Grimes. “Creating a solid password policy.” In: (2020). URL: https://www- sciencedirect- com.ezproxy.uio.no/science/article/pii/ S1361372320300774. [21] Aaron L. F. Han, Derek F. Wong, and Lidia S. “Advances of Password Cracking and Countermeasures in Computer Security.” In: Paper 1 (). URL: https://arxiv.org/pdf/1411.7803.pdf. [22] Chris Hoffman. “Keyloggers Explained: What You Need to Know.” In: (2014). URL: https : / / www . howtogeek . com / 180615 / keyloggers - explained-what-you-need-to-know. [23] Troy Hunt. Have I been Pwned. URL: https : / / haveibeenpwned . com / Passwords. [24] Tehreem Hussain et al. “Passwords and User Behavior.” In: (2017). URL: http://www.jcomputers.us/vol13/jcp1306-09.pdf. [25] Doctor Ian. Generating Eight-Character Passwords. 2002. URL: mathforum. org/library/drmath/view/52277.html. [26] Beyond Identity. “Passwordless identiy management for workforce.” In: (2020). Whitepaper from Beyond Identity. URL: https : / / www . beyondidentity.com/sites/default/ﬁles/Beyond-Identity_Passwordless- Identity-Management-For-Workforces_Datasheet.pdf. [27] Beyond Identity. “Why passwords stink.” In: (2020). Whitepaper from Beyond Identity. URL: https://www.beyondidentity.com/sites/ default / ﬁles / Beyond % 20Identity _ Why % 20Passwords % 20Stink _ Whitepaper.pdf. [28] Philip Inglesant and M. Angela Sasse. “The True Cost of Unusable Password Policies: Password Use in the Wild.” In: cl.cam.as.uk (2010). URL: https://www.cl.cam.ac.uk/~rja14/shb10/angela2.pdf.

80 [29] Philip Inglesant and M. Angela Sasse. “The True Cost of Unusable Password Policies: Password Use in the Wild.” In: (2010). URL: https: //dl-acm-org.ezproxy.uio.no/doi/pdf/10.1145/1753326.1753384. [30] John the Ripper password cracker. URL: https://www.openwall.com/john/ pro/. [31] Dan Bergh Johnsson et al. Secure by Design. Manning, 2020. [32] Rick Joyce and Gopal Gupta. “Identity Authentication Based on Keystroke Latencies.” In: (1990). URL: https : / / dl - acm - org . ezproxy. uio.no/doi/pdf/10.1145/75577.75582. [33] Pilsung Kang and Sungzoon Cho. “Keystroke dynamics-based user authentication using long and free text strings from various input devices.” In: (2015). URL: https : / / www . sciencedirect . com / science / article/abs/pii/S0020025514009062. [34] Nima Khademi. Password policy analyzer. Github repo for Password policy analyzer created for this thesis. URL: https : / / github . com / nimkha/password_policy_analysis. [35] Saranga Komanduri et al. “Of Passwords and People: Measuring the Effect of Password-Composition Policies.” In: (2011). URL: https://dl- acm-org.ezproxy.uio.no/doi/pdf/10.1145/1978942.1979321. [36] Saranga Komanduri et al. “Of Passwords and People: Measuring the Effect of Password-Composition Policies.” In: Paper 1 (). URL: https: //tsapps.nist.gov/publication/get_pdf.cfm?pub_id=907615. [37] Antonio López. “Biometrics and dynamic authentication.” In: (2015). URL: https://www.incibe-cert.es/en/blog/dynamic-authentication. [38] Microsoft. “Cached and Stored Credentials Technical Overview.” In: (2016). URL: https : / / docs . microsoft . com / en - us / previous - versions / windows/it-pro/windows-server-2012-r2-and-2012/hh994565(v=ws.11). [39] Microsoft. Trusted Platform Module Technology Overview. 2018. URL: https : / / docs . microsoft . com / en - us / windows / security / information - protection/tpm/trusted-platform-module-overview. [40] Microsoft. “Why a PIN is better than a password.” In: (2017). URL: https : / / docs . microsoft . com / en - us / windows / security / identity - protection/hello-for-business/hello-why-pin-is-better-than-password. [41] Microsoft. “Windows Authentication Concepts.” In: (2016). URL: https://docs.microsoft.com/en-us/windows-server/security/windows- authentication/windows-authentication-concepts. [42] Daniel Miessler, Jason Haddix, and g0tmi1k. SecLists the pentester’s companion. Github repo for SecLists password list collections. URL: https://github.com/danielmiessler/SecLists. [43] Elinor Mills. “LinkedIn conﬁrms passwords were ’compromised’.” In: (2012). URL: https : / / www . cnet . com / news / linkedin - conﬁrms - passwords-were-compromised/.

81 [44] Michael Mimoso. “Picture-Based Password Schemes Have Their Weaknesses.” In: (2013). URL: https://threatpost.com/picture-based- password-schemes-have-their-weaknesses/102170. [45] Jodi Myers. “Most People Have 70-80 Passwords.” In: (2020). URL: https://www.newswire.com/news/new-research-most-people-have-70- 80-passwords-21103705. [46] Luay Nakhleh. Combinatorics and Password Breaking. online course video. 2016. URL: https : / / www . coursera . org / lecture / principles - of - computing-1/combinatorics-and-password-breaking-ge171. [47] Jared Newman. Google Chrome policy exposes user passwords on purpose: Here’s how to prevent it. 2013. URL: https://www.pcworld.com/article/ 2046106/google- chrome- policy- exposes- user- passwords- on- purpose- heres-how-to-prevent-it.html. [48] Paul C.van Oorschot. Computer Security And The Internet. Page 72. Springer, 2020. URL: https://link-springer-com.ezproxy.uio.no/chapter/ 10.1007%2F978-3-030-33649-3_3. [49] OWASP. Multifactor Authentication Cheat Sheet. 2020. URL: https : / / cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_ Cheat_Sheet.html. [50] OWASP. Multifactor Authentication Cheat Sheet. URL: https : / / cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_ Cheat_Sheet.html. [51] Piotr Panasiuk et al. “A Multimodal Biometric User Identification SystemBased on Keystroke Dynamics and Mouse Movements.” In: (2017). URL: https://hal.inria.fr/hal-01637458/document. [52] Rob Picheta. “How hackable is your password?” In: (2019). URL: https://edition.cnn.com/2019/04/22/uk/most- common- passwords- scli-gbr-intl/index.html. [53] Sarath Pillai. “How are passwords stored in Linux (Understanding hashing with shadow utils).” In: (2013). URL: https://www.slashroot. in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils. [54] Harshajit Sarmah. “Understanding The 5 Factors Of Multi-Factor Authentication.” In: (2019). URL: https : / / analyticsindiamag . com / understanding-the-5-factors-of-multi-factor-authentication/. [55] Defuse Security. “Salted Password Hashing - Doing it Right.” In: crackstation.net (2019). URL: https://crackstation.net/hashing-security. htm. [56] Jérôme Segura. “Lenovo and the Superfish fiasco.” In: (2016). URL: https://blog.malwarebytes.com/security-world/2015/02/lenovo-and-the- superfish-fiasco. [57] Tobias Seitz et al. “Do Differences in Password Policies Prevent Password Reuse?” In: (2017). URL: https://dl- acm- org.ezproxy.uio. no/doi/abs/10.1145/3027063.3053100.

82 [58] RICHARD SHAY et al. “Designing Password Policies for Strength and Usability.” In: (2016). URL: https://libkey.io/libraries/269/articles/ 58777036/full-text-file?utm_source=api_181. [59] Karanbir Singh. Microsoft’s guide for going password-less. 2017. URL: https://channel9.msdn.com/Events/Ignite/Microsoft-Ignite-Orlando- 2017/BRK2078. [60] Single Sign-On (SSO). URL: https://www.cyberark.com/what-is/sso/. [61] SSL store. Explaining the Chain of Trust. URL: https://www.thesslstore. com/knowledgebase/ssl-support/explaining-the-chain-of-trust. [62] Forrest Stroud. “Windows Hello Defi Meaning.” In: (2020). URL: https://www.webopedia.com/definitions/windows-hello/. [63] Microsoft Security Team. “Building a world without passwords.” In: (2018). URL: https://www.microsoft.com/security/blog/2018/05/01/ building-a-world-without-passwords. [64] Jovi Umawing. “When three isn’t a crowd: Man-in-the-Middle (MitM) attacks explained.” In: (2018). URL: https://blog.malwarebytes. com/101/2018/07/when-three-isnt-a-crowd-man-in-the-middle-mitm- attacks-explained. [65] Jaikumar Vijayan. “RockYou hack exposes names, passwords of 30M accounts.” In: (2009). URL: https://www.computerworld.com/article/ 2522045/rockyou- hack- exposes- names-- passwords- of- 30m- accounts. html. [66] Dr. Matt Weir. Pretty Cool Fuzzy Guesser. Github repo for PCFG cracking tool. URL: https://github.com/lakiw/pcfg_cracker. [67] welivesecurity. “A short history of the computer password.” In: (2017). URL: https://www.welivesecurity.com/2017/05/04/short-history- computer-password/. [68] What is FIDO. What is the root cause of data breaches. URL: https: //fidoalliance.org/what-is-fido/. [69] Wikipedia. “Draw a secret.” In: (2019). URL: https://en.wikipedia.org/ wiki/Draw_a_Secret. [70] Wikipedia. Single sign-on. URL: https://en.wikipedia.org/wiki/Single_ sign-on. [71] Authentication World. Single Sign On. URL: https : / / archive . is / 20140315095827/http://www.authenticationworld.com/Single- Sign- On-Authentication/. [72] Shukun Yang et al. “DPPG: A Dynamic Password Policy Generation System.” In: (2018). URL: https://ieeexplore-ieee-org.ezproxy.uio.no/ stamp/stamp.arnumber=tag=1. [73] Yubico. “Going Passwordless with FIDO2 and WebAuthn.” In: (2020). Whitepaper from Yubico. URL: https : / / pages . yubico . com / passwordless-authentication.html.

83 [74] Yubico. “Introducing WebAuthn Enabling a Streamlined and More Secure User Authentication Experience.” In: (2019). Whitepaper from Yubico. URL: https://pages.yubico.com/webauthn-oﬀers-stronger-mfa. [75] Yubico. “The WebAuthn Standard: Why It Matters and How It Works.” In: (2019). Whitepaper from Yubico. URL: https : / / pages . yubico.com/why-webauthn-matters. [76] Ziming Zhao et al. “On the Security of Picture Gesture Authentica- tion.” In: (2013). URL: https://www.usenix.org/system/ﬁles/conference/ usenixsecurity13/sec13-paper_zhao.pdf.