Multi-factor secure password manager using a secret sharing

scheme

Comp4560

Bevan Lee

U5798032

Australian National University

Supervisors: Alwen Tiu, Ramesh Sankaranarayana

May 2019

Acknowledgement

I would like to thank Alwen Tiu and Ramesh Sankaranarayana for being great supervisors

and giving me much needed guidance to complete this project. I could not have done this

without you two.

I would also like to thank my friends and family for supporting me throughout this project.

ii

Contents Acknowledgement ...................................................................................................................... i

Abstract ..................................................................................................................................... iv

Glossary ..................................................................................................................................... v

1. Introduction ............................................................................................................................ 1

1.1 Proposed solution ............................................................................................................. 1

2. Literature Review................................................................................................................... 3

2.1 Related Work ................................................................................................................... 3

2.2 Shamir Secret Sharing...................................................................................................... 3

2.3 Password Managers ......................................................................................................... 5

2.4 KeePass ............................................................................................................................ 5

3. Design and Implementation ................................................................................................... 8

3.1 Shamir secret sharing ....................................................................................................... 8

3.2 Problems with Updating Shares ....................................................................................... 9

3.3 Versioning scheme ......................................................................................................... 10

3.4 Splitting a password database into shares ...................................................................... 13

4. Discussion ............................................................................................................................ 18

Lost Shares ........................................................................................................................... 18

Limit of number of shares .................................................................................................... 18

Security ................................................................................................................................ 18

Combinations of mergeable shares ...................................................................................... 18

5. Limitations ........................................................................................................................... 20

6. Future Work ......................................................................................................................... 21

Cloud storage ....................................................................................................................... 21

Mobile compatibility ............................................................................................................ 21

Storage of database in memory ............................................................................................ 21

7. Conclusion ........................................................................................................................... 22

References ................................................................................................................................ 23

Appendix 1 ............................................................................................................................... 25

Appendix 2 ............................................................................................................................... 25

Appendix 3 ............................................................................................................................... 26

Appendix 4 ............................................................................................................................... 27

iii

Table of Figures

Figure 1. Copying a password to the clipboard ......................................................................... 7

Figure 2. Shamir Sharing Flow .................................................................................................. 8

Figure 3. C# Part class ............................................................................................................... 9

Figure 4. Versioning split ........................................................................................................ 10

Figure 5. Version A of a database ............................................................................................ 11

Figure 6. Version B of a database ............................................................................................ 12

Figure 7. Merged database from version A and version B ...................................................... 13

Figure 8. History of an entry .................................................................................................... 13

Figure 9. Storing the shares ..................................................................................................... 14

Figure 10. Screenshot of KeePass with secret sharing ............................................................ 15

Figure 11. ShamirOpen Form .................................................................................................. 16

Figure 12. ShamirSaveAll Form .............................................................................................. 17

iv

Abstract Given the increasing need for users to remember strong and unique passwords for many online

services, password managers are becoming more vital to ensure that our information stays

secure. Unfortunately, password managers are highly dependent on the master password and

the password database itself.

This paper addresses these issues by splitting the database up into shares using Shamir Secret

Sharing. The database is only able to be recovered by bringing together a certain number of

shares. This enhances security significantly because a leaked master password or a lost share

will not be enough to compromise the passwords contained in the database.

This paper also introduces a versioning scheme for passwords, so the user is always able to

update their passwords without being required to have all shares present. The program is also

able to synchronize the database once all shares are brought together again.

This project is implemented in KeePass, an open source password manager for Windows.

Keywords: Cryptography, Shamir’s secret sharing, Versioning, KeePass

v

Glossary SSS – Shamir’s Secret Sharing algorithm

Share – a piece of information that can recover information only if paired with enough other

shares

(n, k) threshold scheme – a Shamir secret sharing scheme with n shares and a threshold of k

Attacker/adversary – an entity that wants to break the system in order to gain information

Password manager – A program or application that helps a user manage their passwords

Synchronization – merging of databases together in a way which does not lose information

Master password – password that is used to unlock a password database using a password

manager

Clipboard – data that is copied or cut will be stored here on an operating system so it can be

pasted with ctrl-v on Windows

Entry – refers to a database entry in a password database.

1

1. Introduction

From social to business and banking accounts, the number of services we use online is ever

increasing, requiring users to have passwords for many different services. The solution many

people take is to reuse the same password for multiple different accounts. This poses a

problem as a breach in one of these services could lead to attackers having access to all the

accounts of a user who used the same password elsewhere. The problem with using strong

and unique passwords for all your online services is that it becomes very difficult to

remember.

Password managers are a good solution to help users keep strong and unique passwords for

all their online accounts, by providing a database of passwords that are locked behind a

master password. This means that a user only needs to remember a single strong password to

maintain all their other passwords in a secure manner.

There are two main concerns with password managers. Firstly, the passwords are protected

by only a single master password. While people are encouraged to use a strong master

password, this is still the only barrier to access all the passwords in the database. Secondly,

the passwords are completely dependent on the password database. If this database is lost or

stolen, all the passwords will be gone as well.

1.1 Proposed solution Shamir’s Secret Sharing (SSS) is a technique that splits a secret into multiple shares that are

distributed to different places or people. Shares are pieces of information that do not reveal

anything about the original secret by themselves. Only when a certain number are brought

together can the original secret be recovered. To recover the initial secret, a minimum number

of shares need to be present. This paper uses KeePass, an open source password manager.

By splitting the database into shares using SSS, the password database will not be saved as a

single file, but rather across multiple shares. When splitting the database, the user will

determine how many shares they want, and the threshold or minimum number of shares

required to reconstruct the database.

The goal of this paper is to split up the password database into shares across several

locations. In doing this, the database will not be stored itself in any single location while it is

not open. Instead, a user will construct a database out of shares and distribute new shares to

save the changes that were made. This addresses the dependency on the single database file

itself. Requiring multiple shares to reconstruct the database also minimizes the risk of an

adversary finding out the master password to the database as they would require access to a

minimum threshold of shares as well.

While this method enhances the security of the database, it also introduces some usability

issues. Using this sharing scheme makes the password database require all shares or devices

to be present in order to update password entries. There is a conflict between usage patterns

here as the secret sharing aspect encourages a user not to need all devices present. On the

other hand, updating the database will require all devices to be present. This is a major

problem and needs to be solved for security and usability reasons.

2

This paper addresses this problem by adding a versioning scheme to KeePass when using

shares. Password databases should be able to be changed frequently, whether it be through

adding or updating password entries. This functionality is supported by tracking the versions

of individual shares and an algorithm to find the most recent version to give to the user.

The contributions this paper makes are as follows:

1. An implementation of Shamir’s Secret Sharing algorithm in conjunction with KeePass

to work with offline storage

2. Introduce a versioning scheme that can be used to update and synchronize password

databases without requiring all shares to be present

These will provide a basis for a secret sharing scheme on a password manager with a

versioning system in place.

3

2. Literature Review

2.1 Related Work This project is based on the work by Sanjana [1], where a lot of the implementation is based

on ideas introduced there. Despite this inspiration, this paper was completed independently

and aims to build on from integrating Shamir’s Secret Sharing (SSS) scheme to adding a

versioning scheme. SSS itself is not a new concept. It was created by Adi Shamir in 1979 [4]

and is featured in many applications.

NoKey [2] is a password manager that uses SSS to replace a master password. Instead of

using a master password to gain access to a database, NoKey lets users bring shares together

instead. NoKey is available as a web application, web extension or as an android application.

SSS is used to distribute passwords between multiple devices. NoKey can also automatically

generate secure passwords with some customisability. The different devices are kept up to

date with each other using conflict-free replicated data types (CRDT). This approach is

similar to this paper, but it takes a different approach to versioning information.

Elle. et al. [3] devised a mobile application which uses SSS to split and reconstruct individual

passwords. They use the three large cloud platforms, Google Drive, OneDrive and Dropbox

to store shares. An android application was developed to create, save and recover passwords.

The design makes it convenient for users as they do not need to carry a physical device to

reconstruct passwords from shares. Splitting individual passwords here is different to splitting

a password database as done in this paper. By only dealing with passwords individually, there

is no need for them to implement a versioning scheme on passwords.

Eggimann and Gloor [17] also created a mobile application to handle splitting of individual

passwords using SSS. Different devices are given shares that are reconstructed by secure

Bluetooth communication. A scheme to invalid(ate)? shares and modifying the threshold of

passwords was introduced. All passwords in this application are generated automatically and

randomly in order to promote safe password usage for users.

While there are existing projects that involve implementing SSS for password managers, the

focus is on the actual implementation of SSS. The problem of updating shares or databases is

a currently undeveloped area of Shamir’s Secret Sharing. Versioning the shares that result

from database splits is the focus of this paper.

2.2 Shamir Secret Sharing Given a (n, k) threshold scheme, Shamir Secret Sharing allows a secret S, to be split up into n

shares, requiring that at least k of them must be present to reconstruct the secret. The number

of shares n, and the threshold, k, are defined at the time of splitting the secret. Splitting the

secret up as such is secure as each share contains no information about the secret itself, and

the secret cannot be reconstructed with less than k shares. With this scheme, the individual

shares are not important; Any combination of k or more shares will be sufficient to

reconstruct the secret.

SSS uses a mathematical concept called polynomial interpolation. Given any k data points

(xi, yi), where no two data points are the same, there is only one polynomial of degree k-1

that goes through all these points. For example, given two points an infinite number of

polynomials of degree two can be drawn through them. If three points are given, there is a

4

single unique polynomial of degree two that passes through these points. These polynomials

are called Lagrange polynomials.

SSS uses polynomial interpolation by constructing a k-1 degree polynomial 𝑓(𝑥) for a

scheme with threshold k. Equation 1 shows the general form of a k-1 degree polynomial. The

coefficients of this polynomial a1, a2, …, an-1 are generated randomly. The secret is the

constant C.

𝑓(𝑥) = 𝑎1𝑥 + 𝑎2𝑥2 + 𝑎3𝑥3 + ⋯ + 𝑎𝑛−1𝑥𝑛−1 + 𝐶

Given a (n, k) threshold scheme, splitting a secret into shares works like so:

1. Generate a random polynomial 𝑓(𝑥) of degree k-1 where k is the threshold and the

constant C is the secret

2. Give out n random points (xi, yi) that lie on the polynomial as shares.

To reconstruct the secret:

1. Combine k “points” back to reconstruct the polynomial

2. Calculate 𝑓(0) to figure out the original secret

The general formula for calculating Lagrange basis polynomials with points (x1, y1), (x2,

y2), …, (xn, yn) is [13]:

𝑃(𝑥) = ∑ 𝑃𝑗(𝑥)

𝑛

𝑗=1

Equation 1. General Lagrange polynomial formula

The 𝑃𝑗 term can be calculated by:

𝑃𝑗(𝑥) = 𝑦𝑗 ∏𝑥 − 𝑥𝑘

𝑥𝑗 − 𝑥𝑘

𝑛

𝑘=1𝑘≠𝑗

Equation 2. Calculating Pj

Equation 3 shows the formula for reconstructing each Lagrange basis polynomial given a

threshold of 3 shares with points (x1, y1), (x2, y2), (x3, y3):

𝑃(𝑥) =(𝑥 − 𝑥2)(𝑥 − 𝑥3)

(𝑥1 − 𝑥2)(𝑥1 − 𝑥3)𝑦1 +

(𝑥 − 𝑥1)(𝑥 − 𝑥3)

(𝑥2 − 𝑥1)(𝑥2 − 𝑥3)𝑦2 +

(𝑥 − 𝑥1)(𝑥 − 𝑥3)

(𝑥3 − 𝑥1)(𝑥3 − 𝑥2)𝑦3

Equation 3. Generating the Lagrange polynomial given 3 points

5

Equation 1 shows us a way to calculate the original Lagrange polynomial. Since we are only

concerned with finding the secret 𝑓(0), we can simplify this formula. Equation 4 shows a

simplified formula that can be used to find the secret.

∑ 𝑓(𝑥𝑗) ∏𝑥𝑚

𝑥𝑚 − 𝑥𝑗

𝑘−1

𝑚=0𝑚≠𝑗

𝑘−1

𝑗=0

Equation 4. Simplified Polynomial Interpolation

The above method for implementing SSS is problematic as it can be vulnerable to an attacker

who has k shares can still find out the original secret. For each share an attacker has, they can

reduce the number of possibilities of the random coefficients and brute force the answer out.

To address this issue, during the splitting and reconstruction of shares, the results are

calculated in a finite field by taking the modulus of a large prime p that is greater than the

size of any individual share. This ensures that no information can be gained from the values

of other shares.

2.3 Password Managers Password managers are tools that help users keep track of their passwords. Typically, they are

desktop or web applications. By setting up a single master password for a password database,

a user can gain access to all the password entries in that database. Passwords can then be

copied onto the clipboard for ease of use. This makes the management of passwords a lot

easier for users as they only need to remember one strong password.

Some common features of password managers are:

- Automatic generation of secure passwords

- Storage of other important information such as bank details, social security

numbers

Popular password managers include LastPass, 1Password, KeePass and Dashlane [14].

KeePass is the only password manager out of these that is free and open source. This is one

of the main reasons that this paper uses KeePass to implement SSS and versioning. Although

the work in this paper is implemented in KeePass, in theory it should work in any password

manager. Using KeePass meant that this project would not need to also create a password

manager application.

2.4 KeePass

This project is implemented in KeePass [3], a free and open-source password manager

written in C#. In this paper, version 2.41 of KeePass was used with .NET version 4.61.

6

Although the project is focused on Windows operating systems, other operating systems can

run KeePass through Mono [10], an open source implementation of the .NET framework.

This was not tested in this paper as the Windows version was the focus.

KeePass is an offline application that has many features such as strong security and secure

storage of passwords on the Windows clipboard. From version 2 onwards, KeePass stores

password databases in .kdbx files. These database files are typically stored on the local

filesystem. The KeePass database files are encrypted using AES and Twofish. AES is

approved by the US government and used as the standard encryption method for top-secret

information [15]. Bruce Schneier, a cryptography expert, wrote a post on the security of

Twofish explaining that there were no successful attacks on it [16]. The combination of these

two encryption algorithms makes the KeePass databases very secure.

KeePass has good support for additional plugins and makes it easy to extend the functionality

of the program if anyone is interested. This paper is not implemented as a plugin due to

requirements of modifying internal KeePass operations. Even though KeePass does not

natively support any online operations, there are a multitude of plugins available that enable

things like cloud integration.

Some key features of KeePass that were used in this paper were its ability to track the history

of individual password entries and the history of the database itself. This is used in section

3.3 to allow for versioning of shares.

KeePass also lets users copy passwords to the clipboard, where they can be pasted in

password fields of websites or applications. The bottom of Figure 1 shows a protective

measure in place when copying passwords; the password will only be stored in the clipboard

for 12 seconds by default. Additionally, KeePass provides protection against keyloggers

through a method called Two-Channel Auto-Type Obfuscation [17]. It makes keyloggers

unable to see the contents pasted from the clipboard.

7

Figure 1. Copying a password to the clipboard

8

3. Design and Implementation 3.1 Shamir secret sharing A general SSS scheme was implemented in C# as the first part of this project. These secret

sharing implementation files were added to KeePass. The modifications to KeePass are all

additional features, so existing KeePass functionality is not changed at all.

The Shamir splitting works by taking the bytes of a file as an array and splitting them into

groups of 8-byte chunks. Any remainder would be padded with 0’s to make up 8 bytes. This

was done to simplify calculations that would need to be done on huge byte arrays. After

getting the 8-byte arrays, these are run through the SSS algorithm. This is depicted in Figure

2.

Figure 2. Shamir Sharing Flow

As mentioned previously, to keep the results of the resulting polynomial within a finite field,

a prime p was defined such that it would be larger than any of the 8-byte chunks. This was

done by taking the largest 8-byte number [6] and using the C# BouncyCastle library [7] to

find the next largest prime. If the prime was smaller than the maximum 8-byte number, this

would cause a loss in information when a chunk was larger than the prime. The C#

BigInteger [9] class is used to represent these byte arrays as integers.

Given a (n, k) threshold scheme, a random polynomial of degree k-1 is generated with the

database (as a BigInteger) as the constant. From this resulting polynomial, n points located on

the polynomial are generated for x=1, 2, …, n with all the final values calculated modulo p.

These n points (x1, y1), (x2, y2), …, (xn, yn) are the resulting shares for this secret. These

9

points are stored in a C# class called Part, which contains two BigIntegers, representing the x

and y values of a point.

Figure 3. C# Part class

Shamir merging takes the list of Parts for each share and combines them to reconstruct each

(x, y) pair on the original polynomial. Using equation 4 from above to calculate the original

polynomial, the value of the original secret is found. The original database is then returned in

the form of a byte array.

3.2 Problems with Updating Shares By design, SSS does not require all shares present to recover the secret that has been split

using the algorithm. This then introduces the problem of updating shares when not all the

shares are present.

If a (3, 2) threshold scheme is used, the initial split of the database into shares will mean that

all the shares will be up to date. Let the three devices that the shares are saved to be a

computer, a USB and a mobile phone. Now, if the computer and the USB are used to open

the database and the password database is updated, the user will want to save the changes

even though not all devices are present. The simple solution would be to create a new set of

shares for this version of the database and distribute them. This would require some naming

10

scheme to help the user identify which shares should be paired with each other as well as

what each set of shares represent in terms of database content.

Another problem is as follows (depicted in Figure 4):

If a (5, 3) threshold scheme is used, let S1, S2, S3, S4, S5 be the names of each of the shares.

Say the user updates the database with the combination (S1, S2, S3). Now the first three

devices will have two versions of shares each.

If shares (S3, S4, S5) are then updated separately, branching off the original database, then

we have two different updated versions of the database. When all the devices are brought

back together, there becomes an issue of how to deal with different databases in (S3 S4 S5)

v2 and (S1 S2 S3) v2.

Figure 4. Versioning split

These two databases potentially have conflicting password entries. We do not want to lose

any database entries, so we cannot simply open the latest set of shares in (S3 S4 S5) v2 as this

was updated most recently.

Ideally, there would be a way to look at the contents of each database version and merge the

entries in each database. These problems will be addressed in the following section.

3.3 Versioning scheme To allow users to save databases without all shares present, a config file was introduced.

Config files are created in each location that the user specifies to save a share to. These

config files keep track of the share number, the shares present, and the names of the shares.

The file is saved as a binary file called “config” in each share location. This change means

that the user will supply the folder that the config is located in rather than individual shares.

This allows for the user to not have to worry about versioning of shares and the contents that

each set of shares makes up. It also means that the program can interact with multiple

databases constructed from sets of shares.

The algorithm to merge shares together looks at all unique combinations of shares by the

user. The shares that can be combined are reconstructed, then the KeePass Synchronization

11

[5] operation is run on all these databases to give the user an updated version of the

databases. If multiple databases have entries in common, KeePass will check the internal

timestamps of them and keep the most recent one. All other entries will be combined into the

resulting database. In the case that a user would want a previous version of a password entry,

KeePass stores a changelog of each entry where a user can revert to a previous version of that

entry. Due to these factors, this synchronization ensures that the merging of databases results

in the most up-to-date entries without losing any data.

An example of synchronization between two databases is shown below:

Figure 5 shows two sample entries that KeePass automatically generates in a blank password

database. An additional entry is added titled new entry2. Figure 6 edits the title of the second

sample entry to edited entry. A unique entry is also added titled new entry.

Figure 5. Version A of a database

12

Figure 6. Version B of a database

After these two databases are merged, the result is shown in Figure 7. Both the uniquely

added entries are present in the database. Since the second sample entry is a common entry in

both version A and version B, KeePass will look at the timestamp on both entries. The edited

entry will have a more recent timestamp, so KeePass decides to keep the edited entry.

13

Figure 7. Merged database from version A and version B

In the case that an updated entry is not desired, and a user wants to revert to a previous

version of an entry, KeePass supports this. The user simply needs to Edit/View the entry and

go to the history tab on the popup menu. This will display the history of changes that has

happened to this entry. In Figure 8, we can see that the older version of the entry with the title

Sample Entry #2 is present.

Figure 8. History of an entry

3.4 Splitting a password database into shares To split a database into shares, the database itself is first saved into the user’s temporary

directory determined by the .NET framework [8]. The byte array of the database is then split

into Part objects. The prime p was set as the smallest 65-bit prime number as mentioned in

section 3.1. The BigInteger partitions of the Part objects are calculated in the finite field of p.

While the partitions of the actual database byte array are guaranteed to be within the 8-byte

range, the BigInteger partitions potentially grow past an 8-byte value as p is greater than 8-

bytes.

Instead of using 8-bytes to store the intermediate BigInteger values, 16-byte arrays are used

to store them. In addition to this change, the BigInteger values were changed to always be

positive. The C# BigInteger class determines BigInteger values from arrays in a little-endian

way and classifying a leading 0 as the number being positive. This made the signage of a lot

of the 8-byte values incorrect when padding to 16-bytes. Overall, this results in the share files

being twice the size of the original secret. This is shown below:

14

Figure 9. Storing the shares

When shares are brought together to reconstruct the database, the opposite of the above

happens. The bytes are converted back into signed BigIntegers and then passed through the

SSS algorithm.

Figure 10 shows the adjustments made to the KeePass application. Three additional buttons

are added: ShamirOpen, ShamirQuickSave and ShamirSaveAll.

15

Figure 10. Screenshot of KeePass with secret sharing

ShamirOpen lets a user choose the shares to combine along with the threshold for the given

shares. Currently, the number of shares that can be opened is limited to a maximum of five.

While the functionality of the SSS scheme here supports any number of shares, this was done

to help with testing. A simple set of changes would allow users to open databases from more

shares.

16

Figure 11. ShamirOpen Form

For saving files, there are two processes that a user will go through. One is splitting a

KeePass database file from scratch. The other is saving a database that has been opened by

some number of shares.

From a previously unsplit database, The ShamirSaveAll button prompts the user to choose a

(n, k) threshold scheme and n locations to save the shares to as shown in Figure 11. This will

generate a config and share file in each of these folders.

ShamirSaveAll also acts as a “Save All” function in the case of all shares being present given

a password database that has been split into shares. KeePass saves the history of a password

database, so if all the shares are present, there is no need to keep any of the old shares. In this

case, ShamirSaveAll will overwrite the config file and add a new share file in each location.

17

Figure 12. ShamirSaveAll Form

ShamirQuickSave is similar to ShamirSaveAll except it appends to the config file rather than

overwriting it. Instead of giving the user a form to fill out location details, the shares present

are tracked from the opening of the database through ShamirOpen. This was done to make it

easier for users to save a database as their share locations should be present if they were

opened using them. In the case that a user tries to ShamirQuickSave without opening the

database from shares, an error message will pop up. In these scenarios, a user can simply use

the ShamirSaveAll button instead.

Both saving operations generate completely new polynomials each time they are called due to

the database being different when it is updated.

18

4. Discussion Lost Shares Shares that are lost are a negligible issue if the number of sets of shares lost is less than the

set threshold. This means that an attacker would need to have k sets of lost shares in order to

reconstruct the database.

For a user, a lost share will not cause any issues if there are at least k other shares available.

The best course of action if a user loses a set of shares is to synchronize their shares as soon

as possible. This will overwrite the config files and remove mention of the previous shares.

Although this program does not remove unused shares, the user can delete these to ensure

that any lost shares are completely useless.

Limit of number of shares In theory, SSS should support any variation of n and k in a (n, k) threshold scheme. In this

paper, the solution only allows up to 9 shares to be used for any split of the database. The

naming format in the config files uses a character to determine a share number, which

supports the digits 1 through 9. While this was considered, there was no reasonable situation

perceived in which 9 shares would be too little. In general, SSS may be used across many

people or locations where a higher threshold would increase the security of the secret. For

this project, the primary use case was considered to be a single user. Between phones, USB’s

and computers as the currently supported storage systems, a user would be unlikely to use 9

or more shares between these devices. In order to do so, users will likely have to double up

by having more than one share per device, which does not improve security simply having

more shares. Therefore, it is deemed appropriate to limit the user to a maximum of 9 shares.

If cloud or mobile integration is completed, this may be reconsidered.

Security The Shamir secret sharing scheme is mathematically proven to be secure, so following the

procedure makes this element of the paper satisfiable in terms of security.

Internal operations made in this paper are made by following the KeePass implementation for

most of the added functionality. In order to save, open and synchronize databases, most

operations are overloaded KeePass functions that are suited for SSS applications. By

following KeePass operations, most of the security that KeePass has in place is also applied

to the additional features that were added in this paper.

The biggest issue lies with opening and saving databases with the Shamir operations. When

shares are combined to reconstruct a password database, the database itself is stored on the filesystem in the computers temp location. Currently the database file needs to exist when

shares are brought together and when the database is saved. Even though the database file is

deleted after the program is closed, it will still leave a trace behind where it can be found.

One way to address this issue is by saving the database to memory. This will make it a lot

more difficult for an attacker to obtain the database even when the KeePass database is open.

Combinations of mergeable shares In order to determine the possible combinations of shares that can be opened given the shares

by the user, a maximum of 𝑛 𝑐ℎ𝑜𝑜𝑠𝑒 𝑘 number of combinations will need to be calculated

and checked against the given shares to determine what databases should be merged.

19

𝑛 𝑐ℎ𝑜𝑜𝑠𝑒 𝑘 = 𝑛!

𝑘! (𝑛 − 𝑘)!

Equation 5.

The number of combinations grows a lot when the number of shares increases. Similarly to

the previous section, the number of shares is both limited and unlikely to be large in

reasonable circumstances, so this operation will not be problematic in terms of size.

20

5. Limitations The config and share files are not designed in a way that enable users to freely interact with

them. In the config files, paths to the shares are absolute paths. By moving shares or folders

that contain these shares around, the paths in the config files will be incorrect and cause the

reconstruction of these shares to fail. While users can redistribute these files into new

locations by splitting the database again, this will not be able to preserve previous config or

share information.

It is not very clear to users that the ShamirSave operation uses the devices present in the

ShamirOpen operation to choose where to save the database shares. Due to this, users will

need to Synchronize the database first before doing ShamirSave. It would be better to come

up with a more intuitive system, perhaps by renaming the button.

The Synchronize operation that is provided by KeePass works under most situations, except it

relies on the master passwords of the databases to be the same. This means that changing the

master password of a database while not all devices are present will break the merging

functionality between different database versions. It is therefore suggested that users only

change the master password of their database when all shares are present.

The splitting and merging operations were tested on larger KeePass database files of about

280kb. Given enough time, all of the functionality still works, but it generally freezes

KeePass while it does the calculations. While it is unlikely that a typical password database

would be that large, this is something that should be avoided. This could be improved by

making the SSS algorithms more efficient or advising users not to use databases that are too

large.

The implementation was set as (5, 3) threshold scheme. This was left in the final product as it

was the only one tested properly. Different combinations should be possible by simply

changing some settings in the existing code.

21

6. Future Work

Cloud storage Cloud is an area that is becoming increasingly common due to the convenience it brings by

being always available wherever you are. Integration with cloud services to store shares

would improve usability for users. Increasing the number of shares required by adding cloud

shares would also improve the security of the passwords.

Mobile compatibility Like storing these shares in the cloud, integrating this to a mobile app would also make it

more convenient for users to use this multi-factor KeePass solution on their phones as well.

While this iteration of KeePass supports phones as simple storage devices, developing the

KeePass functionality with either an existing KeePass app or a new one would allow users to

split and reconstruct database shares on mobile. Communication with mobile devices would

need to be managed in a secure way and avenues such as Bluetooth would be considered.

Storage of database in memory As mentioned in the Limitations section, this paper uses KeePass to save and open databases

in a temporary directory on the filesystem. By storing these database files in memory instead,

this makes it much more difficult for an attacker to track down. Sanjana [1] has shown a way

to do this using Memory-mapped files [11].

22

7. Conclusion Passwords are becoming more and more important in this online heavy world and password

managers are one of the best ways to securely organise key information about online

accounts.

This paper firstly includes an implementation of Shamir secret sharing in C#. This algorithm

is then added on top of KeePass, an open source password manager, to enable multi-factor

authentication to improve security and redundancy. Finally, a versioning scheme is

introduced to allow updates to any combination of shares without requiring all shares to be

present. This implementation forms the basis for a password manager with a multi-factor

authentication scheme using secrets which can be extended.

23

References [1] Sanjana, J. (2017). Two-factor secure password manager. Nanyang Technological

University.

[2] Zinggeler, F. (2017). NoKey - A Distributed Password Manager. ETH Z ̈urich.

[3] Elle, M., Mjølsnes, S. and Olimid, R. (2018). Distributed Personal Password Repository

using Secret Sharing. Norwegian University of Science and Technology.

[4] Shamir, A. (1979). How to share a secret. ACM, pp.612-613.

[5] Reichl, D. (2019). Synchronization - KeePass. [online] Keepass.info. Available at:

https://keepass.info/help/v2/sync.html [Accessed 3 May 2019].

[6] Poley, J. (2009). Magic Numbers: Integers. [online] Msdn.microsoft.com. Available at:

https://msdn.microsoft.com/en-us/library/ee621251.aspx [Accessed 8 Feb. 2019].

[7] Bouncycastle.org. (2013). The Legion of the Bouncy Castle C# Cryptography APIs.

[online] Available at: https://www.bouncycastle.org/csharp/ [Accessed 24 Sep. 2018].

[8] Docs.microsoft.com. (n.d.). Path.GetTempPath Method [online] Available at:

https://docs.microsoft.com/en-us/dotnet/api/system.io.path.gettemppath?view=netframework-

4.6 [Accessed 31 Apr. 2019].

[9] Docs.microsoft.com. (n.d.). BigInteger Struct. [online] Available at:

https://docs.microsoft.com/en-us/dotnet/api/system.numerics.biginteger?view=netframework-

4.6 [Accessed 8 May 2019].

[10] Mono-project.com. (2019). Home | Mono. [online] Available at: https://www.mono-

project.com/ [Accessed 20 May 2019].

[11] Docs.microsoft.com. (2017). Memory-Mapped Files. [online] Available at:

https://docs.microsoft.com/en-us/dotnet/standard/io/memory-mapped-files [Accessed 19 May

2019].

[12] Archer, B. and Weisstein, E. (n.d.). Lagrange Interpolating Polynomial -- from Wolfram

MathWorld. [online] Mathworld.wolfram.com. Available at:

http://mathworld.wolfram.com/LagrangeInterpolatingPolynomial.html [Accessed 14 May

2019].

[13] Rafaloff, E. (2018). Shamir's Secret Sharing Scheme. [online] Ericrafaloff.com.

Available at: https://ericrafaloff.com/shamirs-secret-sharing-scheme/ [Accessed 20 May

2019].

[14] Knafo, J. (2019). 2019 Most Popular Password Managers Compared. [online] The

Devolutions Blog. Available at: https://blog.devolutions.net/2019/01/updated-2019-most-

popular-password-managers-compared [Accessed 22 May 2019].

[15] Csrc.nist.gov. (2019). Block Cipher Techniques. [online] Available at:

https://csrc.nist.gov/projects/block-cipher-techniques [Accessed 22 May 2019].

24

[16] Schneier, B. (2005). Twofish Cryptanalysis Rumors. [online] Schneier.com. Available at:

https://www.schneier.com/blog/archives/2005/11/twofish_cryptan.html [Accessed 22 May

2019].

[17] Reichl, D. (2019). Two-Channel Auto-Type Obfuscation - KeePass. [online]

Keepass.info. Available at: https://keepass.info/help/v2/autotype_obfuscation.html [Accessed

31 May 2019].

[18] Eggimann, M. and Gloor, C. (2016). Convenient Password Manager. ETH Zürich.

25

Appendix 1 Final Project Description:

Appendix 2 Details of study contract:

26

Appendix 3 Description of software/artefacts produced

This project was based on the open source KeePass Project.

Files that were added:

Keepass/KeepassLib/Shamir/* – General Shamir secret sharing algorithm

Keepass/KeePass/Forms/ShamirOpenForm.cs

Keepass/KeePass/Forms/ShamirSaveForm.cs

Keepass/KeePass/Forms/ShamirSynchronizeForm.cs

Forms that the user interacted with to choose shares locations and the (n, k) threshold scheme

Files that were edited

Keepass/KeePass/Forms/MainForm.cs

Keepass/KeePass/Forms/MainForm_Functions.cs

Keepass/KeePass/DataExchange/ImportUtil.cs

27

Appendix 4