Digital Security Analysis of Local Password Managers

University of Derby
School of Computing & Mathematics
A project completed as part of the requirements for the
BSc (Hons) Computer Forensics and Security
Entitled
Digital Security Analysis of Local Password Managers
By
Joshua Gray
J.gray5@unimail.derby.ac.uk
Joshgray614@gmail.com
In the years 2011 – 2015
Page | 0
Abstract
Passwords offer a form of protection and identification for users online. The most used
methods of remembering passwords is to make them memorable to the user, unfortunately
these methods are reducing the security that they provide. Password managers have been
developed to counteract the human factor in password security, they achieve this by offering
features that create, manage and specifically protect all data they are entrusted with.
There are currently three different types of password managers; cloud, browser and local
based. Each password manager offer different features and levels of security. Previous studies
have highlighted areas in which password managers could be exploited. This could be
achieved through either attacking the manager directly or manipulating features to work in the
attackers favour.
Previous studies have concentrated in cloud and browser password managers and have
highlighted areas in which they could be exploited.... However, local password managers have
been under-evaluated. This project examines three different local password managers;
KeePass, Password Safe and RoboForm (Desktop version) from a user's perspective. This
examination was achieved through a combination of software testing and computer forensic
investigative techniques. It assessed the potential risks of residual data which, if found, could
lead to the loss of data and security issues for the user.
This examination was achieved through a combination of software testing and computer
forensic investigative techniques. Results from the experiments indicate worrying factors that
had appeared to be previously overlooked which if discovered by an attacker could then be
exploited. KeePass was the password manager with most security risks. For example it
showed that KeePass stored unencrypted data within the page file of the system and the
printing feature design left data unprotected in an unencrypted format. The tests done on the
selected password managers as a part of this project, uncover an area of security risk that
shows the lack of robust security. The issues highlighted as part of this project have shown
that even software designed for security may in fact not be a full security guarantee.
Page | 1
Acknowledgements
I would like to express my gratitude to both my friends and family for keeping me motivated
during the course of this project. I would especially like to thank both Matthew Tully and
Benjamin Jones for keeping my spirits high.
I would also like to thank Dr Virginia N. L. Franqueira who made this project possible,
through both guidance and advice which proved very valuable.
Page | 2
Table of contents
Abstract ................................................................................................................................................... 1
Acknowledgements ................................................................................................................................. 2
Table of contents ..................................................................................................................................... 3
Table of Figures ...................................................................................................................................... 7
Table of tables ......................................................................................................................................... 8
Chapter 1 - Introduction and Project Aims ............................................................................................. 9
1.1 Introduction................................................................................................................................... 9
1.2 Aim and Objectives: .................................................................................................................... 10
Chapter 2 - Literature Review ............................................................................................................... 11
2.1 Introduction................................................................................................................................. 11
2.3 Password Protection ................................................................................................................... 11
2.3 Password managers .................................................................................................................... 12
2.3.1 The need for password managers ........................................................................................ 12
2.3.2 Selected Password Managers .............................................................................................. 14
2.3.3 Common Password Manager Features ................................................................................ 14
2.3.4 Password Manager Security ................................................................................................. 15
2.4 - Cloud-based .............................................................................................................................. 16
2.4.1 - Password encryption .......................................................................................................... 17
2.4.2 - Cloud-Based Features ........................................................................................................ 17
2.4.3 - Security Issues .................................................................................................................... 18
2.4.4 - Decrypting LastPass Master Password............................................................................... 19
2.4.5 - JavaScript Rootkits ............................................................................................................. 20
2.4.6 - Bookmarklet Attacks .......................................................................................................... 21
2.5 - Browser based........................................................................................................................... 22
2.5.1 Google Chrome .................................................................................................................... 23
2.5.2 Mozilla Firefox ...................................................................................................................... 24
2.5.3 Microsoft Internet Explorer ................................................................................................. 25
2.5.4 Safari..................................................................................................................................... 26
2.5.5 Opera .................................................................................................................................... 26
2.5.6 Browser Summary ................................................................................................................ 27
2.6 - Locally based ............................................................................................................................. 27
2.6.1 Features ................................................................................................................................ 27
2.6.2 Attack Restrictions ............................................................................................................... 28
Page | 3
2.6.3 KeePass 2x version 2.28 ....................................................................................................... 28
2.6.4 - Password Safe version 3.35.1............................................................................................. 31
2.6.4.1 ............................................................................................................................................ 32
2.6.5 - RoboForm (Desktop-Based trial, version 7.9.12) ............................................................... 32
2.7 Digital Forensic Investigation ...................................................................................................... 34
2.7.1 Introduction.......................................................................................................................... 34
2.7.2 ACPO Principles .................................................................................................................... 34
2.7.3 - ISO 27037 ........................................................................................................................... 35
2.7.4 - Digital Forensic Frameworks .............................................................................................. 36
2.7.5 - Digital Forensic Framework Examination .......................................................................... 37
Chapter 2.8 - Forensic Tools .............................................................................................................. 38
2.8.1 Encase and FTK ..................................................................................................................... 39
2.8.2 Freeware tools...................................................................................................................... 39
2.9 - Literature Review Summary ...................................................................................................... 42
Chapter 3 - Methodology ...................................................................................................................... 44
3.1 Introduction................................................................................................................................. 44
3.2 Software Testing ......................................................................................................................... 44
3.2.1 - Software testing methods .................................................................................................. 46
3.3 - Test case Anatomy .................................................................................................................... 46
3.4 Digital Forensic Framework........................................................................................................ 47
3.4.1 Analysis of existing models .................................................................................................. 47
3.4.1.3 Common Forensic Process Model ..................................................................................... 55
Chapter 3.4 - Chosen Framework ..................................................................................................... 61
Chapter 4 - Experiment Design ............................................................................................................. 63
4.1 Introduction................................................................................................................................. 63
4.2 Scenario Design ........................................................................................................................... 63
4.2.1 Experiment environment ......................................................................................................... 63
4.3 Experiment design ....................................................................................................................... 64
4.2.1 KeePass 2.x .......................................................................................................................... 64
4.2.2 Password Safe ...................................................................................................................... 68
4.4 Limitations .................................................................................................................................. 72
Chapter 5 - Analysis and Results .......................................................................................................... 73
5.1 Introduction................................................................................................................................. 73
5.2 KeePass 2.X ................................................................................................................................ 73
Page | 4
5.2.1 Scenario 1 ............................................................................................................................. 73
5.2.2 Scenario 2 ............................................................................................................................. 74
5.2.3 Scenario 3 ............................................................................................................................. 75
5.2.4 Scenario 4 ............................................................................................................................. 75
5.2.5 Scenario 5 ............................................................................................................................. 75
5.2.6 Scenario 6 ............................................................................................................................. 76
5.2.7 Scenario 7 ............................................................................................................................. 77
5.2.8 Scenario 7.2 .......................................................................................................................... 77
5.2.9 Scenario 8 ............................................................................................................................. 78
5.2 Password Safe ............................................................................................................................. 78
5.2.1 Scenario 1 ............................................................................................................................. 78
5.2.2 Scenario 2 ............................................................................................................................. 79
5.2.3 Scenario 3 ............................................................................................................................. 79
5.2.4 Scenario 3.2 .......................................................................................................................... 79
5.2.5 Scenario 4 ............................................................................................................................. 80
5.3 RoboForm ................................................................................................................................... 80
5.3.1 Scenario 1 ............................................................................................................................. 80
5.3.2 Scenario 2 ............................................................................................................................. 81
5.3.3 Scenario 3 ............................................................................................................................. 81
5.3.4 Scenario 4 ............................................................................................................................. 82
5.3.5 Scenario 5 ............................................................................................................................. 82
5.4 - Discussion.................................................................................................................................. 82
5.4.1 Introduction.......................................................................................................................... 82
5.4.2 KeePass................................................................................................................................. 82
5.4.3 Password Safe ...................................................................................................................... 84
5.4.4 RoboForm ............................................................................................................................. 85
Chapter 6 - Conclusion and Recommendations .................................................................................... 87
6.1 Introduction................................................................................................................................. 87
6.2 Aims and Objectives .................................................................................................................... 87
6.3 Improvements and Recommendations ....................................................................................... 88
6.3.1 Improvements ...................................................................................................................... 88
6.2.2 Recommendations ............................................................................................................... 88
Chapter 7 - Personal Reflection............................................................................................................. 90
8. References ......................................................................................................................................... 91
Page | 5
Appendix ............................................................................................................................................... 99
Appendix A ........................................................................................................................................ 99
Appendix B LastPass ...................................................................................................................... 106
B.1 ............................................................................................................................................... 106
B.2................................................................................................................................................ 111
B.3................................................................................................................................................ 111
B.4................................................................................................................................................ 111
B.5................................................................................................................................................ 112
B.6 ............................................................................................................................................... 116
B.7................................................................................................................................................ 116
B.7.2............................................................................................................................................. 119
B.8................................................................................................................................................ 121
Appendix C Password Safe .............................................................................................................. 121
C.1................................................................................................................................................ 121
C.2................................................................................................................................................ 121
C.3................................................................................................................................................ 122
C.3.2............................................................................................................................................. 125
C.4................................................................................................................................................ 127
Appendix D RoboForm .................................................................................................................... 128
D.1 ............................................................................................................................................... 128
D.2 ............................................................................................................................................... 132
D.3 ............................................................................................................................................... 132
D.4 ............................................................................................................................................... 135
D.5 ............................................................................................................................................... 135
Page | 6
Table of Figures
Figure 1 ................................................................................................................................................. 46
Figure 2 ................................................................................................................................................. 48
Figure 3 ................................................................................................................................................. 49
Figure 4 ................................................................................................................................................. 49
Figure 5 ................................................................................................................................................. 50
Figure 6 ................................................................................................................................................. 51
Figure 7 ................................................................................................................................................. 54
Figure 8. ................................................................................................................................................ 55
Figure 9. ................................................................................................................................................ 56
Figure 10 ............................................................................................................................................... 57
Figure 11. .............................................................................................................................................. 59
Figure 12 ............................................................................................................................................... 60
Page | 7
Table of tables
Table 1................................................................................................................................................... 14
Table 2....................................................................................................... Error! Bookmark not defined.
Table 3....................................................................................................... Error! Bookmark not defined.
Table 4................................................................................................................................................... 44
Table 5....................................................................................................... Error! Bookmark not defined.
Table 6....................................................................................................... Error! Bookmark not defined.
Table 7....................................................................................................... Error! Bookmark not defined.
Table 8....................................................................................................... Error! Bookmark not defined.
Table 9....................................................................................................... Error! Bookmark not defined.
Table 10..................................................................................................... Error! Bookmark not defined.
Table 11..................................................................................................... Error! Bookmark not defined.
Table 12..................................................................................................... Error! Bookmark not defined.
Table 13..................................................................................................... Error! Bookmark not defined.
Table 14..................................................................................................... Error! Bookmark not defined.
Table 15..................................................................................................... Error! Bookmark not defined.
Table 16..................................................................................................... Error! Bookmark not defined.
Table 17..................................................................................................... Error! Bookmark not defined.
Table 18..................................................................................................... Error! Bookmark not defined.
Table 19..................................................................................................... Error! Bookmark not defined.
Table 20..................................................................................................... Error! Bookmark not defined.
Table 21..................................................................................................... Error! Bookmark not defined.
Table 22..................................................................................................... Error! Bookmark not defined.
Table 23..................................................................................................... Error! Bookmark not defined.
Page | 8
Chapter 1 - Introduction and Project Aims
1.1 Introduction
Passwords are an essential element for those with an internet presence. Passwords are relied
on to prove identities, secure information and prevent people from taking information which
does not belong to them. Almost everything digital containing sensitive information requires a
password of some kind, in order to permit users to gain access to that information.
Due to the sensitivity of the information passwords protect, and the possibility of misuse by
others, users are expected to have long complex passwords in order to retain a high level of
security. However, it is generally accepted that most passwords are chosen because they are
memorable words, and are found in the dictionary (Kumar, 2011). In one case study of 14,000
UNIX passwords, almost 25% were in the dictionary, meaning that those passwords would be
simple to decipher or guess (Kumar, 2011).
The ideal password should be eight characters long and must contain at least two non-letter
characters, and changed periodically to retain a level of security (Kumar, 2011). However,
this recommendation is often ignored, because a longer and more complex password is more
difficult for users to make memorable. This results in techniques such as brute forcing and
dictionary attacks to bypass or guess user passwords. This then nullifies the security that the
password is intended to present (Cole, 2015).
Requirements for passwords are increasing and therefore passwords managers are becoming a
necessity. For a user with 30 password accounts, the problem becomes less about
remembering each password but rather, remembering which password belongs to which
account (Florencio and Herley, 2007). Password managers assist users in creating a system
whereby only one password is required to access all of the other passwords (Florencio and
Herley, 2007). According to a research study conducted by Microsoft, the average user has
6.5 passwords; each is shared over 3.9 different websites. Also the average user types eight
passwords per day and only uses lower case letters in their passwords (i.e. no upper case,
digits or special characters). The same research showed that on average at least 1.5% of
Yahoo users forget their passwords each month (Florencio and Herley, 2007).
Password Managers provide a solution for companies and users that protect and manages their
passwords in ways which would be difficult to do achieve by any other method. Password
Page | 9
Managers operate by securing the passwords entered, by encrypting them, using a number of
techniques. They also help users create stronger passwords to limit the chances of decryption.
This means that once a user has selected a website they wish to make an account with, they
have the option of gaining assistance in creating a new password (Perrin, 2010).
Password managers might be a solution to preventing trust in weak passwords, but studies
indicate that password managers have limitations to the security provided. This project will
explore, in detail whether current local password managers are sufficiently secure or if they
present their own security risks for their users.
1.2 Aim and Objectives:
The aim of this project is to test local password managers and their features, to determine if
any residual data can be acquired by attackers and pose a security risk to users.
In order to achieve this aim, the project has a number of objectives:
1.
Research how different types of password managers protect the data they are entrusted with.
2.
Research past incidents and vulnerabilities that challenge the security of password managers.
3.
Design test cases to evaluate features of three local password managers from a users’
perspective.
4.
Conduct a forensic examination on main features provided to users, in order to evaluate
what, if any, residual data is left on the computer.
5.
Evaluate the security implications of residual data uncovered by the forensic examination.
Page | 10
Chapter 2 - Literature Review
2.1 Introduction
Password managers are a tool used to secure and protect passwords. In order to understand
the potential risks associated with local password managers, it is important to review how
other reports and experiments have highlighted areas in which password managers are shown
to need further development on their capability, to protect user data. Each type of password
manager has its unique way of storing, securing and managing their data. However, as past
research has identified, there are still attacks and weaknesses that password managers are
susceptible to. Looking at how past security issues have been used against password managers
will demonstrate why security remains a concern to be addressed.
A select number of password managers, will be described and discussed, with examples of
security flaws that have the potential to make them redundant. The objective of this project is
to discover if the selected password manager features, function as intended. If the software
does not perform as expected, it will expose potential security risks that could be exploited.
By taking a forensic approach the investigation will clearly show whether data entrusted to
each of the password managers is at risk.
2.3 Password Protection
Passwords are used to protect online data and to confirm the identity of the user accessing the
online data. However, having a password does not guarantee the security of the data because
there are vast amounts of software capable of bypassing security.
The password bypassing software is readily available and threatens password security and
potentially exposing data to abuse. Password security is a high risk issue and IT professionals
increasingly recommend creating more complex and secure passwords, by combining
characters, letters and numbers (United States Computer Emergency Readiness Team, 2012).
Passwords increasingly have to be replaced or updated, each time containing a certain level of
complexity and abide by established standards which are now commonly required.
A significant issue for any security network is the human element.
Having a complex
password can often prove challenging for some users to remember and keep track of. This is
because each password has to have a unique combination of letters, numbers and characters,
Page | 11
which cannot be replicated across multiple websites and accounts. If the same password has
been used multiple times it can weaken the security of that password and nullify the original
aim of securing data (Gasti and Rasmussen, 2012).
The challenge of creating secure passwords, result in users re using passwords for all of their
online profiles, setting simple passwords in order to remember them. Also, people often have
the habit of writing their passwords down, which immediately lowers the security of the
information that the passwords are protecting (National Institute of Standards and
Technology, 2009).
To help the average user better manage their passwords, password managers were created. At
its core the password manager was designed to store user password and usernames. By storing
and managing the user passwords, password managers eliminate the need for the user to
remember a long series of passwords. Along with the added benefit of storing passwords,
password managers contain other features to help users create, manage and keep safe their
online data (Li et al., 2014).
2.3 Password managers
Authentication credentials are increasingly being implemented into websites, requiring users
to produce unique passwords with a level of complexity. Password managers help users better
manage their passwords across multiple websites. There are many different variations of
password managers, some of which are incorporated into different browsers (Silver et al.,
2014). There are also third party password managers and cloud-based password managers,
these types include features which help users keep their data secure (Silver et al., 2014).
Password managers are becoming increasingly popular, as the number of passwords the
average user is expected to remember increases. Password managers act as a ‘vault’ securing
all of the passwords entered into it (The SANS Institute, 2013). The vault can then only be
accessed by entering a ‘master password’, the master password acts as the key to unlocking
the vault. The idea of a master password is ideal for users who have multiple passwords
across many devices because it then acts as the only password the user needs to remember.
2.3.1 The need for password managers
Password managers increase the level of security by protecting their contents behind various
levels of encryption and defences; these have been put in place to make sure that the only user
Page | 12
who can gain access to its contents is the original user. Each password manager uses their
own version of encryption method which is determined on the specific software. The master
password is in theory the only method of decrypting the data stored within the vault. This
means that if the data stored in the database was stolen, it could not be read without the master
password, even if it is trying to be read by the company who designed the software (Zhao,
Yue and Sun, 2013). By using this type of security, users know that their data is safe and not
easily accessible to anyone other than themselves.
Along with storing and securing passwords, password managers have the feature of
automatically filling data into the specific fields to allow a user access to their online accounts
(Zhao, Yue and Sun, 2013). This is accomplished by the password manager storing all the
relevant data associated with a particular login. For example if a user were to choose to save
their Facebook account password they will also be saving their username and the web address.
This results in the user gaining instant access to their account without the need for logging in
manually.
By also saving this data, users are less susceptible to typical attacks like phishing and key
logging (Gasti and Rasmussen, 2012). This is because the user is not manually typing on their
computer thus; no data will be gained by the malicious user. Along with the added benefit of
not having data stolen, users can be assured that if they were redirected to a malicious
website, the password manager would not automatically log them on. This is because the web
address would not match up to the saved file, thus adding another layer of protection for the
user (Gasti and Rasmussen, 2012).
Synchronised passwords are a feature offered by cloud based password managers. Cloud
based password managers such as LastPass, offer their users an opportunity to synch their
data across all of their devices which have the appropriate additions (Li et al., 2014). For
example if a user were to download the LastPass application onto their mobile phone, they
would also be able to use the passwords they previously installed on their computers on their
mobile phones too. This feature means that there is a less likely chance of passwords being
stolen by a user entering it on another device.
Encryption is an important feature for password managers to effectively protect the data they
store. However, simply encrypting a password may not guarantee the data security, if that
Page | 13
password is easily guessable or insufficiently complex. Depending on the manager, it may
offer the feature of helping a user create stronger, more complex passwords. This feature
helps users create stronger passwords to decrease the likelihood of it being stolen (The SANS
Institute, 2013).
2.3.2 Selected Password Managers
Below is a table outlining the password managers to be analysed based on their security,
known security threats and the repercussions of these flaws. These password managers have
been selected based on their popularity and performance. The cloud based password managers
are considered among the top in their field (10 TopTen Reviews, 2015) but as this report will
demonstrate, there have been issues in the past which has cast doubt on their ability to safely
secure their users’ data. The browser based password managers have been chosen based on
their popularity and they are considered to be the top browsers used in 2014 and for the
foreseeable future (Bloomfield, 2015).
The local password managers shown below have been selected based on their popularity and
security. Among the password managers chosen are KeePass and Password Safe, these
password managers are both open source which raises the interesting question of their
security. RoboForm is not open source however; it does have a local version that is both
popular and free for a trial basis.
Password Manager
Type
Security
LastPass
Cloud
AES 256-bit
1Password
Cloud
AES 256-bit then-MAC
Google Chrome
Browser/Local
Triple DES
Firefox
Browser/Local
Triple DES
Safari
Browser/Local
Base 64 algorithm
Opera
Browser/Local
Md5 Hash1
Internet Explorer
Browser/Local
Triple DES
KeePass
Local
AES 256-bit & Twofish
Password Safe
Local
Blowfish, 64-block cipher/ SHA-1
RoboForm
Local/cloud
AES 128-256 bit
Table 1: displaying the various password managers that are discussed further into the literature review.
2.3.3 Common Password Manager Features
There are three types of password managers; each has their own method of operating (United
States Computer Emergency Readiness Team, 2012). Each manager contains different
Page | 14
features, for example, Cloud based password managers allow synchronisation across multiple
devices (TopTenReviews, 2015) but Local password managers are only able to be used on the
device they were originally made on (Pinola, 2012).
There are two specific features that are offered by each password manager regardless of the
type of manager it is. The first is the ability to store user passwords in a database, protected by
some form of encryption. The second is the ability to have an auto-fill feature. The auto fill
feature allows the user to store all of their passwords and login information which is inserted
in the appropriate fields. This feature increases both user security and efficiency (Perrin,
2010).
These features are the bare minimum offered by password managers. Browser password
managers are an example of those that only offer these two features. Browser password
managers are only extensions to the actual browser itself, unlike any cloud based manager
which is third party software which has many different features not offered by browser based
password managers.
2.3.4 Password Manager Security
Password managers are a tool to increase security for their users on the web. As password
managers become increasingly more popular, investigations are carried out to test the stability
and strength of the security that they offer. These investigations have highlighted a number of
security flaws located in both browser and cloud based password managers.
These security flaws can have serious implications on the overall security of the password
manager and the data stored on them. The investigations have proved to be important because
through them, designers have been able to fix multiple potential openings which could
weaken the security of the managers. Malicious hackers are consistently altering and adapting
their techniques, once they have discovered a weakness or flaw within the security they can
then use it to gain data previously protected (Zhao, Yue and Sun, 2013).
An example of how malicious users are creating new ways to bypass the security password
managers is a discovery of a malware discovered to be installed within an IBM PC. This
malware was named the Citadel Trojan, which operates by monitoring the processes
associated with Nexus Personal Security (Personal.exe), Password safe (PWsafe.exe) and
Page | 15
Keepass (Keepass.exe). Once the malware detects that one of these pieces of software have
started to run it begins its key logging functionality (Kovacs, 2014).
By using a key logging function it may be possible for the user to retrieve the targets master
password or any data associated with the password manager. The data was then sent to a web
server operated by the attackers (Kovacs, 2014).
Attackers are constantly changing and adapting their techniques to bypass the security that the
average user uses. Because of constant change of attackers and malicious methods the need
for better password managers greatly increases. With the increased need for password
managers comes the needed for additional security to safeguard the data they hold.
This project will describe the three main types of password managers; cloud-based, browserbased and locally stored password managers. With each of these there have been previous
investigations into how secure each manager is, when faced with different types of attacks
which will also be explored.
2.4 - Cloud-based
Password managers such as LastPass and 1Password are cloud-based, they store saved
website passwords on a cloud storage server. Storing data this way enables users to have
access to their data wherever and whenever they wish (Zhao, Yue and Sun, 2013). Because of
this usability cloud password managers are the more commonly used type and work with most
browsers (Zhao, Yue and Sun, 2013). Similar to other password managers, cloud based
password managers operate by having the user create and save passwords whilst using the
manager. By doing so, the manager can provide complex and unique passwords for each
visited website.
Cloud-Based password managers use browser extensions to work alongside the users
browsers. These extensions allow the password manager to auto login and auto-populate
fields to reduce the chances of the user succumbing to attacks that involve user participation
(Li et al., 2014). For example if a user had a key logging software installed on their personal
computer, they would unknowingly be providing someone else with their passwords and data.
Page | 16
However, browser extensions are only accessible with certain browsers like Google Chrome,
Firefox, Internet Explorer and Safari. When a user is unable to download a browser extension
they are given the option of using a bookmarklet instead which acts as an extension that is
compatible with most browsers (Li et al., 2014).
2.4.1 - Password encryption
Encrypting data is a high priority for any password manager. Each manager version chooses
how and what they encrypt. For example LastPass uses a 256-Bit AES encryption to encrypt
both passwords and usernames (LastPass, 2015). However, another cloud-based password
manager named PasswordBox only encrypts user passwords (Li et al., 2014). Cloud password
managers also have to consider encrypting the method of transferring data across from the
server to the user’s device.
Encrypting the data that is being transferred is essential for cloud based password managers
because without using a secure data transfer method, a malicious user could view the data
packets being sent from the server to the user’s device (SSL Shopper, 2015). By using
Wireshark a user would be able to capture packets across a network and if not protected it
could be viewed easily for the malicious user (WireShark, 2015).
2.4.2 - Cloud-Based Features
Cloud-Based password managers include some of the most used password managers on the
market. Because of the high number of users, it is important for them to be up to date with the
latest features. Because of the features are not required for the core design of a password
manager to work, not all managers include all of the most up to date features.
Along with fulfilling the core purpose of a password manager, Last Pass also contains feature
such as users being able to combine ownership of accounts. This means that users are able to
share access to certain passwords with whomever they want (Li et al., 2014). LastPass also
includes the feature of syncing data across multiple user profiles when data is shared (Last
Pass, 2015).
For example if a user registers that they wish to share their log in information with their
spouse, they can still change or alter the log in information without needing to worry about
locking their spouse out. Once information has been changed the data is then automatically
Page | 17
changed on the communicating users vault as well without either user needing to take action
(Last Pass, 2015).
Synchronisation is another feature offered by cloud based password managers. Allowing a
user to synch their stored passwords and usernames is an effective feature for cloud password
managers. This is because when a user has multiple devices such as a phone, laptop, desktop
or Ipad they will be able to operate their account with their stored passwords and usernames
without being limited to the original device (McCarney, 2013).
Untrustworthy logins are another problem which cloud password managers can help resolve.
Some password managers such as LastPass allow One Time Passwords (OTP) or Kaspersky
Password Manager which uses a virtual keyboard (McCarney, 2013). This feature is
exceptionally useful if the user does not wish to divulge their master password on a device
they do not trust.
Each type of password manager has security risks associated with that type of manager. Cloud
based password managers do not store data on the user’s device, thus they do not need to
concerned about the security of the passwords being left on the user’s device. However,
cloud-based password managers have other security threats which could lower the reliability
of the managers.
2.4.3 - Security Issues
Cloud-based Password managers such as LastPass and 1Password pride themselves on being
among the best password managers on the market, each with millions of users’ worldwide (Li
et al., 2014). Because of the amount of active users it is unsurprising that attackers are now
changing their methods to target password managers instead of trying to bypass them
(Fontana, 2014).
There are many variations of attacks which have been tried and tested against cloud based
password managers. Because of this, the producers of password managers were able to
respond to the potential threat against them and fix the issues before becoming compromised
(Li et al., 2014).
Page | 18
The security issues mentioned below are past exposures which have since been fixed or
protected against. These are to show how cloud-based password managers are still unable to
safely guarantee their users a 100% protection against attacks.
2.4.4 - Decrypting LastPass Master Password
As mentioned in section 2.4.2, LastPass is one of the most popular password managers.
However, from a previous investigation it became clear that the method which LastPass uses
to secure the master password is potentially vulnerable to attack. The way in which LastPass
secures a master password before being saved within a database depends on the user machines
configuration (Zhao, Yue and Sun, 2013).
The first method depends on whether there is a binary component on the user machine. The
binary component is a plugin used to control features designed for LastPass, these features
include auto logoff on browser close, auto logoff on browser idle and enables finger print
authentication (LastPass, 2015). The binary component is automatically installed for Firefox
and Internet Explorer however, for a user to install the binary component they will need to
download it from a third party (LastPass, 2015).
If there is a binary component and the trusted platform module (TPM) of the machine is
available the protect_data() function of the binary component will use the Windows API
CryptProtectData() with the TPM to encrypt the master password (Zhao, Yue and Sun, 2013).
The second method of securing the master password also depends on whether the user has the
binary component installed. If it is installed but the TPM is unavailable the master password
will use the Windows CryptProtectData() without the use of the TPM function (Zhao, Yue
and Sun, 2013).
If however, there is no binary plugin installed, the master password is not encrypted at all.
Master passwords saved onto the user device whether encrypted or not are still vulnerable to
decryption attacks. An encrypted master password can then be unencrypted if the user has
both client side stealing capabilities and client side computational capabilities (Zhao, Yue and
Sun, 2013).
Page | 19
This security threat is only possible by utilising a design fault with LastPass itself, this type of
threat depends on the attacker having access to the user’s computer to gain access to the
stored master password database.
2.4.5 - JavaScript Rootkits
Bookmarklets
As mentioned in section 2.4.2, cloud-based password managers use browser extensions in
order to use certain features, unfortunately as not all browsers are capable of installing the
needed extensions. Without the extension, the features of being able to populate fields are not
possible. To make up for the possibility of not being able to use any extensions, LastPass and
other cloud based password managers use bookmarklets as a method of getting around this
problem (Li et al., 2014).
Bookmarklets are a special feature provided by cloud based password managers. They work
as a bookmarking method of synchronising the user passwords across multiple websites.
Bookmarklets are used when the current browser does not support any isolated APIs for
browser extensions (Li et al., 2014).
However, malicious users can use their websites to alter the JavaScript stored in the
bookmarklet to obtain a large proportion of the user’s stored passwords. The bookmarklet is
essentially a plugin which has less functionality but a broader compatibility (Li et al., 2014).
When a bookmarklet is being created it needs a link to the master key to authenticate the user.
This is done by firstly creating a new value once the user has requested a link be made. The
value is known as _LASTPASS_RAND which then encrypts the master password with it
within the user browser. The LastPass server then stores the encrypted code named
key_rand_encrypted and an identifier (h) along with the users credential database (Li, et al.,
2013).
The page the user is creating the bookmarklet for then creates a JavaScript snippet containing
the _LASTPASS_RAND and h, which allows the user to save the newly created bookmarklet.
By deleting the identifier (h) the user can revoke the bookmarklet at any time. This gives the
user the option of deleting previously created bookmarklets (Li et al., 2014).
Once a bookmarklet has been created, it contains both the _LASTPASS_RAND snippet and
the identifier (h). This means that once a user clicks on the appropriate bookmarklet, it firstly
Page | 20
checks on the pages domain and adds a script element to the page sourced from Lastpass.com
(Li, et al., 2013). To gain the script element, a request is made by the bookmarklet to the
LastPass server by sending both the identifier (h) and the domain of the page (u). LastPass
then checks the parameter h; if the bookmarklet has not been deleted previously h is classed
as valid. Once h has been classed as valid the LastPass server responds by sending a
JavaScript file containing two parameters ref and rh (Li et al., 2014).
The newly sent JavaScript file then creates an iframe to LastPass.com using the four
parameters h, u, ref and rh. The iframe contains a script located on the LastPass server which,
when downloaded contains the key_rand_encrypted and the credentials for the associated
page. Once received the iframe then receives the bookmarklets _LASTPASS_RAND value
through a postMessage call. This allows the bookmarklet to decrypt the associated pages
credential (Li et al., 2014).
2.4.6 - Bookmarklet Attacks
One way in which an attacker could use bookmarklets is by taking advantage of how they
work. This can be done if the user clicks on a bookmarklet whilst on a malicious website.
Once the request has gone through for the JavaScript snippet, they can use a number of
hijacking techniques to gain access to the data which is sent from the LastPass server (Li et
al., 2014).
By using a hijacking technique the attacker can retrieve the LASTPASS_RAND and h
parameters and then requesting the script from the server (Li et al., 2014).
Once the attacker has the parameters from the script and obtained the parameters left on the
bookmarklet (h and u) they have all of the needed data to decrypt the credentials for the
desired page from the LastPass server.
The attacker then only needs to repeat the previous hijacking technique to retrieve the
decrypted information (Li et al., 2014).
LastPass responded to the potential vulnerability in a blog where they commended the efforts
of Zhiwei Li and his team for their research. Although they also claimed that the issue had
been resolved, they did recommend that anyone who may have used a bookmarklet before
September 2013 should change their master password (LastPass, 2013).
Page | 21
Shadowing
There are many variations in which a bookmarklet can be used against a user. One simple
method of attack is known as shadowing. Shadowing replaces a native JavaScript global
variable with another variable with the same name (Adida, Barth and Jackson, 2009). The
native JavaScript is replaced once the user enters the attacker’s website before the native
JavaScript has time to run, by doing so the attacker can then utilise a getter or setter function
which most browsers support (Adida, Barth and Jackson, 2009). By tricking the bookmarklet
into thinking the new JavaScript is native; the attacker can use a getter or function to retrieve
the supposed password for the website (Adida, Barth and Jackson, 2009).
The code below is an example of how a shadow technique can be used to gather a password
from a bookmarklet. In this case we can imagine that login has been replaced as indicated
with the # value. The login value represents the stored password data associated with the
recorded log in details (Adida, Barth and Jackson, 2009).
Window. _defineGetter_(“location”),
Function () (
Return https://bank.com/login#;
));
Window._defineSetter_(“location”,
Function (v) { } );
(Adida, Barth and Jackson, 2009).
Bookmarklets may be a feature for users to easily fill out forms or log onto sights. However,
the cost of storing data within a bookmarklet may result in the user losing the information
which the bookmarklets were designed to protect (Adida, Barth and Jackson, 2009).
2.5 - Browser based
Safari, Firefox, Internet Explorer, Opera and Google Chrome are the top five browsers of
2015 (Carlsen, 2015). These browsers have been compared for their speed, compatibility,
security, feature set and help/ support.
Google Chrome, Firefox, Internet Explorer Safari and Opera all offer their own integrated
password manager. Each browser has their own method of storing and securing data and
works differently depending on the operating system that is being used. For example Chrome
Page | 22
may use the users Microsoft account password as a master password however, when installed
on an Apple system that is not possible. (McCarney, 2013).
Browser managers offer a limited number of features when compared to other types. For
example these password managers do not offer a complex password generator or secure log in
capabilities (McCarney, 2013).
On a Windows based machine, Google Chrome, Internet Explorer and Safari all use Windows
Data Protection API to encrypt all of the passwords stored in their respective databases. The
Encryption used by DPAPI is linked with the users Microsoft Windows account password
which acts as the user master password (McCarney, 2013). By doing using this method of
encryption, Chrome, IE and Safari can be assured that the password database is secure from
being viewed in plain text, without the need for the user to set their own master password
(McCarney, 2013).
On a MAC OSX machine however they rely upon Apple’s Keychain service to encrypt the
contents of the databases. Similar to the DPAPI, as the default master password the user login
user password is used. To change the password the user must do so manually and thus is
unlikely to be done by the average user (McCarney, 2013).
On a device with a Linux based OS Chrome automatically chooses whether it will encrypt the
databases contents either with GNOME Keyring or KWallet, if neither is available Chrome
stores the passwords unencrypted and in plain text (McCarney, 2013).
Below each browser is examined on the features and the security of their password managers
to demonstrate how this type of manager differs from software dedicated to password
management.
2.5.1 Google Chrome
Google Chrome is one of the top five browsers currently being used. Google Chrome
advertises itself as a fast, secure and simple browser to use (Chrome, 2015). Google Chrome
does offer support against phishing and malware attacks against the user. This is done by
alerting the user when they are about to view a website which has been recorded to contain
Page | 23
malware or phishing attacks (Chrome, 2015). However, unfortunately Chrome’s password
manager does not offer a high level of security.
As previously mentioned each browser supplies their own password manager inbuilt into the
browser however, these password managers do not offer the same level as security or features
as other third party password managers such as LastPass.
Google Chrome was exposed to have very little in terms of security for their password
managers. Up until 2013 Google Chrome did not even have a master password securing the
password database. All a user needed to do was open Chromes settings, click on manage
passwords and then click show to the associated password that they wanted to view. This lack
of security meant that anyone with access to the machine was able to view all of the
passwords of the signed in user (Poulsen, 2013).
Chromes password manager has since had a master password security measure installed. The
password manager saves all appropriate data to allow an auto fill feature. Passwords are saved
into a database named ‘login data’. If however, a user chooses to not save their password for a
particular website the web address is instead saved into a different database so that Chrome
does not ask again. Chrome uses a SQLite database with a Triple DES Algorithm to encrypt
the passwords stored in the database. Chrome only chooses to encrypt the passwords and
leaves all of the other data unencrypted and in plain text (Security Xploded, 2015).
Unfortunately, even with the added protection Chromes master password now offers, it
remains easy for an attacker to decrypt the Login data database by using a third party
software. Chrome Password Decrypter is a tool which decrypts all of the stored passwords
and saves them into a XML, HTML or TXT format (MajorGeeks, 2015).
2.5.2 Mozilla Firefox
Firefox is another popular browser which has its own built in password manager feature.
Unlike the other browsers mentioned, Firefox works the same regardless of which operating
system the device is running on. Firefox’s password manager works just as any other browser
password manager would, by asking whether the current user would choose to save their
password for the current website (How-To_Geek, 2012).
Page | 24
Firefox does have the option of using a master password however, it requires the user to enter
it themselves or a null value is stored instead. It is important for the user to enter a master
password because all of the security designed to encrypt the data requires there to be a
password.
What separates Firefox’s password manager from others is that they choose to use a number
of security measures placed on the database.
When a new Firefox profile is created a random key called an SDR key and salt are also
created and stored in a file called key3.db. The key and salt are used in a 3DES algorithm to
encrypt all of the usernames and passwords of the new profile. Once the usernames and
passwords are encrypted the encrypted file is then base64 encoded. Once they have been
encoded, they are stored in a SQLite database named signons.sqlite (Wright, 2013).
To get access to the SDR keys contents the user has to decrypt it using the master password
and the global salt stored in the key3.db file. Without a strong master password an attacker
could extract the global salt and decrypt the SDR key with the null value. This is why it is
important for the user to have a strong secure master password (Wright, 2013).
With the use of third party software, an attacker can decrypt the database which holds all of
the user passwords and usernames. FireMasterCracker is a tool which uses various methods of
decryption, these methods include brute-force, dictionary, hybrid and pattern based bruteforce (Darknet, 2006).
2.5.3 Microsoft Internet Explorer
Internet Explorer (IE) is the default web browser with any Microsoft operating system.
Internet Explorer chooses to store user passwords and usernames in the devices registry. Each
record is stored separately, each as a new registry record and encrypted with the users log in
credentials which acts as a master password (Gasti and Rasmussen, 2012).
The encryption method is performed using the CryptProtectData system call with a triple DES
in Cipher Block Chaining (CBC) mode and a hash based Message Authentication Code
(MAC). The key to decrypting the database is derived from a random salt value (stored in the
ciphertext), the URL of the address and the Windows Login Credentials (Gasti and
Rasmussen, 2012).
Page | 25
The security of Internet Explorers password database is dependent on the strength of the user
login credentials. If the user has not got a log in password then the database is left unprotected
against malicious users (Gasti and Rasmussen, 2012).
2.5.4 Safari
Safari’s password manager functions depend on the operating system it is running on. If for
example, a user is using Safari on a Windows OS, Safari automatically uses the Windows
APAPI function to encrypt data stored in the password database (McCarney, 2013).
However if the user is has an Apple OS installed on the device they instead use a cloud
password manager named KeyChain (McCarney, 2013).
On a Windows OS device, Safari uses an encryption method similar to Chrome and IE in that
they all use Microsoft’s user password as the master password which allows the algorithm to
be created. Safari also stores the passwords locally in a database named keychain.plist (Mac
Developer Library, 2014).
On an Apple OS device however, the cloud password manager KeyChain is used. It operates
similar to if it was run on a Windows machine but uses the users log in passcode on mobile
devices and password on a desktop version. As a cloud based password manager KeyChain
allows the same features of other cloud based password managers. These features include auto
login, password generator and synchronisation across devices (Brodkin, 2013).
2.5.5 Opera
As mentioned in section 2.5, Opera is among the top five browsers used today. Similarly to
the other four browsers Opera has an inbuilt password manager that is used for both
convenience and user security. Unlike other browsers Opera requires the users to activate
their password manager themselves whereas in other browsers, it is done automatically. To
operate the password installed password manager the user has to navigate to the settings and
click on the security and privacy tab to be given the option of activating the manager (Opera
Software, 2015).
Similarly to other password managers Opera uses Microsoft’s Windows log in password as a
master password. Operas password manager is limited to the feature of storing usernames and
passwords for the precise reason of log in forms (Khanse, 2014).
Page | 26
2.5.6 Browser Summary
Browser password managers each have their own method of protecting and managing
passwords. Although they may each secure passwords, due to the inefficient protection a user
should not rely upon the security they offer, but instead look into other alternative methods. If
a browser password manager is used however, the user should understand the risks associated
with each browser as currently there is no immediate source informing users.
2.6 - Locally based
Local password managers are a combination of both browser and cloud based password
managers. The features they offer share similarities to cloud based password managers and
the storage method is the same as browser based password managers (Gasti and Rasmussen,
2012).
What Separates local or desktop password managers from other manager types is the way in
which the manager stores, manages and the level of control the user has over their data. As
mentioned in section 2.4 and 2.5, cloud password manager databases are stored on a secure
server whilst the security key is stored on the user computer, whereas the browser based
password managers give no GUI for the user to operate and manage but does store all of the
users data on the machine itself. The locally stored managers give the user control over their
password database but still are used securely.
Similarly the other password managers password Safe, KeePass and RoboForm have all had
previous examinations to test the security placed on their databases. This type of
experimentation was specifically designed to test the security on the database whereas this
project looks at the security behind the features from a user perspective.
2.6.1 Features
The local password managers discussed in this project are open source, meaning that they are
free to use but have a reduced amount of features when compared to cloud password
managers. However, being open source also offers a unique possibility for user input and
development. KeePass for example openly allow plugins that have been developed by other
users. This means that the development of the manager is constantly growing and adapting to
the needs of its users (Reichl, 2015).
Besides the additional custom tools available, local password managers also have the
additional benefit of allowing their users the options of moving their database of passwords
Page | 27
between computers or simply onto a memory stick. However, this feature does not make their
databases as accessible as a cloud password manager. The option of moving any of their
databases may be seen as either a security feature or vulnerability depending on how the
databases are transported (Reichl, 2015).
2.6.2 Attack Restrictions
Desktop password managers are locally stored; this means that they attacks they are
vulnerable to is slightly different to those that can be done on a cloud based password
manager. Firstly there is no need for the password manager to be connected to the internet,
which this means there is possibility for the user passwords to be gained by intercepting data
being sent to and from a server as there is with cloud password managers.
Previous projects done on KeePass, Password Safe and RoboForm were conducted on the
databases themselves. The testing done was designed around testing the database format that
each of the software uses. The examinations done on each of the password managers by
(Paolo Gasti and Kasper Rasmussen) did conclude that there were issues with the databases
used by the most popular password managers.
2.6.3 KeePass 2x version 2.28
KeePass is an open source local password manager, available on Windows, Linux and Apple
OS. Over the years it has won multiple awards, all of which can be found on their website.
(Kee Pass, 2015). Even though KeePass is an open source password manager it still has a
wide variety of features, these include the ability to install plugins, multiple user keys and
easy database transferring (Kee Pass, 2015).
As with most password managers, KeePass offers the feature of creating strong passwords to
reduce the likelihood of the user passwords being discovered. KeePass also offers their users a
further level of control by allowing the option of choosing what characters to include in the
password. For example the user may wish to include letters, numbers but no special characters
but still have a strong password (Rubenking, 2012).
There are two versions of KeePass available for download, a classic edition and a professional
edition. Each of these also have a second option of downloading a zip file folder instead of an
exe, this is designed easy transference onto a memory stick or removable device.
KeePass is praised for their user-controlled security, strong algorithms and its offline access.
These are among a few of the features that make KeePass one of the most noteworthy
password mangers on the internet (Henry, 2015).
Page | 28
2.6.3.1 KeePass 2.x Features
KeePass 1x and 2x features are all designed to securely manage and contain all the data
entered into each database, but still give the user a sense of control over their data and their
databases.
Portability
As previously mentioned in section 2.6.1, KeePass has the capacity to be downloaded onto a
USB device and can be run on a Windows device without the need to first install it. This does
makes it easier for users who do not want to use a cloud based password manager but require
their passwords in different locations. Portable password databases do however, raise the
security risks when being used on possible compromised systems and raises chances of it
being misplaced or lost (Reichl, 2015).
Exportation and Importation
Importing and exporting databases are common in almost every password manager. This
feature allows the user the opportunity to move their database to either a new location or
imported into a different password manager (Reichl, 2015).
KeePass 2.x is capable of importing over 35 different formats into their databases. These
formats include other password manager database formats, for example KeePass 2.x is
capable of importing other locally stored password databases and other text formats like
HTML, TXT and CSV (Reichl, 2015).
Exporting databases can also be achieved by using the inbuilt features offered by KeePass 2.x.
Using the exporting feature a user can download their entire database of passwords into an
easy to read document or into a normal KDB format depending on their purpose (Reichl,
2015).
Database Data Management
The following features are used for both data management and control.
Password Groups
Password grouping allows the user to structure their database passwords. By doing so, the
user can better manage their passwords so they can have different groups for both work and
home. Each group can be arranged in a tree structure, allowing the user to see where there the
sub group belongs (Reichl, 2015).
Time Fields and Entry Attachments
KeePass supports the use of time fields, allowing the user to note the creation, last
modification, last access and the expiration date of every password they enter. This feature is
Page | 29
useful for guaranteeing that the user is not using a password for an extended amount of time
which may lower the security of the protected data (Reichl, 2015).
Secure Windows Clipboard Handling
Windows clipboard is a feature designed for copying data which can then be pasted to the
necessary fields without actually typing each entry. This feature is useful for preventing key
loggers and other malicious software gaining access to user data (Reichl, 2015).
Search and Sorting
Searching and sorting allows the user to easily find individual entries rather than having to
locate it by opening every group and every entry (Reichl, 2015).
Strong Random Password Generator
Similar to other types of password managers, KeePass has the option of creating complex
passwords for individual entries. This reduces the likelihood of the user re-using old
passwords and risking the security of the data they are trying to protect (Reichl, 2015).
Users can create a password either using the password generator or make use of the random
seeding option which uses user mouse movement and random keyboard input to create a
strong password (Reichl, 2015).
Multiple User Keys
Unlike other Password Managers, KeePass offers the feature of using more than one method
of securing a database. A master password is the most common way of securing a database
contents however, KeePass gives their users the option of securing their database with either a
master password, key file or by using the Windows account password. To add a further level
of security a user can use multiple security measures. For example combining both the master
password and a key file will mean if the key file is misplaced or lost the data is still secure
without the master password (Reichl, 2015).
Printing database contents as a hard copy
KeePass 2.x includes the option of printing the contents of a user database to obtain a hard
copy if required. KeePass printing feature creates works by creating a temporary file where
the contents is placed and then deleted to retain the contents security (Reichl, 2015).
2.6.3.2 Security
Both versions of KeePass use well known and well respected algorithms for their database
encryptions, KeePass 1.x uses both Advanced Encryption Standard (AES / Rijndael) and
Twofish. Each version uses a 256 key size and 128 block size. KeePass 2.x however, does not
Page | 30
support Twofish but additional encryption algorithms are available as a plug in if the user
wants to add additional features they can (Reichl, 2015).
Hashing and key derivation
The key bit block encryption requires the use of a secure algorithm to compress the users key
(either a password and/or a key file) into a fixed size key of 256 bits. KeePass uses the
hashing algorithm SHA-256 which has been shown to be a secure method of encryption
(Reichl, 2015).
If only a master password is used, the password plus a 128-bit random salt are hashed to
SHA-256 to create the final key.
Dictionary Attack Protection
Although preventing dictionary attacks is not 100% assured, KeePass uses certain measures to
make sure that a dictionary attack is inefficient and harder to accomplish. The final 256 bit
key is generated uses a SHA-256 encryption to encrypt ‘N’ times using an AES algorithm.
The key is then ‘hashed’ again using a SHA-256. For AES, a random 256 bit key is used
which is stored in the database file. This means that an attacker must try every combination to
check that the current key is correct (Reichl, 2015).
By default KeePass sets ‘N’ as 6000 encryption rounds however, ‘N’ can be changed by the
user during the databases creation
Process Memory Protection
During the time KeePass is in operation it stores sensitive data in the computers process
memory encrypted. As a further measure of security the encrypted data is later overridden by
the software before releasing them, this ensures that the data is permanently deleted from the
computer. Similarly to the browser password managers KeePass uses Windows DPAPI as
previously described in section 2.5. DPAPI is used for the encryption of data stored in the
process memory (Reichl, 2015).
2.6.4 - Password Safe version 3.35.1
Password Safe is open-source, standalone software that is hosted on open source.net. The
designer of Password Safe is security expert Bruce Schneier. Password Safe is simple in
design, offering very little in features other than the basic features of storing usernames and
Page | 31
passwords, generating new passwords and managing the data stored in each database
(Mulligan and Elbirt, 2007).
Advance users are given the option of customising their databases like creating intermediate
backups before saving and shortcuts to other features.
2.6.4.1 Password Safe Features
As mentioned in section 2.6.4 Password Safe offers a limited number of features to reduce the
software size and ease of use. The features it does offer include password grouping, drag and
drop, backup, import and export, browse / autotype, merge, sync and password expiration (der
Gucht, 2015). All of these features are similar in design to the features in KeePass 2.x as
mentioned in section 2.6.3.1.
2.6.4.2 Password Safe Security
Password Safe chooses to use a Twofish encrypting algorithm that is an alternative to a DES
algorithm. The security has also been claimed to have been “thoroughly verified by
Counterpane Labs under the supervision of Bruce Schneier” (Schneier on Security, 2015).
2.6.5 - RoboForm (Desktop-Based trial, version 7.9.12)
RoboForm is a mixture of both a cloud and local based password manager; initially the data is
stored on the user’s computer. However, every user is given the option of buying RoboForm
“Everywhere” which acts as a cloud-based password manager feature giving their users
access to their data on any device at any time (RoboForm, 2015). RoboForm also has full
integration with every browser mentioned in section 2.5. Aside from having 15 years of
experience and having a 24/7/365 call back policy, RoboForm has a free mobile application
version which can hold up to 10 different logins (RoboForm, 2015).
2.6.5.1 RoboForm Features
RoboForm is a combination of having a locally stored option whilst still offering the same
features found on a cloud based password manager, for example completely synced data and
access anywhere and instant completion of long forms.
One click logins
One click login is a feature where the user is given the option of selecting the desired website
out of a toolbar list, once selected RoboForm logs the user in without further input. This
feature is especially useful against key loggers and other malicious software designed to
record key movements (Siber Systems, Inc, 2015).
Page | 32
Instantly login forms
By using the RoboForm pass-card feature, a user can instantly fill in forms by selecting the
relevant card which will take them onto that site and log them in securely. Filling in these
forms can also be done either by normal typing or using the drag and drop feature (Siber
Systems, Inc, 2013).
RoboForm Identities
Similarly to the log in forms, RoboForm has the additional feature of ‘identities’. These
identities are used when a non-password form needs to be completed, each identity can hold
every field that a user would expected to answer. For example when entering completing a
form that includes numbers, job title, name or email address the user can instantly fill these
fields with one click (Siber Systems, Inc, 2013).
Safe Notes
Safe notes are a feature that allows the user to protect secret data that may not be a password
or web related secret, for example a user credit card passcode or a safe combination. This
information is encrypted in each database as any other data is. However, each safe note can be
emailed, printed or cloned depending on the user needs (Siber Systems, Inc, 2013).
RoboForm2Go
RoboForm has a similar feature to KeePass that they allow the downloading of the software
onto a removable storage system (usually a USB). RoboForm2Go does as the name suggests
and allows the user the option of keeping their data local but having a way of transporting it to
other computers (Siber Systems, Inc, 2015).
2.6.5.2 Security
RoboForm uses a combination of different methods to make sure that any user data entrusted
in their databases are as secure as possible. RoboForm protects each Passcard or any
RoboForm file with a secure master password that the user creates. Depending on the
character length of each password it is encrypted using a different algorithm, the table below
shows the encryption for each character length.
Algorithm Key Length
Block Size
AES
128-256
16
Blowfish
256
8
RC6
256
16
3-DES
64
8
1-DES
64
8
Page | 33
Table 2: showing the algorithm for each password character length for RoboForm adapted from (Siber Systems, Inc,
2013).
AES key length depends on Master Password Key Length:
* 128 bit for Master Password less than 32 characters,
*192 bit for Master Password from 32 to 47 characters,
* 128 bit for Master Password characters no longer.
For security reasons RoboForm only stores data in known locations that once deleted upon
user request, all data contained in the deleted database is permanently deleted from the
system. RoboForm does however; give the user the option of backing up their passwords and
databases on their servers (Siber Systems, Inc, 2013).
USB Security
As mentioned in section 2.6.5.1, RoboForm2Go gives their users the option of removable
storage. To retain the security of the databases saved on the moveable storage RoboForm
removes all trace of the device ever being on the computer. Using a removable storage does
however mean that if lost, all data associated with that USB is also lost (Siber Systems, Inc,
2013).
2.7 Digital Forensic Investigation
2.7.1 Introduction
The information gathered concerning each possible failure in local password manager security
will be analysed and examined using a digital forensic framework and conducted by adhering
to the set Association of Chief Police Officers (ACPO) standards and principles. Each
investigation will explore potential security flaws in each password manager by analysing
whether the software poses any risk to its user.
The following section will explain the processes that each investigation will follow and the
necessary background information needed to fully understand the reasoning for each method.
2.7.2 ACPO Principles
The ACPO principles for digital forensics are required due to the fragile state of digital
information that investigations are required to retrieve (Afentis, 2010).
Page | 34
There are four specific principles which must be followed when conducting any digital
forensic investigation regardless of the type of device. The following principles are the most
up to date list currently used (Wilkinson, 2015).
Principle 1: No action to be taken by law enforcement agencies, persons employed within
those agencies or their agents should change data which may be subsequently be relied upon
in court.
Principle 2: In circumstances where a person finds it necessary to access original data, that
person must be competent to do so and be able to give evidence explaining the relevance and
the implications of their actions.
Principle 3: An Audit trail or other record of all processes applied to digital evidence should
be created and preserved. An independent third party should be able to examine those
processes and achieve the same result.
Principle 4: The person in charge of the investigation has overall responsibility for ensuring
that the law and these principles are adhered to.
2.7.3 - ISO 27037
International Standards Organisation 27037 (ISO 27037)
ISO standards present a guideline for handling a digital forensic investigation. The guidelines
include: identification, collection, acquisition and preservation of the digital evidence. The
aims of the ISO standards are to create audibility, repeatability, reproducibility and
justifiability of the digital investigation (BSI Standards, 2013).
Audibility
Any external assessor or authorised personal should be able to evaluate the steps taken during
an investigation, by correctly documenting each of the steps taken. This is designed to ensure
the correct steps have been followed (BSI Standards, 2013).
Repeatability
Repeatability is established when the same results can be reproduced by correctly repeating
the investigation following the same conditions as the original investigation. A fully trained
investigator should be able to arrive at the same results without need of guidance or
interpretation (BSI Standards, 2013).
Page | 35
Reproducibility
Reproducibility is similar to repeatability however; the same results should be achievable
under different circumstances and conditions. By doing so the investigation can be showed to
be reproducible no matter what method is used (BSI Standards, 2013).
Justifiability
Any actions done by the investigator should be justifiable, in other words, every step taken in
both the handling and investigation of the digital evidence should be undisputable (BSI
Standards, 2013).
2.7.4 - Digital Forensic Frameworks
A digital forensic framework is a planned process which has to be closely followed by the
investigator. However, with further advancements in technology there is no recognised set
standard for a digital framework. Each framework has a variation of the same steps but
ultimately follows the same path. Digital forensic investigation is often relied upon in court
where any digital devices are involved. This mean, the evidence collected and the process
used for the collection can be scrutinised (Kohn, Eloff and Eloff, 2013).
To adhere to the ACPO principles each step taken needs to be documented, doing so will
allow any evidence located be easily re-discovered by completing the same process (Kohn,
Eloff and Eloff, 2013).
A standard forensic process model follows four main processes. Each process is designed to
control the case from the moment any device is retrieved from a crime scene to the point that
the evidence is being reported. Depending on the complexity of the case each phase may have
an increase or decrease in steps depending on the necessity. Each method is presented below
with an explanation of each step (Al-Fedaghi and Al-Babtain, 2012).
Collection: The first phase involves collecting, categorising, labelling, sorting and recording
all possible digital devices that may contain relevant data.
Examination: The examination phase of the process model focuses on forensically
processing all of the gathered data. The data is examined using specialist software and
techniques either manually or automated to discover any data of relevance to the
investigation.
Page | 36
Analysis: The third phase is processing all the resulting data to answer the questions that were
presented to justify commencing a forensic investigation.
Reporting: The final phase is to report on all of the information gathered from the
investigation. The report may include details on what was collected, how it was collected and
where it was collected.
The next section of will examine other known forensic frameworks and compare them against
each other in terms of how they differ and what the differences in phases mean.
2.7.5 - Digital Forensic Framework Examination
As mentioned in section 2.7.2, the four phases of a digital investigation are included in all
current frameworks in some way. The main challenge investigators face when deciding on a
particular framework to choose is, by choosing a framework incorrectly can greatly influence
the overall outcome of the investigation. Each framework has its advantages and
disadvantages and it is up to the lead investigator to decide which framework is most relevant
for that situation (Olga and vidalis, 2013).
Without a set standard for all digital forensic investigations there are numerous versions of
investigatory frameworks that each has their own interpretation of the correct process to
follow. Although every framework follows the same path mentioned in section 2.7.2 there is
usually a large difference in the amount of phases that each framework has. Table 3 displays
13 difference digital forensic frameworks alongside the number of phases that each of them
have.
No
Digital Forensic Investigation Framework
No of Phases
1
Computer Forensic Process (M.Pollitt, 1995)
4 Processes
2
Generic Investigative Process (Palmer, 2001)
7 Classes
3
Abstract Model of the Digital Forensic Procedure 9 Components
(Reith, Carr, & Gunsch, 2002)
4
An Intergrated Digital Investigation Process 17 Phases
(Carrier & Spafford, 2003)
5
End-to-End Digital Investigation (Stephenson,
6 Steps
2003)
Page | 37
6
Enhance Integrated Digital Investigation Process 21 Phases
(Baryamureeba & Tushabe, 2004)
7
Extended Model of Cybercrime Investigations 13 Activities
(Ciardhuaim, 2004)
8
Hierarchical, Objective-based Framework (Beebe 6 Phases
& Clark, 2004)
9
Event-based
Digital
Forensic
Investigation 16 Phases
Framework (Carrier & Spafford, 2004)
10
Forensic Process (Kent K., Chevalier, Grance, & 4 Processes
Dang, 2006)
11
Investigation Framework (Kohn, Eloff, & Oliver, 3 Stages
2006)
12
Computer Forensics Field Triage Process Model 4 Phases
(K.Rogers, Goldman, Mislan, Wedge & Debrota,
2006)
13
Investigative
Process
Model
(Freiling
& 4 Phases
Schwittay, 2007)
14
Common Process Model (Freiling and Schwittay, 3 Phases
2007)
Table 3: displaying various digital forensic frameworks and the number of phases they each have adapted from (Selamat
and Sahib, 2008).
Table 3 contains a small number of frameworks that are available to use by a digital
investigator. For the purpose of this project only three frameworks will be discussed in greater
detail. The reasoning for choosing which frameworks to discuss in greater detail is based on
how adaptable they are to meet the needs of the investigation. The three frameworks that will
be discussed further are the End-to-End, Hierarchical and Common frameworks.
Chapter 2.8 - Forensic Tools
A digital forensic examination requires the use of specialist forensic software; this software
allows an examiner to fully examine the intended device without needing to be concerned
about not seeing hidden or deleted data. There are both tools designed for specific reasons and
tools designed for general forensic investigations; it is up to the examiner to determine the
correct tool to use for each scenario (Forensic Focus, 2015).
Page | 38
2.8.1 Encase and FTK
Encase v7 is the leading standard in forensic examination software. Investigators used Encase
to conduct an efficient, forensically sound, collection and investigation that is both repeatable
and defensible in a court of law. Encase can be used with many different electronic devices
including laptops, desktops, mobile phones and removable media. Encase gives the examiner
an unobstructed view of the data left on the targeted device. Effective use of this software can
reveal any and all relevant data left on the device whether it be deleted, hidden or password
protected (Guidance Software, 2015).
Encase features are designed to provide each investigator with a toolkit for every occasion
and for almost every possible scenario, for example Encase can be used for a simple
examination of a hard drives documents or it could be used on a hard drive believed to contain
thousands of indecent images (Guidance Software, 2015).
Forensic Tool Kit (FTK) is also forensic analysis software designed for digital forensic
analysis. FTK is similar in design to Encase in that it can be the only software needed for a
digital forensic examination. FTK features include a registry viewer, encryption cracker and
zip file analysis (Access Data, 2015).Both Encase and FTK are commercial digital forensic
toolkits that are available for both student and business use. Although FTK is a commercial
product, it does offer a free option that does has a limited number of files that can be
analysed. The limited version does not allow a complete scan of the device, this means any
data on the device is not admissible in court but does give the user a test of the software
(AccessData, 2015).
2.8.2 Freeware tools
As mentioned in section 2.8, there are both freeware and commercial forensic software
available on the internet. Encase and FTK are both tools that require payment however, as
previously mentioned in 2.8.1 FTK does offer a limited free version but the full version
requires payment. Unlike other general tools, most freeware is designed for a specific purpose
that when combined with other tools give the examiner all they need to conduct a full
investigation.
2.8.2.1 Data capture
Data capturing tools are used for creating images for further examination using other
specialist software. Data capturing is an important step for a digital investigation, if done
correctly the whole contents of the intended target will be captured for analysis. If done
Page | 39
incorrectly there may be data missing from the image which may change the conclusion made
by the investigator (Forensic Control, 2015).
Encase Forensic Imager and FTK imagers are both free software that are capable of capturing
the contents of an intended electronic target. However, they worked best when combined with
the actual forensic analysis software mentioned in section 2.8.1. Other software can capture
specific data from the digital device, Magnet RAM Capture is free to use software designed
for capturing physical memory off of a suspected device. Guymager is a tool used as a multithreaded GUI imager which works on Linux machines.
There are many different types of imaging software available for every operating system and
electronic device the software mentioned are only a couple that can be used, depending on the
investigators needs (Forensic Control, 2015).
2.8.2.2 Email Analysis
Email analysis software is used to review the emails sent on the targeted digital device, emails
can be relevant for an investigation to provide evidence of communication between different
parties and also crucial for understanding what the device was used for. Mail viewer and PST
Viewer are both email analysis software that is both free and useful for an investigator.
Correct use of this software can reveal all communication via email and what was contained
in those emails (Forensic Control, 2015).
2.8.2.3 File and Data Analysis
There are many different types of file and data analysis software available for download. Each
type of software can be used for a different purpose. For example, Defraser is used for
detecting full or partially media files located in the unallocated space of the device.
Encryption Analyzer scans the device to locate any password protected documents or folders,
reports the level of encryption and gives the user recommendations on how to break or bypass
the security of those files (Forensic Control, 2015).
2.8.2.4 Internet Analysis
Internet analysis software is used to capture the internet history, cookies, stored passwords
and the stored caches of every browser on the digital evidence image. Browser History
Viewer, Web Historian and Web Page Saver are all individual software’s capable of capturing
data from the browsers located on the image (Forensic Control, 2015). The information
gathered from the user browser can include all of their usernames, passwords, past web
addresses and all activity done on each browser.
Page | 40
2.8.2.5 Registry Analysis
The registry holds all the information relating to the machine itself, with the information
gathered from the registry the investigator can view the user settings, time and date the
computer was set to all of which is needed to create an accurate forensic report. Registry
Decoder, RegRipper and Windows Registry Recovery are three individual software’s capable
of capturing the registry for analysis (Forensic Control, 2015).
The software mentioned in this section is a few of the wide variety that can be used by an
investigator or a general user. These free software alternatives give the user the same analysis
options as either Encase or FTK does but is not located in one package. This software list
shows that an untrained investigator or malicious user can still accomplish the same results of
a trained investigator but without the laws that govern a legal investigation.
Page | 41
2.9 - Literature Review Summary
This literature has covered a broad range of areas associated with password managers. Section
2.2 discusses general password protection to help understand the reasoning behind the
importance of password protection and password managers. From the gathered literature it has
become apparent that a strong password is essential for any online profile or account
regardless of its use. Although un-guessable passwords are encouraged section 2.2 has shown
that complex passwords are rarely easy to remember and less likely to be used. Section 2.3
introduced password managers and the need for them. From this section each of the password
manager types were explained and examined in terms of how they worked and operated.
Section 2.3 discussed a variety of different features and security advantages to using password
managers. This section discussed the reasons as to why password managers are being used
and why they are necessities for users who want a high level of security on their passwords.
The literature review then discussed each type of password manager in more detail in terms of
the features, security issues and examples of those security issues. 2.4 discusses cloud
password managers, 2.5 discusses browser password managers and 2.6 leads into discussing
the local password managers that will be examined for this project.
2.7 discussed digital forensic investigation and the laws that govern each investigation.
Within this section are the ACPO and ISO guidelines. Both have to be followed during any
type of digital investigation. Alongside the guidelines each of the investigations will follow
are the digital forensic frameworks that help guide each investigator in every investigation.
This section begins to discuss the digital forensic aspect of this project that will be used in
each scenario. 2.8 leads to the forensic tools that are involved in a digital forensic
investigation, this section also discusses freeware tools that are available online that are
capable of the same types of investigation used in this project.
Password Managers have shown to have many uses and positive features that make them
effective at providing a secure environment for users to place their most valuable digital data.
However, from the literature it is evident that password managers are not 100% effective
against malicious intent. The method of attack may be different in both cloud and browser
based managers but result is still the same, passwords and data entrusted to them is or can be
stolen.
Page | 42
The analysis of cloud password managers revealed that unlike browser based password
managers, cloud password manager issues were aimed at the functionality and features, as
opposed to the actual database that contained the data. For example section 2.4.4 discussed
the implications of how LastPass were encrypting their master passwords and the fault found
in those systems. This shows the large differences in what attackers target on different
password managers. Browser password managers for example have their databases targeted as
mentioned in section 2.5.
The discussed literature focuses on the security issues that individual password managers
have experienced. These issues revolve around their features and the way in which the
features operate. The test conducted on password managers focuses on the security aspects
that affect the database of the password manager as opposed to how the manager operates.
This project focuses on analysing local password manager features because of the little
amount of research that has been conducted on whether they are as secure as advertised.
To more effectively evaluate whether there are any potential risks associated with how the
password manager operates a digital forensic investigation will be carried out on the
associated computer to gain a better understanding of the impact the password manager is
having on the computer itself. A digital forensic examination is not a common practice for
software testing but provides the tester with a clear understanding of the repercussions of
using this software.
Page | 43
Chapter 3 - Methodology
3.1 Introduction
This section will look at the ways to show the information that will be gathered from the
planned experiments. The first part will analyse the best method of planning and conducting
the investigations on each of the three password managers. From this a further section will
show the method of displaying each experiment in an understandable form. The second half
of this section will look into the forensic process models that will be used to determine the
correct path and method of digital forensic investigation.
Unlike other undergraduate dissertations, the experiments conducted in this project will not
present any findings which can be categorised as a statistic or social experiment. The outcome
of these experiments will reveal how each local password manager handles each situation and
the impact that they have on the user’s machine. As revealed in the literature review, each
password manager regardless of type is susceptible to attack. The aim of this project is to not
try and compromise the security of the password managers but to rather pre-emptively reveal
potential design flaws which compromise the user’s data.
Each tested scenario is designed to use a combination of features that is likely to be used by
an actual software user.
3.2 Software Testing
Software testing is conducted on every piece of software released. By testing software the
developers can determine how the software operates and whether it operates as required.
There are five different levels of software testing, each level is used for a different reason and
how they assess the software (Ammann and Offutt, 2008). Each testing ‘level’ includes many
sub levels, all designed to be used to test every aspect of a particular software.
Software test
Purpose
Acceptance Testing
Assess software with respect to requirements
System Testing
Assess software with respect to architectural design
Integration Testing
Assess software with respect to sub system design
Module Testing
Assess software with respect to detailed design
Unit Testing
Assess software with respect to implementation
Table 4: Table indicates the five different software testing levels, each with an explanation of what the test is
based against. (Ammann & Offutt, 2008)
Page | 44
System testing is an extension of individual unit testing, where two or more units that have
already been tested are combined into a subsystem. This allows the testing of multiple
subsystems to evaluate how well they work together and do not create any errors (Pfleeger
and Atlee, 2010).
Within System testing there are a further subset of steps which are used to conduct a system
test. These steps include (Pfleeger and Atlee, 2010):

Function Testing

Performance Testing

Acceptance Testing

Installation Testing
Function Testing
Functional testing can be split further into either functional or non-functional testing.
Functional testing is the process of seeing what the software does. In other words, testing
features and scenarios based on test cases and system requirements (Veenendaal & Evans,
2008).
Non-functional testing is the process of testing how well the software or system does
something. The two types of functionality testing are used to evaluate the effectiveness of the
particular software (Graham, Veenendaal and Evans, 2008)
Performance Testing
Performance testing is designed to test the systems availability, response time, throughput and
utilisation. Performance testing ensures the software or system works as well as possible and
if there is an error or problem it can be flagged for repair (Molyneaux, 2009)
Acceptance Testing
Acceptance testing is used as a formal test to determine whether the software’s system
satisfies its criteria. Acceptance testing is also used as a chance for the buyer to examine the
software and ask for changes or corrections to be made before release (Maidasani, 2007).
Installation Testing
Installation testing focuses on combining the software to test how it well it works in its
production environment. By testing this, the software is shown to work as intended (Everett
and McLeod, 2007).
Although there are many different kinds of software testing, each type is used to test a
different aspect and area of a piece of software. Unlike a full software testing project, this
Page | 45
project will focus on the functionality of the features in relation to possible security
weaknesses, which may be exploited. Once each experiment has been completed, a digital
forensic investigation will be carried on the virtual machine to establish the results of each
scenario. The digital forensic investigation will reveal the outcome of each experiment and
then compared against the expected outcome.
3.2.1 - Software testing methods
There are two types of software testing methods. There are black box tests and white box
testing. Black box testing is used when the inner workings of the system or software is
irrelevant to the investigator. The point of using a black box method is that the tester is only
interested in reviewing the data output resulting from selected inputs (Myers et al., 2004)
Performing a black box test attempts to uncover any external errors in the external behaviour
of the software by testing the functionality through a series of experiments (Williams, 2011).
Input
Executable Program
Output
Black-Box Test
Figure 1: Black box testing process phase adapted from (Williams, 2011).
A white box method however is used when the tester needs to take into account the inner
mechanisms of the software. In these cases the testing is usually done on the software code to
fix an error of raise efficiency. In most cases it is more desirable for the tester to not be the
coder for the software so that he/she may see errors which have been mistaken by the original
software designer (Williams, 2011).
3.3 - Test case Anatomy
Feature testing can involve a significant number of features for a highly complex piece of
software. Each feature has to be tested to ensure it acts as required, for release. To reduce the
number of tests that have to be completed testers use special graphs that help create a series of
scenarios that need to be tested which include using as many features as possible. Testers use
‘cause and effect’ graphs and decision tables to map the logic of the software which then
Page | 46
helps discover any potential errors. Although these graphs are commonly used when planning
each scenario, this project is not testing the features associated with the chosen password
managers and thus cannot proceed along the same course as a normal tester (Pfleeger and
Atlee, 2010).
Besides not testing every feature of each password manager, the actual testing will be done
following a digital forensic framework. By doing a digital forensic investigation, the full
impact that each scenario has on a user’s computer will be revealed. Unlike traditional testing,
this project will be able to look in detail at the full impact each scenario has and provide a
point of view that is uncommonly used.
Adhering to how test cases are shown using a black-box approach the investigation will be
conducted from the point of view of an average user. Each experiment will be conducted in its
own testing environment, guaranteeing that it does not become contaminated from previous
experiments. Once each scenario has been devised it will be placed in a table adjacent to a
column displaying the predicted result. Once each test has been carried out and had a forensic
examination conducted, the final results will be placed to the right of the predicted results.
This will either confirm or deny whether the software acts as it should.
Test ID
Description
Expected Results
Actual Results
Table 5: : showing the template of each scenario test case adapted from (Williams, 2011).
Table 5 displays how each of the scenarios will be shown throughout the scenario planning
section except for the actual results section that will be discussed in the analysis and results
section. Each scenario will be shown in its own table alongside a short description of what
that scenario will be looking for and the reasoning behind it.
3.4 Digital Forensic Framework
The following models are all appropriate to use for each experiment investigation however,
from the frameworks discussed a further examination of a chosen framework will be done to
show how it will be used in this project.
3.4.1 Analysis of existing models
3.4.1.1 Event-Based Digital Forensic Investigation Framework
An event based framework consists of five major categories of phases. Each category has a
different number of sub phases.
Page | 47
Figure 2: Graphical representation of the five major categories of the framework phases adapted from (Carrier &
Spafford, 2004)
Readiness Phases
The readiness phase includes two sub phases, the operations readiness phase includes the
training of appropriate people and so that the investigation can be carried out. The
infrastructure readiness phase is used to configure the testing equipment to guarantee that the
tools are ready to gather the data (Carrier and Spafford, 2004).
Deployment Phases:
The deployment phase includes the sub phases, detection / notification phase and
confirmation / authorisation phase. The detection and notification phase is used to include the
detection of the incident. For example a network intrusion will be detected by a network
monitoring system. The confirmation and authorisation phase is where the investigator
receives the authorisation to begin the investigation; different scenarios need different levels
of authorisation. For example a private company may need to get legal authorisation before
commencing whereas a governmental organisation may not need to (Carrier and Spafford,
2004).
Physical Crime Scene Investigation Phases
After the authorisation has been given the next step is gathering the physical evidence in order
to be analysed. If any digital evidence is found the next step is to begin the sub phases to
search for any evidence pertaining to the case. Each of the sub phases are explained in the
next section (Carrier and Spafford, 2004).
Digital Crime Scene investigation Phase
The criminal investigation phase is split into a further three phases that are used to account for
each possible type of digital investigation.
Page | 48
Presentation Phases
The presentation phase is used to display the findings of the physical crime scene
investigation phase. The data is shown in the appropriate format for that particular
investigation (Carrier and Spafford, 2004).
Figure 3: Digital crime scene investigation sub phases adapted from (Carrier & Spafford, 2004)
System Preservation and Documentation Phase
This phase is involves preparing the digital evidence for the investigation that can be used in
court. To guarantee that validation of the digital evidence either a MD5 or SHA-1 Hash is
calculated to show the evidence had not been tampered with (Carrier and Spafford, 2004).
Evidence Searching & Documentation Phase
Once the evidence is preserved the digital investigation phase is split into a further four
phases. These phases are designed to help the investigator search for specifics. The four
phases are described below in a graphical representation.
Figure 4: Evidence searching phases adapted from (Carrier and Spafford, 2004).
Page | 49
Once the evidence has been preserved it can then be examined. The goal of this phase is to
recognise digital objects that could contain useful data relating to the case. Searching is
conducted in a four phase process as shown in figure 3; the first phase is designed to define a
target that will be searched for. For example if you knew to look for a file named
(evidence.txt) you could conduct the search for that specific file (Carrier and Spafford,
2004).The second phase is to then extract the data from the crime scene using a particular
search pattern; the third phase is to then compare the extracted data with the target data. Once
the data has been located the general knowledge of the case is updated so that a further data
can be located (Carrier and Spafford, 2004).
The next stage of the investigation is to convert the state of the objects into events. For
example if a piece of evidence was found in the cache of the system, the next step is to
hypothesise how that information ended up there, whether the web browser placed it there or
possibly another program. The goal of this process is to examine every individual piece of
evidence to determine the cause of event that caused the piece of evidence to arrive.
As shown in figure 2, the last step in the event driven framework is the event reconstruction
and documentation phase. This phase is split into a further five phases as shown in figure 4.
Figure 5: Event Reconstruction Phase adapted from (Carrier and Spafford, 2004).
The examination phase involves identifying of each object by its characteristics and
individualised by their individual characteristics. Once completed, the second phase is to
Page | 50
examine each characteristic of every object identified and create a hypothesis of what role that
objects played in the overall case. For example the examiner could identify that a program file
on the system had been used to create an open network connection, that connection could
have then created an event which triggered the need for the investigation to take place.
Once every object has been examined and all possible roles noted the next phase groups
events together. Cause and effect roles are grouped together so that if an effect requires
certain other events to have occurred those events are also searched (Carrier and Spafford,
2004).
The fourth phase creates event chains based on their occurrence; some objects contain
temporal information that can combine two events to create a sequence. Other objects contain
functional information that can be used to determine if one event needed to be created before
another. For example data has to be downloaded from a browser before it can be saved to disk
(Carrier and Spafford, 2004).
The final phase of the event based framework tests the hypothesis that have been created from
the analysis of the joining events. The hypothesis has to be created based on the objects that
have been located, if a hypotheses is being tested where not all objects that are required have
been found then other hypotheses, where all or more of the objects have been found must be
deemed the more likely (Carrier and Spafford, 2004).
3.4.1.2 Hierarchical Object-Based Framework (HOBF)
A hierarchical object based framework is a framework that includes all of the phases outlined
in section 3.3.1 .1 however, unlike an EEDI framework the HOBF has six phases all of which
make up the first tier of the framework. The first six Phases present the generalised process of
the investigation model as shown in figure 5 (Beebe and Clark, 2005).
Figure 6: first tier phases of the Hierarchical Object-Based Framework adapted from (Beebe and Clark, 2005).
Preparation
A preparation phase is required in any digital investigation process. The preparation phase
focuses on minimising the risk to the digital evidence becoming destroyed or resulting in a
loss of data. Preparation activities include but not limited to:

Assess risk considering threats/exposure and vulnerabilities to the digital evidence.

Develop information retention plan (both before and during incident)
Page | 51

Development of technical capabilities, creation of toolkits and other forensic software

Training of personnel in digital forensic techniques

Preparation of network and host devices

Develop evidence preservation and handling procedures

Document results of activities and

Develop legal coordination plan with authorities both before and during investigation
Incident Response
The incident response phase is designed to be a pre- investigation phase to both detect and
validate a suspected security incident. The purpose of this phase is to create a strategy for
assessing, validating to the suspected incident (Beebe and Clark, 2005). This phase includes
but limited to:

Detect or suspect unauthorised activity

Report the suspected activity to the proper authority depending on the actual activity

Validate the incident to justify an investigation

Assess the damage resulting from the incident; this may include interviews of
technical personal, review of pertinent logs and review of the network topology.

Coordinate, as applicable with various departments including human resources, law
enforcement, managerial persons and

Formulate the initial investigation plan for the correct method of the collection and
analysis of data.
Data Collection Phase
Once the incident has been validated and a forensic investigation has been deemed necessary
the next phase is to collect the data that was not already collected during the initial
investigation phase. This data would be used to validate the investigation. The purpose of this
phase is to gather all the relevant data to support both the response strategy and investigation
plan (Beebe and Clark, 2005). This phase includes but not limited to:

Complete “live response” data collection which was generally started during the initial
investigation phase.

Obtain network based information from application which includes, intrusion
detection systems, routers, firewall records and log server data.

Obtain host based data from application, this includes volatile data, system time/date
information etc.
Page | 52

Obtain any removable media including USB’s, CD-ROMs and flash memory devices

Install activity monitoring capabilities e.g. surveillance cameras and system monitors.

Ensure the integrity of the data by using write blockers and creating hash values of the
data.

Package and transport and store the digital evidence for further analysis
Data Analysis Phase
The purpose of the data analysis phase is to either confirm or refute allegations of
suspicious activity and/ or event reconstruction to answer “who, what, where, when, why
and how” type questions. The data collected during this phase is surveyed, extracted and
reconstructed (Beebe and Clark, 2005). The data analysis includes but not limited to:

Transforming the large amount of collected data gathered during the data collection
phase and processes it into a more manageable size and form for the analysis.

Conduct initial survey to recognise the obvious pieces of digital evidence and assess
the level of the suspect(s).

Employ a data extraction technique including keyword searches, extraction of
unallocated space and file timeline/ mapping.

Examine/analyse and event reconstruct the data to answer the critical investigative
questions
Presentation of Findings Phase
This phase is used to communicate the findings to the various audiences in a way that will be
understood by each different audience regardless of their backgrounds. For example a digital
forensic report may use terminology that is unknown to various departments which may mean
a verbal report may result in a larger understanding than a written report.
Incident Closure Phase
The purpose of the incident closure is to follow a four phase process; this is done following
these steps:

Conduct a critical review of the entire process and investigation to identify and learn from
the lessons gained from this investigation.

Make and act upon decision(s) that resulted from the findings and presentation phase.

Dispose of the evidence (e.g. return to the owner, destroy clean and re-use all as
applicable and legally permissible.
Page | 53

Collect and preserve all information related to the incident for later examination if needed.
Second-Tier Phases
Unlike other digital evidence frameworks, the Hierarchical Object-Based framework
incorporates a second tier phase framework. By implementing a second tier of phases, the
framework can be adapted to almost any type of digital investigation. Whilst the objectivesbased sub phases (OBSP) will remain mostly consistent from situation to situation the specific
tasks that populate the sub phases will vary from each different situation depending on the
objectives sought after in each situation (Beebe and Clark, 2005).
Figure seven displays the graphical representation of both tiers.
Figure 7: The first and second tier phases adapted from (Beebe & Clark, 2004)
An example of what the sub phase may look like for the data analysis phase can be seen in
figure 8
Page | 54
Figure 8: Data Analysis sub-Phase example adapted from (Beebe & Clark, 2004).
Figure 8 shows what a sub-phase may include, each phase is divided up into surveying the
data, extracting the data and examining the data.
3.4.1.3 Common Forensic Process Model
The common process model is a combination of both incident response and computer forensic
process model. This is the third possible model that could be applied to this project. The
common model for incident and Computer Forensic is a combination of two similar models.
The incident response model is used for planning ahead of time before an incident can occur.
This involves making sure that there is a plan in place for the possibility of an incident so it
can be handled in a systematic and well-organised way (Freiling and Schwittay, 2007).
Page | 55
The common process model for an incident response and computer forensic investigation is
split into three areas. These areas are the pre-Analysis, Analysis and Post-Analysis phase.
Each phase can be seen in figure 9.
Figure 9: Common Forensic Process model stages adapted from (Freiling and Schwittay, 2007).
Pre-Analysis Phase is the phase where all of the steps and activities that are performed before
the actual analysis of the device occur.
Analysis Phase is where the actual analysis of the device occurs. During this phase data is
gathered and recorded.
Post-Analysis Phase follows from the analysis phase. During this phase each of the recorded
data is gathered into a report that can then be used in a court of law.
Now that each of the three phases has been briefly explained, the next section goes on to
discuss the individual steps that each phase has.
Page | 56
Pre-Analysis Phase
The pre analysis phase contains all of the stages that happen before that actual examination of
the any of the devices can commence. As figure 10 shows, there are three main steps in the
first analysis phase. These are the Detection of Incidents, Initial Response and Formulation of
Response Strategy (Freiling and Schwittay, 2007).
Figure 10: Pre-Analysis phases of the common forensic process model. Adapted from (Freiling and Schwittay, 2007)
Detection of Incidents
This step involves creating proper incident detection guidelines for the eventuality that an
incident may occur. Incident Detection usually occurs once a person or security mechanism
has recorded suspects that an unauthorised or unlawful action has occurred involving a
computer or network. The guidelines include whom to contact in case an incident occurs and
how to react to a given situation. By having a set of guidelines in place certain information
can be recorded instantly. This information includes the time and date of the detection. This
data is crucial for a full forensic examination to commence (Freiling and Schwittay, 2007).
Initial Response
During the initial response step, the goal is to confirm that a suspicious incident has occurred.
Once it has been confirmed, the type and scope of the incident should then be determined.
This is done to create a suitable response strategy. Containment of the incident is also
necessary to reduce the damage done to the company or user (Freiling and Schwittay, 2007).
Page | 57
In a network based investigation, networking monitoring will most likely be in operation
which can then be used to confirm an unauthorised incident and possible collect additional
data.
Once an incident has been verified, the data gathered around the incident can be used to
estimate the initial impact on the users systems. All of this information can then be used to
formulate an effective response strategy (Freiling and Schwittay, 2007).
Formulation of Response strategy
The goal of this stage is to determine the best response strategy for the particular security
issue.
Deciding on the best course of action can be determined on a number of different factors.
These factors include the potential perpetrators, apparent skill level of the attacker, potential
downtime caused by the incident and the monetary loss. All of these need to be taken into
account when determining how best to proceed. This stage is also accountable for deciding on
whether to conduct a full computer forensic investigation or not (Freiling and Schwittay,
2007).
Analysis stage
The analysis stage is complimentary to the pre-investigation phase in that once a plan has
been formulated the investigation can commence. The analysis stage has five different parts.
The first part is a live acquisition of the targeted data. This involves gathering data connected
to the incident whilst the machines are still running (Freiling and Schwittay, 2007). All of the
five stages can be seen in figure 11.
Page | 58
Figure 11: Review of the common forensic process models analysis phase, adapted from (Freiling and Schwittay, 2007).
Each of the analysis stages will now be described.
Live Response
A live response analysis is used to gather data relating to the security issue whilst the
computer or device is still powered on. This stage is used to gather data that may be changed
once the machine is turned off. For example the current contents of the RAM may be
unreadable once the machine is turned off. The live response is used to gather as much
volatile information as possible; this may include the contents of the RAM but also a list of
the current open network connections. The rest of the analysis phase is done on a ‘dead’
analysis. This means the investigation proceeds on a machine that has no power to it so no
data can overwritten or changed (Freiling and Schwittay, 2007).
Forensic Duplication
Forensic duplication refers to the creation of a bit by bit copy of the original device to make
sure that the original evidence keeps is integrity. This is also used to start a chain of custody
to record where each device is being held at any time (Freiling and Schwittay, 2007).
Data Recovery
Data recovery refers to attempting to reconstruct the data that cannot be initially analysed.
This includes deleted files and partitions, damaged, hidden or otherwise inaccessible data
(Freiling and Schwittay, 2007).
Harvesting
During this stage, the Meta data connected to the investigation is gathered. This metadata
includes file names, file types, file sizes etc. This stage can be structure the unorganised
material based on certain criteria. This includes timestamps, permissions and other file
attributes. This information can then be useful later in the investigation when viewed with
other data (Freiling and Schwittay, 2007).
Reduction and Organization
The goal of this stage is to disregard the data that is unimportant to the actual case. The aim of
alleviating the unnecessary data is to reduce the total amount of uncovered data so that the
important data can be analysed effectively (Freiling and Schwittay, 2007).
Analysis
Once all of the stages have been completed in the analysis phase, the next step is to begin to
attempt to reconstruct the events that led to the compromise of the system. The overall aim of
the analysis phase is to work out the possible perpetrator, the means, motive and opportunity
Page | 59
that lead to the compromise of the security which created the incident (Freiling and Schwittay,
2007).
In an attempt to answer these questions, the investigation should be analysed scientifically,
meaning each theory presented about the case should be attempted to be disproved until the
actual likely theory is the only one left.
During the course of this stage each process needs to be repeatable which means keeping an
accurate recording of every step and process that is carried out during the course of the
investigation. This will then lead into the post-analysis phase where the theories are
documented which can then be presented in court if necessary (Freiling and Schwittay, 2007).
Post-Analysis Phase
This final phase of the common forensic process model is the post-analysis phase that begins
once all of the previous areas have been completed. The final steps can be seen in figure 12.
Figure 12: Post-Analysis Phase steps adapted from (Freiling and Schwittay, 2007)
Report
The reporting step is used to write down the precise report that describes the incident in detail.
The report is to be aimed at a non-technical audience so that it can be admissible in a court of
law if necessary. The report should contain every area of the investigation which then creates
a comprehensive overview of the whole case. Key areas of the case should also be pointed out
especially when they relate to the suspected resulting factors of the incident (Freiling and
Schwittay, 2007).
Page | 60
Resolution
The resolution phase is done outside of the actual case. Once the case has been finalised the
causes of the incident should be solved from re occurring in the future. This could involve reorganising the security placed on the system to deal with the new issue or to rethink the
current system (Freiling and Schwittay, 2007).
Chapter 3.4 - Chosen Framework
Section 2.7.3 highlights the importance of following and adhering to a pre-determined digital
forensic framework for the evidence integrity and essential for case re-examination. After
evaluating multiple digital frameworks, it has been decided that the Event-Based framework
is the most suitable choice of framework to use for this project. The two other forensic
processes cannot be used for this project. The Hierarchical-based process model is more
effective on a generalised project where the target data is unknown. This is not useful for this
project as the only data that could be located will be the data entered into the password
manager. The third process model is also unsuitable for this project because of the
generalisation of the process model itself. Unlike the event-based process model, the common
process cannot be altered to only focus on the important areas that are known to have been
impacted.
Each experiment will require a different method of investigation, unlike a normal forensic
investigation this project can focus its searching on the data entered and what areas are most
likely to be impacted. As previously mentioned in section 3.3.1.1 the digital investigation
phase of the Event-Based framework relies upon first searching through the digital image. If
anything is then located, the evidence can then be analysed to discover how that data became
compromised.
3.4.1 Framework Design
This section will describe how each section of the Event-Based Framework that will be used
for the each of the investigations.
System Preservation and Documentation Phase
The system preservation phase will be used to create Hash values of every investigation that
takes place. The hash values will be used to show that the evidence has not been tampered
with and prove the validity of the investigation.
Evidence searching and Documentation Phase
Page | 61
The first phase as shown in figure 4 is the target definition, the target of every investigation
will be the data that has been entered into each of the password manager. For example if the
master password is chosen as a method of securing the information the master password can
then be used as a target for searching.
Data Extraction and Interpretation
Once the target data has been identified the next stage is to evaluate the characteristics of each
identified object to help create a hypothesis of what role it played in the crime. As the purpose
of this project is to identify any potential security issues and to not reconstruct a crime this
phase of the investigation will be used to examine of the characteristics of any uncovered
data. Once uncovered and analysed the next step will to create a hypothesis on how that data
became a potential security threat.
Data Comparison
This phase is used to create cause and affect roles. For this project this phase will try and
determine how if any data found managed to become discovered. For example if a piece of
data was found which should be protected using the software this stage will attempt to
determine the reason for it becoming discovered.
Knowledge Update
This stage of the framework will be used to document the devised hypothesis of each
investigation which includes the hypothesis of how that data became vulnerable.
The next stages of the framework do not apply to this project as they are to finalise and join of
every hypothesis into a document that can be used in court. Unlike a normal forensic
examination, this project only focuses on discovering what information can be found and not
doing an overall investigation.
Page | 62
Chapter 4 - Experiment Design
4.1 Introduction
The experimental design section will look at the features offered with each password manager
and aim to create scenarios to test specific features. This section will be split into three parts.
The first will discuss how the experiment scenarios are following the methodology chosen in
section 3.2. The second stages will determine the environment of each scenario. For example
explaining why a virtual machine is best suited over using a regular machine. The final stage
of this section will discuss individual experiment scenarios, each scenario will be shown in
the layout of table 5.
4.2 Scenario Design
By using a black box methodology designed for software testing the scenarios devised can be
accomplished without requiring knowledge of the code that makes each password manager as
discussed in section 3.1.2. Each scenario will be utilising the features of each manager to
simulate a typical user activity, for example one scenario experiment may involve using the
print feature to simulate a user wishing to have a hard copy of their database. Using Encase
will reveal give a clear picture of the impacts that each scenario has had on the computer, any
unexpected data that can be retrieved from a forensic examination will be analysed based on
whether the retrieved data poses a risk to the user.
4.2.1 Experiment environment
Each experiment will need to be done in a secure environment so outside influences do not
influence the results in anyway. For this reason, each password manager will be installed on
its own virtual machine, by doing so, the environment can be controlled. There will be three
main virtual machines; each VM will contain a different password manager. Every tested
scenario will be done on a clone of the original VM. For example KeePass 2.x will be
downloaded using a Windows 7 operating system; a clone can then be made of the original
that will then allow an experiment to be conducted onto it without altering the original. By
doing this, it reduces that amount of VMs that need to be created whilst still keeping the
integrity of each experiment.
The properties of each virtual machine, the process of creating and cloning each virtual
machine can be found in appendix 2.
Page | 63
For the purpose of keeping each investigation fair, the virtual machines used will all be done
using the same specifications. Each VM will use the recommended standard which can be
seen below:

Windows 7 Operating System

1 processor

60GB hard disk space

1 GB of RAM (1024 MB)

Stored as a single file
A visual representation on the virtual machine specification and the process used to create
the VM can be found in Appendix 2.
4.3 Experiment design
Local password managers have been chosen as the focus point of this project because of the
lack of previous experiments done on them of this type. As mentioned in section 2.6.
Each experiment will be testing whether the resulting impact can be used against the original
user and pose a potential risk if a similar experiment is ran by a malicious user rather than a
forensic investigator. The only features tested on each password managers are ones in which
have an effect outside of the protection of the software itself. For example KeePass has the
feature of allowing users to export into three different formats, these are XML, HTML and as
a XSL style sheet. The exported document may no longer be under the protection of the
software or possibly be un-readable to a forensic examination. Although the tools used in this
project are specialist tools, as discussed in section 2.8 there are freeware tools that can
conduct the same style of investigation.
4.2.1 KeePass 2.x
Scenario 1
The first scenario will aim to test the first database protection method. A master password is
the default data protection method for every new database in KeePass 2.x. In the first scenario
there will be multiple databases, each using the same master password. The experiment is
designed to test how the software handles multiple databases with the same master password
and whether there any security weaknesses that could be exploited.
Page | 64
Inputs
Description
User Expected Results
Master Password is tested as A Database is created and A database is created and
the security method.
filled with fictitious data, filled with all the data
that
database
is
then relating to the user and
protected using the master protected
password security feature.
against
unauthorised users by a
master password.
Table 6: Scenario 1 from an average user perspective
Scenario 2
The second scenario is designed to test using a key file as the password instead of using a
master password. Unlike the master password the key file is outside of the protection of the
database which may be a security issue if the key file can be easily seen or copied.
Inputs
Description
Key file is used as the A
database
User Expected Results
is
created The key file is used instead
security method instead of a similarly to the first scenario
of a password. The database
master password.
is still accessible but does
not require a remembered
password.
Table 7: User expected outcome table of the second scenario.
Scenario 3
The third scenario will use an image file as a key file; an image file is similar to how the
password manager uses it as the security key. However, unlike a key file the image may not
have any real security besides its unobtrusiveness. The investigation carried out will reveal
whether there is any discrepancy in the image file itself which may reveal itself as a key file.
Inputs
Description
User Expected Results
An image file is used as the Unlike the first key file The selected image is the
protection
password.
rather
than
a used, the second key file only way of accessing the
will be an image file.
current
database.
The
security Is equivalent to
either a master password or
any other type of key file.
Table 8: User expected outcome table of the third scenario
Page | 65
Scenario 4
The fourth scenario involves using the Windows user password as the secure password as a
method of protection. Unlike other types of password security the use of the windows
password may require the software to copy the password itself which may be left unprotected
depending on how the software chooses to protect the password.
Inputs
Description
User Expected Results
The Windows user password By using the Windows user The password is set as the
is
used,
the
Windows password for the database login password which means
password means that no security the user will not no
other password is required.
other
password
is
have to remember any other required to access any of the
password aside from their data.
login password.
Table 9: User expected outcome table for the fourth scenario
Scenario 5
Scenario 5 will examine the exportation feature which allows complete databases to be moved
into a different password manager. Although these exported databases are designed to be
temporary it is still important to uncover how protected the exported files are. The relevancy
to this investigation is to see how well protected the databases are against possible attacks or
spyware on the machine.
Inputs
The
Description
created
database
is The
used
User Expected Results
database
is Upon exporting the database
exported using each of the exported using each of the it will be shown in each of
available
formats.
These different exporting options the formats requested. For
formats are: HTML and to determine what data is example
XSL formats as well as readable
other KeePass safe formats.
without
exporting
the
being database as an html format
protected with the master the document will show the
password.
database in the main used
browser.
Table 10: User expected outcome table for the fifth scenario
Scenario 6
One option for exporting a database is into a HTML file, the HTML file when opened is
displayed in a browser. The sixth scenario will open the HTML document in the Chrome
Page | 66
browser. The following investigation will examine whether any residue data is left within the
browser whether it be cached or left in some other area of the computer.
Inputs
Description
User Expected Results
The HTML exported file is This scenario is designed to Upon opening the database
opened in a web browser.
determine
whether
any HTML file the browser is
residue information is left launched
displaying
the
within the browser files contents of the database.
upon opening an exported However, the data within the
HTML database.
database is kept separate to
the browser to reduce any
chance of data being stored
elsewhere.
Table 11: User expected outcome table for the sixth scenario
Scenario 7
One of the most intriguing features offered by KeePass 2.x is the ability to print each database
off into a plain text format. The seventh scenario will involve attempting to print a copy of the
database but unsuccessful. As mentioned in section 2.6.3.1 once each database is printed it is
then deleted off of the system by the software itself. If however, the printing failed to
complete it may result in the software being unable to delete the requested data.
Inputs
Description
User Expected Results
The database is requested to The contents of the database Database is printed to get a
be printed but cancelled has been requested to be hard copy of the data stored
before
the
completed.
job
can
be printed it will be cancelled within the database.
before the database can be
printed.
Table 12: User expected outcome table for the seventh scenario.
Scenario 7.2
Scenario 7.2 is the opposite of the previous experiment. 7.2 will examine the aftereffects of a
successfully printed database, as this scenario is an extension of the previous the same VM
will be used. This means that the residue information on the first experiment will be left on
the new one. By using this method, a realistic scenario of a user attempting to print and then
successfully printed can be analysed.
Page | 67
Inputs
Description
User Expected Results
The opposite experiment of Unlike scenario 7 during this Database is printed to get a
the seventh scenario that scenario the database is hard copy of the data stored
uses
the
same
virtual successfully printed.
within the database.
machine to test whether any
remaining data is left after
the successful printing.
Table 13: User expected table for the eighth scenario
Scenario 8
The final scenario is to simply delete the software from the system in its entirety. By deleting
the software a clear picture of what information if any is left on the machine.
Inputs
Description
User Expected Results
Complete deletion of the The software is completely Once the user has requested
software from the virtual deleted from the computer to the software be deleted all
machine.
analyse whether any residue trace relating to the software
information left relating to apart from the databases will
the user
be removed.
Table 14: User expected table for the ninth scenario
4.2.2 Password Safe
The scenarios involving Password Safe are limited in number when compared with KeePass
as there are fewer features that impact outside of the software itself. Unlike KeePass,
Password Safe does not allow a database to be printed and does not give the option of
presenting the contents of the database in the form of a HTML document.
Scenario 1
The first scenario is the same as the first scenario for KeePass 2.x. The difference between
them both is that unlike KeePass, Password Safe only has the option of using a master
password as protection. Because of this, testing the security behind the master password is
especially important. The experiment will look for any data that may not be as protected as it
should be.
Inputs
Description
User Expected Results
Database is created and Database is created and New database is created and
populated using a master populated
with
fictitious protected using the master
password as the security data. The database is then password function.
Page | 68
function.
protected using the standard
password manager.
Table 15: User expected table for the first Password Safe scenario
Scenario 2
The second scenario will attempt to export a database into every format available to determine
how vulnerable they are to the user.
Inputs
Each
Description
of
the
User Expected Results
exporting Each exporting option is Each
tested
export
will
features are used and saved used to determine whether produce a different virtual
onto the computer.
there is any insecurity in the record of the database.
exporting feature.
Table 16: User expected table for the second Password Safe scenario
Scenario 3
The third scenario will use the clipboard feature. As mentioned in section 2.6.4, the feature
allows the user to momentarily copy their password or username which can then be pasted
elsewhere. This experiment will use the feature but force the machine to shut down
prematurely to determine if any information will become vulnerable.
Inputs
Description
User Expected Results
Utilising the feature of being IS Data is added into a safe Creates a safe note which
able to copy text to the ‘clip note which will then be will then allow the user to
board’ for easy entering of copied to the ‘clip board’.
paste into another document
data into different fields.
if needed. The copied data is
still located in the password
manager however.
Table 17: User expected table for the third Password Safe scenario
Scenario 3.2
Scenario 3.2 is an extension of scenario 3 except it will use the previous VM but shut down
normally. The data will then be compared to the results of scenario 3, the test will determine
whether there is any insecurity brought on by the first scenario and if the correct shut down
method has solved them.
Inputs
Description
User Expected Results
The contents of a safe note During this experiment the Data
copied
onto
the
is copied to the clip board data is copied however a clipboard is going to be used
Page | 69
however, a false shut down simulated forced shut down however
a
unplanned
of the computer means the occurs. The corresponding shutdown occurs before the
data could not be pasted.
investigation will analyse data can be used.
whether any data is located
in the cache.
Table 18: User expected table for the second third Password Safe scenario
Scenario 4
Similarly to the final scenario in KeePass, the final scenario using Password Safe is the
complete removal of the software, without the software the data connected to Password Safe
may be compromised or possibly not all of the data connected to Password Safe may be
destroyed which may present possible risk.
Inputs
Description
The software is completely The
User Expected Results
scenario
surrounds All data related to the
removed from the virtual whether any data is left on software disappears apart
machine.
the machine after being from the expected databases
uninstalled.
which
are
left
on
the
desktop.
Table 19: User expected table for the fourth Password Safe scenario
4.2.3 RoboForm
Scenario 1
The first scenario was designed to test whether RoboForm is similar to KeePass that when
faced with a limited amount of RAM available on the computer. The experiment will see
whether the password Manager will be forced to send data to the page file or whether it will
still be able to protect the information.
Inputs
Data
Description
is
added
to
a This
User Expected Results
scenario
tests
the After the input of each
RoboForm database using security of the password identities the computer will
every possible field. Three RoboForm when provided be shut down as normal.
identities will be added to with
the database.
large
amounts
of
fictitious data with a limited
amount of RAM.
Table 20: User expected table for the first RoboForm scenario
Page | 70
Scenario 2
The second scenario is designed to test the printing feature offered by RoboForm. Unlike the
feature offered in KeePass, RoboForm allows each sub feature to be printed individually, for
example a user can print any or all of their safe notes or an individual contact. The scenario is
evaluating whether the printing feature securely deletes the data after being printed or if any
residue data is left behind in either the printer spooler or another area of the computer.
Inputs
Description
User Expected Results
Print feature is used on the The selected database will The user requests a physical
current database.
be requested to be printed. copy of the database.
This scenario is used to test
whether
information
any
residue
could
be
potential security risk.
Table 21: User expected table for the second RoboForm scenario
Scenario 3
The third experiment explores how the password manager exposes information in a plaintext
format when using the auto complete function offered RoboForm. As mentioned in section
2.6.5.1 KeePass’s auto fill feature is used for user convenience however, if that data is cached
or placed in an unsecure format it may become compromised.
Inputs
Description
User Expected Results
The auto complete form The scenario simulates the Upon
feature is applied.
navigating
to
the
user wishing to use the website ‘Hotmail’, the user
autocomplete feature.
makes use of the auto
complete
feature
to
automatically log on to the
website.
Table 22: User expected table for the third RoboForm scenario
Scenario 4
The fourth scenario is similar to the third in that it is testing how the password manager
protects data that has been copied onto the clip board by the user. The Safe Note feature as
mentioned in 2.6.5.1 is a feature used to keep safe written text by the user. For example the
user may choose to have their bank code as a safe note however, by using the additional
Page | 71
feature of copying all of the text within a safe note it may cache the data in an unprotected
format.
Inputs
Description
User Expected Results
Data of a tested safe note is Copying the data onto the Any database coped to the
copied onto the clipboard clipboard will test whether ‘clipboard’
using the offered feature.
will
allow
the data becomes cached as pasting of the text wherever
other password managers do required.
or protected.
Table 23: User expected table for the fourth RoboForm scenario
Scenario 5
The final scenario for RoboForm is designed to test whether deleting the software actually
erases all of the data associated with the user or if any residue data still resides upon the
computer.
Inputs
Description
User Expected Results
The complete removal of the The scenario will remove Once
software
the
software
from
RoboForm
is
no
the longer needed the software
computer to analyse whether will be deleted from the
any
data
left
on
the computer.
computer can compromise
the security of the data.
Table 24: User Expected table for the fifth RoboForm scenario
4.4 Limitations
Each of the experiments discussed for this project have been aimed at looking at the external
impacts that they have on the machine running it. There are limitations to the data that can be
analysed using these experiments. For example the features offered to users on a network
scale are not explored nor are the effects that multiple users have when access is shared. The
experiments are also designed to be done on a Windows 7 computer and no other operating
system; this may narrow the actual results whereas using multiple Operating Systems may
reveal more about the software.
The final limitation to the investigations carried out in this project is the experiment
environment. Although using the same spec throughout every experiment retains the fairness
of every experiment it does limit the final results. Another spec of computer may reveal a
different set of results each time.
Page | 72
Chapter 5 - Analysis and Results
5.1 Introduction
The analysis and results of every investigation will be discussed in this section. Each
investigation has been carried out according to the framework discussed in section 3.4. The
hash values of every experiment can be found in the corresponding appendix alongside the
print screens of every step that was carried out. For example the Hash MD5 for the first
KeePass experiment can be found in section b.1 located in the appendix section.
As the framework in section 3.4.1 demonstrates, the aim of this section is to display the
results of every experiment, discuss the potential ramifications of any unexpected uncovered
data and to finally reconstruct the events that led to the information being discovered. As
mentioned in the Data Extraction and Interpretation phase of the chosen framework, a
hypothesis will be created to attempt to answer how the target data became a potential ‘flaw’
in the security of the password manager.
Each examination will be shown as separate scenarios; this will make reviewing the results of
each experiment easier. Once each of the experiments have been carried out a summary of the
password manager will be done, the summary will take into account all of the experiments
conducted and all of the data that has been gathered about the password manager.
5.2 KeePass 2.X
5.2.1 Scenario 1
The first scenario was designed to test the master password security however, surprisingly the
scenario revealed more about KeePass than originally intended. The experiment revealed that
under certain circumstances KeePass can accidently place a master password within the page
file of the hard drive. A page file is normally used as an extension of the computers random
access memory (RAM) for when software requires more RAM than the computer has (Rouse,
2005).
Not only was the master password stored within the page file it was stored in plain text. After
an investigation into this problem it became clear that it had already been reported in 2010
using KeePass 2.13 (Sourceforge, 2010). The only similarities between the issues rose in 2010
and now, are that Windows 7 has been used as the operating system.
Page | 73
Beside the placement of the master password within the page file, upon a search of the image,
it revealed that one of the entries entered into KeePass was moved to an unallocated cluster of
the image. The data stored within the unallocated cluster included the username, password
and email, with the use of specialist software this information can be easily viewed for a
malicious user who is intended on finding as much information as they can.
The information acquired from the experiment carried out on the first scenario concluded with
a surprising discovery. KeePass is software specifically designed to protect the integrity of the
information entrusted to it by the user. The repercussions of the data recovered during this
particular scenario could potentially be very damaging to the owner of the data. The data
uncovered from the first investigation would be enough for a malicious attacker to gain access
to every piece of data stored in the database; the master password was assigned to. Besides the
discovery of the master password, the information stored within the unallocated clusters could
be all a malicious user needs to falsely appear as the rightful owner of the associated account.
Possible sources
This scenario revealed that when presented with a computer with a low amount of RAM
KeePass uses the page file of the computer as a way of compensating for the lack of RAM.
The data sent to the page file was in an unencrypted format, which if not immediately over
written will stay within the page file in plain text as shown from this experiment.
Steps of the investigation
The initial investigation of this virtual machine was done by checking each folder relating to
KeePass, unlike other scenarios, there were no places that could specifically retain data. The
initial search did not reveal any obvious signs of security issues. However by using the feature
inbuilt into Encase allowing a forensic examiner to search for ‘key words’ the discovered data
became identifiable. The use of this feature was required, as there were no immediate
possibilities of where data could be located.
5.2.2 Scenario 2
The second scenario concluded that using the key file offered as the security does provide a
high level of security above other methods. The two key files used were both secure and did
not provide any information from the database itself, as it was designed to do.
Page | 74
Steps of the investigation
This investigation followed the same steps as the previous by using the search function
available with Encase. There were no identifiable sources of data from this scenario.
5.2.3 Scenario 3
The third experiment of using an image file as a key file provided the same level of security
as the any other key file type. More importantly by using a key file, it did not display any data
that suggests that the image is being used as a key file, which is important to note.
Steps of the investigation
This investigation followed the same steps as the previous by using the search function
available with Encase. There were no identifiable sources of data from this scenario.
5.2.4 Scenario 4
Using the Windows login password as a master password did not result in any information
becoming leaked however, if the users login password becomes compromised it also means
that the database containing all of the passwords have also become compromised. For the
purpose of this investigation purpose of this experiment it did not reveal any information.
Steps of the investigation
This investigation followed the same steps as the previous by using the search function
available with Encase. There were no identifiable sources of data from this scenario. This is
because the aim was to identify any security weaknesses present in the software features and
no with the operating system.
5.2.5 Scenario 5
The fifth scenario was designed to test the exporting feature offered by KeePass 2.X. KeePass
allows the user to export a database in either a HTML or XSL format. The investigation
revealed that the HTML document resided where it was originally saved and left in an
unencrypted format. The second part of this investigation was to test whether any data was
present in the browser history files. This test involved opening the HTML file in both Internet
Explorer and Google Chrome. During the examination it appeared that there was no
information present in any of the browser history files. However, by using the search function
in Encase it became clear that along with data being stored in a HTML file, it was also stored
Page | 75
within the System Volume Information file. Although this file is kept hidden from general
users with forensic software it can be viewed with ease.
Possible Cause
It is unclear as to why there was data relating to the database stored within the System
Volume Information file, as it is usually only used as a restore point for the computer and the
scenario did not involve an incorrect shut of the PC. The data stored within the System
Volume Information file may not be immediately noticeable to the user however, a malicious
user only needs to search for certain keywords including passwords or if they know the
previous owners name.
Steps of the investigation
Unlike the previous experiments, the investigation into this scenario could be aimed at areas
of the computer where data could be linked to. For example the exportation of the database
into a HTML file may have revealed information in the browser history file. Because of this
the initial investigation was focused in both the areas of where the exported documents were
saved and the browser files.
Upon locating the data saved in the location files of the computer, the search feature in Encase
revealed the information located in the volume information file.
5.2.6 Scenario 6
The sixth scenario used a similar set up as in the fifth scenario however once the HTML
document had been opened it was deleted and stored in the recycling bin. The investigation
revealed that unlike before, the only data retaining to the exported HTML document was
located within the recycling bin. The data however, was still readable even after the recycling
bin had been emptied.
Steps of the investigation
This investigation was an additional search once the parameters had been altered. Because of
this the aim of actual searching of the computer could be focused onto the areas that had been
altered. This includes the recycling bin that had a new document sent to it.
Page | 76
5.2.7 Scenario 7
As mentioned in section 4.1.1, scenario 7 is designed to test a failed printed database. The
experiment revealed that once a database has been asked to be printed it is sent to the
computers temp file. The temp file contained the document in plain text. According to the
KeePass website, the database file is then supposed to be deleted once the printing has been
completed (KeePass, 2014). It appears that a failed print job results in the document being left
in the temp folder.
Possible Causes
The printing features is designed to delete the temporary file once it has registered the job has
been completed. However, after the examination of the scenario the residue information
revealed that a failed print job does mean the data is left in the temporary file in plain text.
This scenario shows that any failed attempts at printing the contents of the database will result
in a plain text version being left within the Temp folder. Any examination of the contents of
the temp folder may reveal the contents of the passwords and data stored within the printed
database.
Steps of the investigation
This scenario focused on the printing features offered by Keepass. Because of this the
investigation could also be focused on what was connected to the printing feature. For
instance the printer spool and the temp folder created during the actual printing. Upon
navigating to the printer spool there showed no easily identifiable data connected to project.
Navigating to the search feature however did reveal data related to this project by searching
for the name of one of the entries.
5.2.8 Scenario 7.2
Scenario 7.2 is an extension of experiment 7 but is actually includes a successful print of the
database. The expected outcome is that the software deletes the temp file once it has
recognised that the print was successful. However, to determine whether the software deletes
the previous file as well a clone of the previous virtual machine was used. The investigation
revealed however, the software did delete the successful print job but did not delete the
previous failed job. The data from the failed print request was still left in the temp file and
poses a risk to the user.
Page | 77
Possible Causes
The second experiment relating to the seventh scenario showed that even when completed, the
software does go back and delete the temporary file as it is designed to do however, as this
experiment has shown the temp file is not created to override the previous file but rather
creates a new file for each print request. The fact that the software does not override or
recognise that the previous file was still on the system could pose a risk to the user.
Steps of the investigation
Similarly to the previous investigation both the printer spool and the temp file location were
searched. Unlike the previous investigation this search could focus in on where the data was
located before rather than not knowing where to look.
5.2.9 Scenario 8
The eighth scenario examines a virtual machine that has had the software deleted from the
computer or virtual machine. After the completion of the forensic investigation the only data
relating to the software was the two remaining database that were created previously. A
second search of the virtual machine using the search option also revealed that all data had
been removed.
Steps of the investigation
As there were no clear potential sources of data on the computer a general search had to be
done. This search focused on where the database was stored and where data could still be
residing.
5.2 Password Safe
5.2.1 Scenario 1
Password Safe only provides their users the choice of using a master password as a form of
security. By conducting a forensic examination, it is proved that the master password is as
secure as it should be. Regardless of the amount of entries entered on each of the database
systems there was no leaked information or unencrypted information on the system.
Steps of the investigation
This scenarios investigation was done by conducting another general investigation on the
machine itself in an attempt to locate any potential insecure data.
Page | 78
5.2.2 Scenario 2
The second experiment revealed that although the option of downloading each database in
plain text format it did require the user to enter their master password before being able to do
so. This does increase the security of the password manager by only allowing the original user
to download their data in a plain text format.
The forensic investigation did reveal the contents of the database but that was expected since
it was saved in a plain text format. However, the v1.xformat and the v2 format were both
encrypted also as expected.
Steps of the investigation
The exportation investigation was focused on the areas in which the exported documents were
saved to. The secondary search of the machine was done by using the search featured offered
by Encase. This was done in an attempt to discover whether data could be located in an area
that would normally be overlooked.
5.2.3 Scenario 3
Copying passwords and usernames to a ‘clipboard’ is a feature that prevents key loggers and
other malicious software from gaining access to the user data. However, as the experiment
concluded, if the machine is improperly shut down either from a hard reset or crashes the data
is saved to a recovery file in an unencrypted format.
Possible Causes
The improper shutdown of the PC resulted in data being saved to the recovery file of the
operating system. This was most likely caused by the shutdown of the pc itself rather than a
fault with the software.
Steps of the investigation
This investigation focused on the cache of the machine. Upon locating cache and seeing no
immediate problems a search was done to locate any relevant information. From that the
restore folder was then further analysed.
5.2.4 Scenario 3.2
A follow up investigation revealed that from using the previous virtual machine, but using a
scenario that had a correctly shut down machine the previous stored data and the latest stored
data were both removed from the system. This shows that although the information copied in
Page | 79
the clipboard was retrievable it is unrealistic to assume that that the data would not be
overwritten once the computer has been restarted and continued to work as normal.
Steps of the investigation
As this was a continued experiment the locations of searched in the previous experiment were
searched again followed by a key word search using Encase.
5.2.5 Scenario 4
The complete removal of the Password Safe software removed all data related to the software
except for the databases as expected. The data within the databases were still kept secure. A
search of the database confirmed the security of the remaining data and the complete removal
of the software.
Steps of the investigation
As there were no clear potential sources of data on the computer a general search had to be
done. This search focused on where the database was stored and where data could still be
residing.
5.3 RoboForm
5.3.1 Scenario 1
The first scenario revealed that if the password manager is running on machine with a limited
amount of RAM it may export sensitive data to the page file of the computer. Among the
information located within the page file was a complete identity of the fictitious user. The
identity included the name, address, credit card number, pin number and the expiration date of
the card.
This scenario displayed an alarming eventuality; if a computer using RoboForm was sold
without being first checked for residue data it could result in the previous owner losing a lot
of vulnerable data. Any tests done on the computer using any of the software mentioned in
section 2.8.2 will reveal the same data as found during this investigation.
Possible Causes
This scenario revealed that when presented with a computer with a low amount of RAM
RoboForm also uses the page file of the computer as a way of compensating for the lack of
Page | 80
RAM. The data sent to the page file was in an unencrypted format, which if not immediately
over written will stay within the page file in plain text as shown from this experiment.
Steps of the investigation
As the first experiment conducted on KeePass revealed an alarming lapse of security the same
examination was run on RoboForm. The investigation used the same previous method of
searching. As the location of insecure data was unknown a key word search was done on the
data located within the database which then lead to the discovery of data being stored in the
page file.
5.3.2 Scenario 2
RoboForm’s printing feature was the aim of the second scenario. The printing feature
revealed no immediate data residue in either the temporary files or within the printer spool.
The printing job was left in the spool but in an encrypted format.
Steps of the investigation
As the purpose of this investigation was the printer records, both a search of the printer spool
and a keyword search was done.
5.3.3 Scenario 3
The third experiment third scenario tests whether any residue information is left on the system
once the autocomplete function is used. For the purpose of this test an email was created for
the fictitious data. Once a Hotmail account had been created the details were saved as an auto
safe login. The auto save login was then used on the same Hotmail account. The experiment
revealed that the only data located on the system connected to the auto login feature was the
email address of used. The email was located in multiple areas of the system in plain text.
This may not be a risk in terms of security but may concern the user about the data left on the
machine connecting them to their profile.
Steps of the investigation
This investigation focused on the cache of the system, however, after navigating to the cache
of the computer no data was recovered. A secondary key word search also did not reveal any
relevant data.
Page | 81
5.3.4 Scenario 4
The fourth scenario was aimed at analysing a virtual machine that had the safe note contents
copied to the ‘word wrap’ feature. From the examination there were no clear discrepancies in
the way in which the safe note feature were copied. It appeared the content was cached to an
encrypted folder, preventing the contents from being seeing outside of the software.
Steps of the investigation
This investigation was similar to the previous one where the cache was the aim of the
investigation. This investigation revealed the same as the previous one. There was no
identifiable data in either the cache or anywhere else.
5.3.5 Scenario 5
The fifth scenario presents no unsurprising data from the actual analysis of the virtual
machine. The only content of the data that was identifiable about the data residing on the
device was the name of the main user profile. The rest of the data was encrypted and
unreadable, the software was also un-accessible.
Steps of the investigation
As there were no clear potential sources of data on the computer a general search had to be
done. This search focused on where the database was stored and where data could still be
residing.
5.4 - Discussion
5.4.1 Introduction
This section will discuss the results from the experiments and what they mean in terms of
security. Each experiment that resulted in possible security issues will be discussed in further
detail and with examples of how the data in question could be used for malicious reasons.
5.4.2 KeePass
As mentioned in section 2.6.3 KeePass is a multi-award winning password manager that
prides itself on being both a well-respected and open source password manager. The features
offered by KeePass give their users both a high level of user-control and adaptability. The
tests conducted on KeePass were designed to create scenarios that are plausible.
The version of KeePass discussed and experimented on during this project is version 2.28 that
was released on 8th October 2014 however, on 4th April 2015 the version 1.29 was released
Page | 82
which contained software improvements. None of the improvements included anything
relating to this project.
The security issues discovered from this project range from the password manager storing
data within the page file of the computer as mentioned in section 5.1.1, to data files being left
within the Temp folder from a failed printing job as discussed in section 5.1.8.
From a user perspective KeePass is a fully functioning password manager that can effectively
manage and protect their passwords as shown in section 2.28. However, the completed tests
revealed multiple security issues, these issues including:

Unencrypted residue data stored within both the page file and unallocated clusters

Inadequate protection via the Windows login password feature

Unencrypted exportation of data

Inadequate protection during printing features
These issues have potential drastic consequences to a user who recently lost or sold their
computer with KeePass previously installed and did not format the hard drive correctly. One
correct method involves using the method degaussing; degaussing is a popular method of
destroying data on a magnetic disk by physically damaging it. This can be done using
techniques such as incineration, sander belts and hammering the physical disk
(degausser.com, 2015).
The first issue raised in section 5.1.1 shows how data can be stored in the Windows page file.
This issue can be exploited using the tool named ‘SandMan’. SandMan is a tool that is
specifically designed to create a snapshot of the Windows page file contents. By using this
tool a malicious user can read/write to the hiberfil.sys of the computer (Suiche, 2008).
The second issue shown is the insecurity behind using a windows account password as the
database password. By allowing users to rely upon their own profile data as their master
password, KeePass transfers the security behind the database to the operating system being
used. By doing so, the data stored within the user database is completely reliant on the user
password not being stolen, copied or known to any other person.
Exporting the data within the database is a feature offered by KeePass that effectively
disregards all of the security set in place as shown in section 5.1.5. Unlike either Password
Page | 83
Safe or RoboForm, KeePass does not require the user to re-enter their security data to confirm
the validity of the request. This means that any user with access to the main user account
whilst the password manager is open can export the contents of the database in a plain text
format with no record of it taking place. A secondary confirmation of the identity of the user
will increase the security behind this feature if it is required. Without additional steps put in
place KeePass exporting feature is a large security issue within the software.
The final security issue within KeePass from the experiments conducted on the features was
shown in both sections 5.1.7 and 5.1.8. The printing feature is a large security risk for
KeePass. As discussed in section 2.6.3.1 the printing feature temporarily stores data within a
temp file which then gets deleted, unfortunately the incorrect printing of the database is highly
dangerous if found by a malicious user. The more alarming result from the experiment was
that even after the database was correctly deleted during the second attempt, the first database
was stored unencrypted and easily obtainable. The second experiment revealed that even if
the user re prints a database after a first failed attempt their data is still unsecure and
vulnerable.
An unencrypted folder containing the entirety of the content of the printed database is not
even the extent of this features vulnerability; in the tested version of KeePass it did not
require the user to even provide their master password. Requesting the master password in
order to print may be an available feature offered by KeePass, but it was not default in the
tested version. Any user with access to the database can request a printed copy which may
immediately be cancelled. The cancelation can still result in the user gaining a virtual copy of
the database contents.
Overall, KeePass has shown to require modifications to the way in which their features
operate. As discussed in section 2.6.3, KeePass is used for both for businesses and private
users. The security issues discovered in this project show that software designed for security
protection has potential security issues.
5.4.3 Password Safe
As mentioned in section 2.6.4, Bruce Schneier was the lead designer of the Password Safe. As
a security expert Bruce Schneier specifically designed Password Safe to not trade security for
convenience (Schneier, 2014). Password Safe does present their users with a high level of
security, as shown in experiments done on Password Safe however; the experiments did show
Page | 84
that even Password Safe has flaws that could be exploited by a malicious user. Although only
one of the experiments revealed an issue which could still result in a potential large loss of
data:

Improper shutdown procedure resulting in exposed data when saved to the clipboard
feature.
The data located in the recovery folder of the tested virtual machine was only placed there
because of the simulated hard shut down. The data located however, was in plain text and
easily located. The insecurity in Password Safes clipboard feature poses a real threat to the
security Password Safe and the trust given to it by its users.
For example if a user had a piece of malware installed on their PC that operated when it
recognises Password Safes software being used as discussed in section 2.6.2. The attacker
could instigate a shut down and potentially gather the data stored in the recovery file.
One way in which Password Safe could solve this issue is by following RoboForm’s example
and using a secure folder to place copied data which can then be encrypted. By doing so the
data would not become vulnerable to an improper shut down attack. A second solution would
be to completely remove this feature as an option. The removal of the feature would make the
password manager more secure but decrease the functionality.
5.4.4 RoboForm
As discussed in section 2.6.5, RoboForm is both an online and offline password manager. The
aim of this project was to examine the features available locally and thus it does not extend to
examining the features online. The experiments done on the locally offered features did reveal
that RoboForm does contain a security issue within their offered features.

Placing data within the page file of the computer in a plain text format, easily
identifiable to the examiner.
Section 5.3.1 discusses how RoboForm stores data within the page file of the computer in an
insecure format. This security issue resulted in a whole ‘identity’ being shown in a plain text
format. The data stored within the page file of the computer included the user name, address,
credit card number, pin number and their email. This one experiment provided enough data to
give a malicious user every bit of information they need to completely take over the user
digital identity.
For example, if a malicious user obtained the data stored within the page file they could:

Purchase products as the original owner of the identity
Page | 85

Change important details connected to the original user such as home address by using
online services.

Commit crimes as the original user, with no connection to the malicious user it would
be difficult to prove the true perpetrator.
These are a few examples of the dangers of this information being used. As mentioned in
section 2.3, passwords are used to confirm the identity of a user. Once those passwords have
been mishandled as they have in this instance they can no longer be used for the very reason
they were intended for.
Overall, RoboForm retained a high level of security besides the insecurity mentioned
previously. One way in which RoboForm was shown to be safer than the other password
managers, was the use of an encrypted folder where any data copied to then be pasted in
another field could be stored in a secure format. This feature greatly improved the security
offered to their users.
Page | 86
Chapter 6 - Conclusion and Recommendations
6.1 Introduction
This section will examine how each of the aims and objectives at the beginning of the project
has been achieved and where in the course of the project they had been met.
6.2 Aims and Objectives
1.
“Research how different types of password managers protect the data they are entrusted
with”.
The beginning of the project involved extensive research into the past exposures that have
affected password managers. The research was gathered from different sources that
specialised in different areas of password managers that when combined gave a clear picture
on past exposures.
2. “Research past incidents and vulnerabilities that bring the security of password managers
into question”.
The gathered literature on past security exploits connected to password managers showed that
password managers had not always been successful at fully protecting the data entrusted to
them. The research also showed that local password managers have had security issues in the
past that have reduced the security they offer their users.
3. “Design test cases to evaluate features of three local password managers from a users’
perspective”.
Three local password managers were tested on separate virtual machines, each machine was
used for a different featured offered by the password manager. The tests were designed to
simulate a normal user interacting with each of the password managers. This was done to
simulate what data would be created from an average user interacting with the software.
4. “Conduct a forensic examination on main features provided to users, in order to evaluate
what, if any, residual data is left on the computer”.
Specialist digital forensic tools were used in the examination of each password manager; the
use of Encase enabled the investigation to examine the virtual machine for any residue data.
The discovered data was then discussed based on whether a malicious user could potentially
use it against the original user of the machine.
Page | 87
5.
“Evaluate the security implications of residual data uncovered by the forensic examination”.
This objective was achieved during the discussion section, the residual data was discussed
along with the potential scenarios that could result in that data being stolen or misused.
All of these objectives resulted in achieving the overall aim of the project which was:
“The aim for this project is to test local password managers and their features, to determine
if whether any residual data can be acquired by attackers and pose a security risk to users”.
In order to determine if any residue information can be located on a machine using a local
password manager each password manager was tested separately on different virtual
machines. The use of virtual machines prevented results from previous experiments
contaminating the results of the other experiments which ensure the integrity of the data.
6.3 Improvements and Recommendations
The following improvements and recommendations are highlighted as potential areas that
could enhance this project further.
6.3.1 Improvements
Throughout the testing of the password managers the virtual machine setup has remained the
same. Conducting the same tests but in a different virtual setup environment may reveal a
different result.
Beside Encase, no other digital forensic tool has been used in the evaluation of each of the
password managers. An improvement to the project would be to use other digital forensic
tools alongside Encase. The data can then be compared between what can be recovered with a
professional commercial product against a freeware tool that anyone can use.
A further improvement to the project would be to conduct the same tests but multiple times
using different data for each time, by doing each test can be compared against another to
reveal any similarities in the results.
Also it would be useful to test each experiment on different operating systems. Each operating
system requires a different version of the password manager as they work differently
depending on the systems operating system.
6.2.2 Recommendations
The Password Manager has the option of being used on a network, shared across multiple
users. This feature has not been explored in this project but may produce interesting results
when compared against an offline approach.
Page | 88
Make use of relevant extensions that could be added to the original password manager. For
example KeePass has a multitude of different plugin options that could alter the results found
in this project.
Page | 89
Chapter 7 - Personal Reflection
During the course of this project there have both positive and negative developments that
have made it both challenging and interesting to undertake. During the early stages of the
project, the original idea was to test the security behind password managers against specific
hacking software, and to analyse whether tools could harm the data located within the
password manager. These aims changed, because during the initial research stage it became
clear that the likelihood of a successful attack was slim when viewing it against the safe
guards put in place. The decision was made to alter the original idea once it was revealed that
the project was unfeasible in the allotted time frame.
The literature review proved to be the most challenging section of the report. Gathering the
literature to use was only possible by using an extensive variety of sources that were difficult
to collate. The resources used were taken from various reports, user manuals, blogs and
websites. Combining the resources required analysing each report to look for key issues that
may be useful for this project. The key issues included past exposures in password managers
and other projects designed to test the security of those managers. The literature did give a
clearer example of what areas in which this project could focus on by the lack of research in
local password managers.
During the initial investigation of the password managers the hash values of every experiment
were not showing as expected. This was eventually resolved by re running each of the
previous experiments and using a different method of acquisition and processing than the first
attempt. The incorrect processing and acquisition set the timescale back for the allotted time
for the dissertation which meant the rest of the project had to move back in time scale from
what was originally planned. The reduced time frame also meant that the rest of the project
required a strict timetable of when sections needed to be completed.
Taking into account the time frame, the setbacks and the challenges faced during the course of
this project, the organisation and time management has been were very important to manage
properly. The setbacks including the reforming of the project goal and the continuous
additions needed to each section delayed other sections of the project. Overall, the project was
both interesting and enjoyable to compete. The Result from each of the investigations was
both surprising and informative and with more time it would have been interesting to explore
further.
Page | 90
8 - References
10 TopTen Reviews, (2015). Online Password Manager Review 2015 | Best Password
Storage Manger | Cloud Password Manger - TopTenREVIEWS. [online]
TopTenREVIEWS.
Available
at:
http://online-password-managerreview.toptenreviews.com/ [Accessed 4 Feb. 2015].
AccessData, (2015). Forensic Toolkit (FTK). [online] AccessData. Available at:
http://accessdata.com/solutions/digital-forensics/forensic-toolkit-ftk [Accessed 4 Mar.
2015].
AccessData, (2015). Product Download | AccessData. [online] Accessdata.com. Available at:
http://accessdata.com/product-download [Accessed 4 Mar. 2015].
Adida, B., Barth, A. and Jackson, C. (2009). Rootkits for JavaScript environments.
In: USENIX Association. [online] Berkeley: USENIX Association, pp.4 - 4. Available at:
http://dl.acm.org/citation.cfm?id=1855880 [Accessed 11 Jan. 2015].
Afentis, (2010). ACPO Guide Electronic Evidence Forensic Science Best Practice. [online]
Afentis.com. Available at: http://afentis.com/expert-witness/forensic-articles/acpo-guideelectronic-evidence/ [Accessed 29 Apr. 2015].
Al-Fedaghi, S. and Al-Babtain, B. (2012). Modeling the Forensics Process. International
Journal of Security and Its Applications, [online] 6(4), pp.97 - 108. Available at:
http://www.sersc.org/journals/IJSIA/vol6_no4_2012/9.pdf [Accessed 11 Jan. 2015].
Ammann, P. and Offutt, J. (2008). Introduction to software testing. Cambridge: Cambridge
University Press.
Bakos, G. (2013). Password Managers. OUCH, [online] (October). Available at:
https://www.securingthehuman.org/newsletters/ouch/issues/OUCH-201310_en.pdf
[Accessed 9 Jan. 2015].
Beebe, N. and Clark, J. (2005). A hierarchical, objectives-based framework for the digital
investigations process. Digital Investigation, 2(2), pp.147-167.
Bloomfield, H. (2015). Internet Browser Software Review 2015 | Best Internet Browsers TopTenREVIEWS. [online] Top Ten Reviews. Available at: http://internet-browserreview.toptenreviews.com/ [Accessed 16 Nov. 2014].
Brodkin, J. (2013). Apple’s iCloud Keychain: It works, but with frustrating limitations.
[Blog] ars
technica.
Available
at:
http://arstechnica.com/informationtechnology/2013/11/03/apples-icloud-keychain-it-works-but-its-limitations-arefrustrating/ [Accessed 15 Jan. 2015].
Page | 91
BSI Standards, (2013). Information technology — Security techniques — Guidelines for
identification, collection, acquisition, and preservation of digital evidence. London:
British Standard.
Carlsen, J. (2015). Internet Browser Software Review 2015 | Best Internet Browsers TopTenREVIEWS. [online] TopTenREVIEWS. Available at: http://internet-browserreview.toptenreviews.com/ [Accessed 6 Feb. 2015].
Carrier, B. and Spafford, E. (2004). An Event-Based Digital Forensic Investigation
Framework. In:Carrier-event. [online] West Lafayette: Center for Education and
Research
in
Information
Assurance
and
Security.
Available
http://www.dfrws.org/2004/day1/Carrier-event.pdf [Accessed 15 Jan. 2015].
at:
Chrome Support, (2015). Phishing & malware alerts - Chrome Help. [online]
Support.google.com.
Available
at:
https://support.google.com/chrome/answer/99020?hl=en-GB [Accessed 16 Jan. 2015].
Chrome,
(2015). Chrome
Browser.
[online]
Google.co.uk.
Available
at:
https://www.google.co.uk/chrome/browser/features.html#speed [Accessed 14 Jan. 2015].
Cole, E. (2015). Protecting Your Passwords. Securing the Human, [online] (March), p.1.
Available
at:
https://www.securingthehuman.org/newsletters/ouch/issues/OUCH201105_en.pdf [Accessed 15 Jan. 2015].
Computer Emergency Readiness Team, (2012). Password Security, Protection, and
Management. Carnegie: US-CERT, pp.1 - 5.
Darknet, (2006). FireMaster 2.1 - A Firefox Master Password Recovery Tool - Darknet - The
Darkside.
[online]
Darknet
The
Darkside.
Available
at:
http://www.darknet.org.uk/2006/06/firemaster-21-a-firefox-master-password-recoverytool/ [Accessed 12 Dec. 2014].
degausser.com, (2015). Degausser.com | Your guide to degaussers and hard drive erasers..
[online] Degausser.com. Available at: http://degausser.com/ [Accessed 16 Mar. 2015].
der
Gucht,
K.
(2015). Password
Safe
Quickstart
Guide.
Passwordsafe.sourceforge.net.
Available
http://passwordsafe.sourceforge.net/quickstart.shtml [Accessed 3 Apr. 2015].
[online]
at:
Ehmer Khan, M. (2011). Different Approaches To Black box Testing Technique For Finding
Errors.IJSEA, [online] 2(4), pp.31-40. Available at: http://www.ijcsi.org/papers/7-3-1-1116.pdf [Accessed 14 Feb. 2015].
Everett, G. and McLeod, R. (2007). Software testing. [Piscataway, NJ]: IEEE Press.
Page | 92
Florencio, D. and Herley, C. (2007). A Large-Scale Study of Web Password Habits. One
Microsoft Way. [online] Redmond: One Microsoft Way, pp.1 - 9. Available at:
http://research.microsoft.com/pubs/74164/www2007.pdf [Accessed 11 Feb. 2015].
Fontana, J. (2014). Citadel malware attacking open source password managers | ZDNet.
[online] ZDNet. Available at: http://www.zdnet.com/article/citadel-malware-attackingopen-source-password-managers/ [Accessed 13 Feb. 2015].
Forensic Control, (2015). Free IT forensic software | Free computer forensic software tools |
Forensic
Control.
[online]
Forensiccontrol.com.
Available
at:
https://forensiccontrol.com/resources/free-software/ [Accessed 4 Mar. 2015].
Forensic Focus, (2015). Computer forensics software, an introduction | ForensicFocus.com.
[online]
Forensicfocus.com.
Available
at:
http://www.forensicfocus.com/Content/pid=2/page=1/ [Accessed 4 Mar. 2015].
Freiling, F. and Schwittay, B. (2007). A Common Process Model for Incident Response and
Computer Forensics. In: IMF 2007. [online] Stuttgart: IMF 2007, pp.19 - 40. Available
at:
https://www1.informatik.uni-erlangen.de/filepool/publications/imf2007-commonmodel.pdf [Accessed 4 Apr. 2015].
Gasti, P. and Rasmussen, K. (2012). On the Security of Password Manager Database
Formats. Lecture Notes in Computer Science, [online] pp.770-787. Available at:
http://link.springer.com/chapter/10.1007/978-3-642-33167-1_44 [Accessed 4 Mar. 2015].
Golubić, K. and Stančić, H. (2015). Clearing and Sanitization of Media Used for Digital
Storage: Towards Recommendations for Secure Deleting of Digital Files. [online]
Zagreb:
University
of
Zagreb,
pp.1
6.
Available
at:
http://www.srce.unizg.hr/fileadmin/Srce/dokumenti/katalog_radova/13_2012_golubic_st
ancic.pdf [Accessed 24 Apr. 2015].
Gott, A. (2014). A Note from LastPass. [Blog] blog.LastPass. Available at:
https://blog.lastpass.com/2014/07/a-note-from-lastpass.html/ [Accessed 10 Jan. 2015].
Graham, D., Veenendaal, E. and Evans, I. (2008). Foundations of software testing. Australia:
Course Technology Cengage Learning.
Guidance Software, (2015). Computer Forensic Software - Encase Forensic. [online]
Guidancesoftware.com.
Available
at:
https://www.guidancesoftware.com/products/Pages/encase-forensic/overview.aspx
[Accessed 5 Apr. 2015].
Page | 93
Henry, A. (2015). Five Best Password Managers. [online] Lifehacker. Available at:
http://lifehacker.com/5529133/five-best-password-managers [Accessed 20 Apr. 2015].
How-To_Geek, (2012). View and Delete Stored Passwords in Firefox. [online]
Howtogeek.com. Available at: http://www.howtogeek.com/111555/view-and-deletestored-passwords-in-firefox/ [Accessed 15 Jan. 2015].
Khanse, A. (2014). How to see and manage saved passwords in Opera. [online] The
Windows Club. Available at: http://www.thewindowsclub.com/see-manage-savedpasswords-opera [Accessed 3 Mar. 2015].
Kohn, M., Eloff, J. and MS, O. (2006). Framework for a Digital Forensic Investigation.
In: ISSA 2006 from Insight to Foresight Conference. [online] Pretoria: ISSA 2006 from
Insight to Foresight Conference, pp.1 - 8. Available at: http://mo.co.za/open/dfframe.pdf
[Accessed 4 Jan. 2015].
Kohn, M., Eloff, M. and Eloff, J. (2013). Integrated digital forensic process
model. Computers & Security, [online] 38, pp.103-115. Available at:
http://dl.acm.org/citation.cfm?id=2622894 [Accessed 23 Mar. 2015].
Kovacs, E. (2014). Citadel Trojan Targets Password Managers, Authentication Solutions |
SecurityWeek.Com.
[online]
Securityweek.com.
Available
at:
http://www.securityweek.com/citadel-trojan-targets-password-managers-authenticationsolutions [Accessed 3 Jan. 2015].
Kumar, N. (2011). Password In Practice: An Usability Survey. Global Research in Computer
Science,
[online]
2(5),
pp.107
112.
Available
at:
http://www.jgrcs.info/index.php/jgrcs/article/view/96/96 [Accessed 22 Dec. 2014].
Last Pass, (2015). Go Premium | LastPass. [online] Lastpass.com. Available at:
https://lastpass.com/go-premium [Accessed 6 Jan. 2015].
LastPass, (2015). How It Works | LastPass. [online] Lastpass.com. Available at:
https://lastpass.com/how-it-works [Accessed 6 Jan. 2015].
LastPass, (2015). LastPass - Help Center. [online] Lastpass.com. Available
https://lastpass.com/support.php?cmd=showfaq&id=3206 [Accessed 8 Jan. 2015].
at:
LastPass, (2015). LastPass - Help Center. [online] Lastpass.com. Available
https://lastpass.com/support.php?cmd=showfaq&id=826 [Accessed 8 Jan. 2015].
at:
LastPass,
at:
(2015). LastPass
-
Technology.
[online]
Lastpass.com.
Available
https://lastpass.com/whylastpass_technology.php [Accessed 7 Jan. 2015].
Page | 94
Li, Z., He, W., Akhawe, D. and Song, D. (2014). The Emperor’s New Password Manager:
Security Analysis of Web-based Password Managers. In: USENIX Security Symposium.
[online]
Berkeley:
USENIX,
pp.465
479.
Available
at:
https://www.usenix.org/system/files/conference/usenixsecurity14/sec14-paper-lizhiwei.pdf [Accessed 13 Jan. 2015].
Mac Developer Library, (2014). Keychain Services Concepts. [online] Developer.apple.com.
Available
at:
https://developer.apple.com/library/mac/documentation/Security/Conceptual/keychainSer
vConcepts/02concepts/concepts.html [Accessed 4 Jan. 2015].
Maidasani, D. (2007). Software testing. New Delhi: Firewall Media.
McCarney, D. (2013). PASSWORD MANAGERS: COMPARATIVE EVALUATION, DESIGN,
IMPLEMENTATION AND EMPIRICAL ANALYSIS. Masters. Carleton University.
Molyneaux, I. (2009). The art of application performance testing. Sebastopol, Calif.: O'Reilly
Media, Inc.
Mulligan, J. and Elbirt, A. (2007). Desktop Security and Usability Trade-Offs: An Evaluation
of Password Management Systems. Information Systems Security, [online] 14(2), pp.1019.
Available
http://www.tandfonline.com/doi/pdf/10.1201/1086/45241.14.2.20050501/88289.3
[Accessed 4 Jan. 2015].
at:
Myers, G., Badgett, T., Thomas, T. and Sandler, C. (2004). The art of software testing.
Hoboken, N.J.: John Wiley & Sons.
National Institute of Standards and Technology, (2009). Guide to Enterprise Password
Management (Draft). Gaithersburg: U.S. Department of Commerce, pp.1 -15.
National Institute of Standards and Technology, (2015). Guide to Enterprise Password
Management (Draft). Gaithersburg: National Institute of Standards and Technology.
Olga, A. and vidalis, s. (2013). Towards ‘Crime Specific’ Digital Investigation Frameworks.
In: The 3rd International Conference on Cybercrime, Security and Digital Forensics.
[online] Chicago: Stafford University, p.1. Available at: http://eprints.staffs.ac.uk/1314/
[Accessed 10 Dec. 2014].
Opera Browser, (2015). Guide to security and privacy in Opera. [online] Opera.com.
Available at: http://www.opera.com/help/tutorials/security/password/ [Accessed 4 Mar.
2015].
Page | 95
Perrin, C. (2010). Five features of a good password manager. [online] TechRepublic.
Available at: http://www.techrepublic.com/blog/it-security/five-features-of-a-goodpassword-manager/ [Accessed 3 Apr. 2015].
Pfleeger, S. and Atlee, J. (2010). Software engineering. Upper Saddle River [N.J.]: Prentice
Hall.
Pinola, M. (2012). Which Password Manager Is The Most Secure?. [online] Lifehacker.
Available at: http://lifehacker.com/5944969/which-password-manager-is-the-most-secure
[Accessed 4 Feb. 2015].
Poulsen, K. (2013). Why Everyone Is Pissed Off About Google Chrome's Sound Security |
WIRED. [online] WIRED. Available at: http://www.wired.com/2013/08/chromepassword-manager/ [Accessed 14 Jan. 2015].
Reichl, D. (2015). Awards/Ratings - KeePass. [online] Keepass.info. Available at:
http://keepass.info/ratings.html [Accessed 6 Feb. 2015].
Reichl, D. (2015). Features - KeePass. [online] Keepass.info.
http://keepass.info/features.html [Accessed 6 Feb. 2015].
Available
at:
Reichl, D. (2015). Plugins - KeePass. [online] Keepass.info.
http://keepass.info/plugins.html [Accessed 10 Jan. 2015].
Available
at:
Reichl, D. (2015). Security - KeePass. [online] Keepass.info.
http://keepass.info/help/base/security.html [Accessed 6 Feb. 2015].
Available
at:
Reichl, D. (2015). Technical FAQ - KeePass. [online] Keepass.info. Available at:
http://keepass.info/help/base/faq_tech.html [Accessed 6 Feb. 2015].
RoboForm, (2015). RoboForm Everywhere: Overview. [online] Roboform.com. Available at:
http://www.roboform.com/everywhere [Accessed 4 Mar. 2015].
RoboForm, (2015). Why RoboForm is the Best Password Manager - RoboForm. [online]
Roboform.com. Available at: http://www.roboform.com/why-roboform [Accessed 3 Apr.
2015].
Rouse, M. (2005). What is pagefile? - Definition from WhatIs.com. [online] WhatIs.com.
Available at: http://whatis.techtarget.com/definition/pagefile [Accessed 11 Apr. 2015].
Rubenking, N. (2015). KeePass 2.28. PC Mag UK. [online] Available at:
http://uk.pcmag.com/security-reviews/38955/review/keepass-228 [Accessed 30 Apr.
2015].
Page | 96
Schneier on Security, (2015). Schneier on Security: Password Safe. [online] Schneier.com.
Available at: http://www.schneier.com/passsafe.html [Accessed 7 Feb. 2015].
Schneier, B. (2014). Security of Password Managers. [Blog] Schneier on Security. Available
at: https://www.schneier.com/blog/archives/2014/09/security_of_pas.html [Accessed 21
Apr. 2015].
Schneier, B. (2015). The Security of Twofish in a Password Manager. [Blog] Schneier on
Security. Available at: https://www.schneier.com/passsafe.html [Accessed 3 Apr. 2015].
Security Xploded, (2015). Download Chrome Password Decrypter - MajorGeeks. [online]
Majorgeeks.com.
Available
at:
http://www.majorgeeks.com/files/details/chrome_password_decrypter.html [Accessed 15
Jan. 2015].
Selamat, S. and Sahib, S. (2008). Mapping Process of Digital Forensic Investigation
Framework.IJCSNS International Journal of Computer Science and Network Security,
[online]
8(10
October),
pp.163
169.
Available
at:
http://paper.ijcsns.org/07_book/200810/20081025.pdf.
Siber Systems, Inc, (2015). RoboForm Reference Manual. [online] Roboform.com. Available
at: http://www.roboform.com/manual?format=pdf [Accessed 8 Apr. 2015].
Silver, D., Jana, S., Chen, E., Jackson, C. and Boneh, D. (2014). Password Managers: Attacks
and Defenses. In: Security Symposium. [online] San Diego: USENIX, pp.449 - 464.
Available
at:
https://www.usenix.org/conference/usenixsecurity14/technicalsessions/presentation/silver [Accessed 10 Apr. 2015].
Sourceforge, (2010). KeePass / Discussion / Help:Passwords in hiberfile.sys and pagefile.sys.
[online]
Sourceforge.net.
Available
at:
http://sourceforge.net/p/keepass/discussion/329221/thread/648b9b5a [Accessed 11 Apr.
2015].
SSL Shopper, (2015). Why SSL? The Purpose of using SSL Certificates. [online]
Sslshopper.com. Available at: https://www.sslshopper.com/why-ssl-the-purpose-ofusing-ssl-certificates.html [Accessed 7 Jan. 2015].
Suiche, M. (2008). Windows Hibernation File for Fun 'N' Profit.
Talekar, N. (2015). Chrome Password Decryptor : Free Google Chrome Password Recovery
Software.
[online]
Securityxploded.com.
Available
at:
http://securityxploded.com/chromepassworddecryptor.php [Accessed 15 Jan. 2015].
Towards ‘Crime Specific’ Digital Investigation Frameworks. (2015). .
Page | 97
United States Computer Emergency Readiness Team, (2012). Password Security, Protection,
and Management. Carnegie: Carnegie Mellon University, pp.1 - 5.
Wilkinson, S. (2015). Good Practice Guide for Computer-Based Electronic Evidence.
[online]
London:
7Safe
Information
Security.
Available
at:
http://www.7safe.com/electronic_evidence/ACPO_guidelines_computer_evidence.pdf
[Accessed 23 Dec. 2014].
Williams, L. (2011). A (Partial) Introduction to Software Engineering Practices and
Methods.
WireShark, (2015). Wireshark · About. [online] Wireshark.org.
https://www.wireshark.org/about.html [Accessed 7 Jan. 2015].
Available
at:
Wright, J. (2013). How Browsers Store Your Passwords (and Why You Shouldn't Let Them).
[Blog]RaiderSec. Available at: http://raidersec.blogspot.co.uk/2013/06/how-browsersstore-your-passwords-and.html#chrome [Accessed 15 Jan. 2015].
Zhao, R., Yue, C. and Sun, K. (2013). A Security Analysis of Two Commercial Browser and
Cloud Based Password Managers. 2013 International Conference on Social Computing.
[online]
Available
at:
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=6693367&url=http%3A
%2F%2Fieeexplore.ieee.org%2Fiel7%2F6693161%2F6693296%2F06693367.pdf%3Far
number%3D6693367 [Accessed 4 Jan. 2015].
Zhao, R., Yue, C. and Sun, K. (2013). Vulnerability and Risk Analysis of Two Commercial
Browser and Cloud Based Password Managers. In: ASE 2013. [online] Colorado:
International Conference on Automated Software Engineering, pp.1 - 15. Available at:
http://www.cs.uccs.edu/~cyue/papers/ASEScience13.pdf [Accessed 3 Jan. 2015].
Page | 98
Appendix
This section is used to place the associated print screens and hash values that have been referred to throughout this report. The first section is the
summarised table of every scenario, the expected outcome and the actual outcome. The second section is used to show the steps taken in both the
scenario creation and the experiment of those scenarios.
The second section is arranged so that each experiment has its own individual section. Last Pass for example is split up from B.1 – B.8. B.1
shows the first scenarios experiment print screens and the associated MD5 hash values connected to that experiment.
Appendix A
This appendix displays the complete table as described in section 3.3. Each of the scenarios and the results from those scenarios are shown
below.
Inputs
Description
User Expected Results
Actual Results
Master Password is tested as A Database is created and filled A database is created and filled with all the The first scenario was designed to test
the security method.
with fictitious data, that database is data relating to the user and protected the master password security however,
then protected using the master against unauthorised users by a master surprisingly the scenario revealed more
password security feature.
password.
about KeePass than originally intended.
The experiment revealed that under
certain
circumstances
KeePass
can
accidently place a master password
within the page file of the hard drive.
Inputs
Description
User Expected Results
Actual Results
Key file is used as the security A database is created similarly to The key file is used instead of a password. The second scenario concluded that
method instead of a master the first scenario
The database is still accessible but does not using the key file offered as the security
Page | 99
password.
require a remembered password.
does provide a high level of security
above other methods. The two key files
used were both secure and did not
provide
any information from the
database itself, as it was designed to do.
Inputs
Description
User Expected Results
Actual Results
An image file is used as the Unlike the first key file used, the The selected image is the only way of The third experiment of using an image
protection
rather
than
password.
a second key file will be an image
file.
accessing the current database. The security file as a key file provided the same level
Is equivalent to either a master password or of security as the any other key file type.
any other type of key file.
More importantly by using a key file, it
did not display any data that suggests
that the image is being used as a key
file, which is important to note.
Inputs
Description
The Windows user password is By
using
User Expected Results
the
Windows
Actual Results
user The password is set as the login password Using the Windows login password as a
used, the Windows password password for the database security which means no other password is required master password did not result in any
means that no other password the user will not have to remember
is required.
to access any of the data.
information becoming leaked
User Expected Results
Actual Results
any other password aside from
their login password.
Inputs
The
Description
created
database
is The used database is exported Upon exporting the database it will be The investigation revealed that the
exported using each of the using
available
formats.
each
of
the
different shown in each of the formats requested. For HTML document resided where it was
These exporting options to determine example exporting the database as an html originally
saved
and
left
in
an
Page | 100
formats are: HTML and XSL what data is readable without being format the document will show the database unencrypted format.
formats
as
well
as
other protected
KeePass safe formats.
password.
Inputs
Description
The HTML exported file is This
opened in a web browser.
with
the
master in the main used browser.
User Expected Results
scenario
is
designed
Actual Results
to Upon opening the database HTML file the The investigation revealed that unlike
determine whether any residue browser is launched displaying the contents before, the only data retaining to the
information is left within the of the database. However, the data within exported HTML document was located
browser files upon opening an the database is kept separate to the browser within the recycling bin. The data
exported HTML database.
Inputs
to reduce any chance of data being stored however, was still readable even after
Description
elsewhere.
the recycling bin had been emptied.
User Expected Results
Actual Results
The database is requested to be The contents of the database has Database is printed to get a hard copy of the The experiment revealed that once a
printed but cancelled before the been requested to be printed it will data stored within the database.
database has been asked to be printed it
job can be completed.
be cancelled before the database
is sent to the computers temp file. The
can be printed.
temp file contained the document in
plain text.
Inputs
Description
User Expected Results
Actual Results
The opposite experiment of the Unlike scenario 7 during this Database is printed to get a hard copy of the The investigation revealed however, the
seventh scenario that uses the scenario
the
database
is data stored within the database.
software did delete the successful print
same virtual machine to test successfully printed.
job but did not delete the previous failed
whether any remaining data is
job. The data from the failed print
left
request was still left in the temp file and
after
the
successful
Page | 101
printing.
poses a risk to the user.
Inputs
Complete
software
Description
deletion
from
of
the
User Expected Results
Actual Results
the The software is completely deleted Once the user has requested the software be After the completion of the forensic
virtual from the computer to analyse deleted all trace relating to the software investigation the only data relating to the
machine.
whether any residue information apart from the databases will be removed.
software
was
the
two
remaining
left relating to the user
database that were created previously. A
second search of the virtual machine
using the search option also revealed
that all data had been removed.
Inputs
Description
Database
is
created
populated
using
password
as
the
a
User Expected Results
Actual Results
and Database is created and populated New database is created and protected By conducting a forensic examination, it
master with fictitious data. The database is using the master password function.
security then protected using the standard
function.
password manager.
Inputs
Description
is proved that the master password is as
secure as it should be.
User Expected Results
Actual Results
Each of the exporting features Each exporting option is used to Each tested export will produce a different The forensic investigation did reveal the
are used and saved onto the determine whether there is any virtual record of the database.
contents of the database but that was
computer.
expected since it was saved in a plain
insecurity in the exporting feature.
text format. However, the v1.xformat
and the v2 format were both encrypted
Page | 102
also as expected.
Inputs
Description
User Expected Results
Actual Results
Utilising the feature of being IS Data is added into a safe note Creates a safe note which will then allow The
experiment
concluded,
if
the
able to copy text to the ‘clip which will then be copied to the the user to paste into another document if machine is improperly shut down either
board’ for easy entering of data ‘clip board’.
needed. The copied data is still located in from a hard reset or crashes the data is
into different fields.
the password manager however.
saved
to
a
recovery
file
in
an
unencrypted format.
Inputs
Description
User Expected Results
Actual Results
The contents of a safe note is During this experiment the data is Data copied onto the clipboard is going to The up investigation revealed that from
copied
to
the
clip
board copied however a simulated forced be used however a unplanned shutdown using the previous virtual machine, but
however, a false shut down of shut
down
occurs.
The occurs before the data can be used.
using a scenario that had a correctly shut
the computer means the data corresponding investigation will
down machine the previous stored data
could not be pasted.
analyse whether any data is located
and the latest stored data were both
in the cache.
removed from the system.
Inputs
Description
User Expected Results
Actual Results
The software is completely The scenario surrounds whether All data related to the software disappears The complete removal of the Password
removed
machine.
from
the
virtual any data is left on the machine apart from the expected databases which Safe software removed all data related to
after being uninstalled.
are left on the desktop.
the software except for the databases as
expected
Inputs
Description
User Expected Results
Actual Results
Page | 103
Data is added to a RoboForm This scenario tests the security of After the input of each identity the The first scenario revealed that if the
database using every possible the password RoboForm when computer will be shut down as normal.
password
manager
is
running
on
field. Three identities will be provided with large amounts of
machine with a limited amount of RAM
added to the database.
fictitious data with a limited
it may export sensitive data to the page
amount of RAM.
file of the computer. Among the
information located within the page file
was a complete identity of the fictitious
user. The identity included the name,
address, credit card number, pin number
and the expiration date of the card.
Inputs
Description
User Expected Results
Actual Results
Print feature is used on the The selected database will be The user requests a physical copy of the The
current database.
feature
revealed
no
requested to be printed. This database.
immediate data residue in either the
scenario is used to test whether any
temporary files or within the printer
residue
spool. The printing job was left in the
information
could
be
potential security risk.
Inputs
printing
Description
spool but in an encrypted format.
User Expected Results
Actual Results
The auto complete form feature The scenario simulates the user Upon navigating to the website ‘Hotmail’, The experiment revealed that the only
is applied.
wishing to use the autocomplete the user makes use of the auto complete data located on the system connected to
feature.
feature to automatically log on to the the auto login feature was the email
website.
address of used. The email was located
Page | 104
in multiple areas of the system in plain
text.
Inputs
Description
Data of a tested safe note is Copying
the
User Expected Results
data
onto
Actual Results
the Any database coped to the ‘clipboard’ will From the examination there were no
copied onto the clipboard using clipboard will test whether the data allow pasting of the text wherever required.
clear discrepancies in the way in which
the offered feature.
the safe note feature were copied
becomes cached as other password
managers do or protected.
Inputs
Description
User Expected Results
Actual Results
The complete removal of the The scenario will remove the Once RoboForm is no longer needed the The
software
fifth
scenario
data
from
presents
the
no
software from the computer to software will be deleted from the computer.
unsurprising
actual
analyse whether any data left on
analysis of the virtual machine. The only
the computer can compromise the
content of the data that was identifiable
security of the data.
about the data residing on the device
was the name of the main user profile.
Page | 105
Appendix B LastPass
Appendix B contains the print screens of the first experiment done on RoboForm B-1.1 – B7.3. The rest of the print screens relating to the scenarios can be found in the external
documents.
B.1
Experiment 1
Acquisition MD5
F10ab139c1af708dba7c3d286b7387a1
Verification MD5
F10ab139c1af708dba7c3d286b7387a1
GUID
191bb9b8cf040fcf0c0cfe2dcdbebee7
File Integrity
0 errors
Experiment 1
Figure B -1.1, Print screen 1 showing the three created databases
Page | 106
Figure B-1.2, print screen 2 showing the contents of the first database
Figure B-1.3, Print screen 3 showing the contents of one of the entries
Page | 107
Figure B-1.4, Print screen 4 showing the contents of another entry
Figure B-1.5, Print screen 5 showing the MD 5 hash values for the first scenarios investigation.
Page | 108
Figure B-1.6, Print screen 6 showing the page files containing data relating to the first scenarios examination
Figure B-1.7, Print screen 7showing the contents of one of the page files including the master password used as part of
the experiment.
Page | 109
Figure B-1.8, Print screen 8 showing the location of the print file as mentioned in the first scenarios discussion
Figure B-1.9, Print screen 9 showing the same discovered data but in a transcript form
Page | 110
Figure B-1.10, Print screen showing the name of one of the fictitious users in plain text.
B.2
Experiment 2
Acquisition MD5
Fef28ca95bff19d95f0c251637edca
Verification MD5
Fef28ca95bff19d95f0c251637edca
GUID
8e2407fc2d31cbcfef1557f7bbbee9fe
File Integrity
0 errors
B.3
Experiment 3
Acquisition MD5
F5db0b688d638a0b46cd0d7ff8c231ec
Verification MD5
F5db0b688d638a0b46cd0d7ff8c231ec
GUID
29cc5b8a59ccbdcb26e82fc8b23ca337
File Integrity
0 errors
B.4
Experiment 4
Acquisition MD5
Dfdfd66f087a5c04a092821ab8278ce8
Verification MD5
Dfdfd66f087a5c04a092821ab8278ce8
GUID
86831892e1801dcb4583cf355fe60cd3
File Integrity
0 errors
Page | 111
B.5
Experiment 5
Acquisition MD5
E0dee6cb8fca4fdf041b2109c912
Verification MD5
E0dee6cb8fca4fdf041b2109c912
GUID
38dd17da5938d8c12f3611f447079596
File Integrity
0 errors
Figure B-5.1: print screen showing the exportation of one of the entries entered into the database.
Page | 112
Figure B-5.2: Print screen showing the exporting options given by KeePass
Figure B-5.3, Print screen showing the XSL file exported from the previous options
Page | 113
Figure B-5.4, Print screen showing the MD5 hash values for the fifth experiments investigation
Figure B-5.5, Print screen showing the search for any data located within the browsers history file
Page | 114
Figure B-5.6, Print screen showing the search for any data in the Internet Explorer history file
Figure B-5.7, Print screen showing the results from a search done on the computer looking for data relating to the
fictitious use.
Page | 115
Figure B-5.8, Print screen showing the second search results alongside the exported data.
B.6
Experiment 6
Acquisition MD5
0ed06e29c3bdd7b5708cf7400188c0c7
Verification MD5
0ed06e29c3bdd7b5708cf7400188c0c7
GUID
033baa15323cfccce83bcd89f0ae1cab
File Integrity
0 errors
B.7
Experiment 7
Acquisition MD5
A12b517d238fa0131065a6e76a38f667
Verification MD5
A12b517d238fa0131065a6e76a38f667
GUID
63397799abb00bc6df4cf6232cb60c08
File Integrity
0 errors
Page | 116
Figure B-7.1, Print screen showing the act of printing the database
Figure B-7.2, Print screen showing the formatting of the intended printed document.
Page | 117
Figure B-7.3, Print screen showing the process needed to print out the database.
Figure B-7.4, Print screen showing the error message that prevented the original document being printed.
Page | 118
Figure B-7.5, Print screens showing the MD5 Hash value for the seventh experiment.
Figure B-7.6, Print screen showing the results from a search done on the machine. The results include the entire database
that was intended to be printed.
B.7.2
Experiment 8
Acquisition MD5
22b4a0eef87145ec6e93e3c0d00451d7
Verification MD5
22b4a0eef87145ec6e93e3c0d00451d7
GUID
16be23be58ca42c28306131a144b9022
File Integrity
0 errors
Page | 119
Figure B-7.7, Print screen showing the MD5 Hash value for the eighth tested experiment.
Figure B-7.8, Print screen showing the results from a similar search done on the virtual machine.
Page | 120
Figure B-7.9, print screen showing the deleted printed database
B.8
Experiment 9
Acquisition MD5
8c19f4385a580ff0f44fc3168c8bfd67
Verification MD5
8c19f4385a580ff0f44fc3168c8bfd67
GUID
185f73d8b2528ece09f4f72130c312df
File Integrity
0 errors
Appendix C Password Safe
Appendix C contains the print screens of the first experiment done on RoboForm C-3.1 – C3.11 the rest of the print screens relating to the scenarios can be found in the external
documents.
C.1
Experiment 1
Acquisition MD5
4335f39b6174820e98146289cb2679af
Verification MD5
4335f39b6174820e98146289cb2679af
GUID
2d8ab206c0e286c9bfed8bb4a64ac441
File Integrity
0 errors
C.2
Experiment 2
Acquisition MD5
B2f5951411f9fe0a824b8fbb1e804ab
Page | 121
Verification MD5
B2f5951411f9fe0a824b8fbb1e804ab
GUID
6308dbdb849751c9b964e982ed1c31fa
File Integrity
0 errors
C.3
Experiment 3
Acquisition MD5
8823dd1c63ac96a301a3c4fe099a7f75
Verification MD5
8823dd1c63ac96a301a3c4fe099a7f75
GUID
F5d21c18e84808ce8df2558a75ab862d
File Integrity
0 errors
Figure C-3.1, Print screen showing the request to copy the selected data to the clipboard.
Page | 122
Figure C-3.2, Print screen showing the confirmation request to copy the data to the clipboard.
Figure C-3.3, Print screen showing the in correct shut down method used during this scenario
Page | 123
Figure C-3.4, Print screen showing the MD5 Hash value for this investigation
Figure C-3.5, Print screen showing the results from a search done on the machine
Page | 124
Figure C-3.6, Print screen showing the refined search for any data related to the scenario, in this case the master
password used on the machine.
Figure C-3.7, Print screen showing the results from the results from the refined search.
C.3.2
Experiment 3.2
Acquisition MD5
E00b163ce25d5dab2a2b4342b444201
Verification MD5
E00b163ce25d5dab2a2b4342b444201
Page | 125
GUID
7f288e0f73881bcc7c84dc5b6dee92dc
File Integrity
0 errors
Figure C-3.8, Print screen showing the MD5 Hash values for the second third experiment done on Password Safe.
Figure C-3.9, Print Screen showing the first initial search done on this experiment
Page | 126
Figure C-3.10, Print screen showing the refined search done on the recovery file where the original information was
located.
Figure C-3.11, Print screen showing the message confirming that the data had been deleted after a correct shut down
had been done.
C.4
Experiment 4
Acquisition MD5
F3c1156eb62a1b91bfbdc640e0140f76
Verification MD5
F3c1156eb62a1b91bfbdc640e0140f76
Page | 127
GUID
4dbb7c6960d23bca6cc0111c3cf83003
File Integrity
0 errors
Appendix D RoboForm
Appendix D contains the print screens of the first experiment done on RoboForm D-1.1 – D3.5. The rest of the print screens relating to the scenarios can be found in the external
documents.
D.1
Experiment 1
Acquisition MD5
Ef2c1f0511c75b07c393d1370344c78b
Verification MD5
Ef2c1f0511c75b07c393d1370344c78b
GUID
9ad7ef6fdead3ec3aafc738132d5f043
File Integrity
0 errors
Figure D-1.1, Print screen of the combined fictitious identities created for the RoboForm scenario.
Page | 128
Figure D-1.2, Print screen of the combined identities and note created for the scenario
Figure D-1.3, Print screen showing the data entered in one of the identities.
Page | 129
Figure D-1.4, Print screen showing the MD5 Hash value for the first experiment done on RoboForm
Figure D-1.5, Print screen showing the results from a search done using Encase.
Page | 130
Page | 131
Figure D-1.6, Print screen showing the search done on whether the master password could be located.
D.2
Experiment 2
Acquisition MD5
F39a234b045635a39971914e0c9edc5d
Verification MD5
F39a234b045635a39971914e0c9edc5d
GUID
24d409ce0c5a12cc971ef9a3801b0c3
File Integrity
0 errors
D.3
Experiment 3
Acquisition MD5
118fded043c81f3dfdaa7aad45b2380f
Verification MD5
118fded043c81f3dfdaa7aad45b2380f
GUID
4cb76a88b9538acd3bddc5d6840171b7
File Integrity
0 errors
Page | 132
Figure D-3.1, Print screen showing the creation of the Hotmail account used to test the auto sign in feature offered by
RoboForm
Figure D-3.2, Print screen showing the confirmation of password protecting the auto login feature.
Page | 133
Figure D-3.3, Print screen showing the automatic login option offered by RoboForm
Figure D-3.4, Print screen showing the MD 5 Hash value for this investigation
Page | 134
Figure D-3.5, Print screen showing the result from a search done on the machine looking for any data relating to the
fictitious data.
D.4
Experiment 4
Acquisition MD5
C8e5ef85718a021c7bc5cdffbe3dbdb6
Verification MD5
C8e5ef85718a021c7bc5cdffbe3dbdb6
GUID
57454109f2a378cbde1f8a076088d747
File Integrity
0 errors
D.5
Experiment5
Acquisition MD5
D885ef8ed18a875c7bc5cdadbe3dcfb9
Verification MD5
D885ef8ed18a875c7bc5cdadbe3dcfb9
GUID
87354129h2a378cgde1h8a094028d632
File Integrity
0 errors
Page | 135
Download PDF
Similar pages