Keep your memory dump shut: Unveiling data

leaks in password managers

Efstratios Chatzoglou1[0000−0001−6507−5052] , Vyron

Kampourakis2[0000−0003−4492−5104] , Zisis Tsiatsikas1[0000−0002−9481−0906] ,
arXiv:2404.00423v1 [cs.CR] 30 Mar 2024

Georgios Karopoulos3[0000−0002−0142−7503] #, and Georgios

Kambourakis1[0000−0001−6348−5031]
1
University of the Aegean, 83200 Karlovasi, Greece {efchatzoglou, tzisis,
gkamb}@aegean.gr
2
Norwegian University of Science and Technology, 2802 Gjøvik, Norway
[email protected]
3
European Commission, Joint Research Centre (JRC), Ispra, Italy
[email protected]

Abstract. Password management has long been a persistently challeng-

ing task. This led to the introduction of password management software,
which has been around for at least 25 years in various forms, including
desktop and browser-based applications. This work assesses the ability of
two dozen password managers, 12 desktop applications, and 12 browser-
plugins, to effectively protect the confidentiality of secret credentials in
six representative scenarios. Our analysis focuses on the period during
which a Password Manager (PM) resides in the RAM. Despite the sen-
sitive nature of these applications, our results show that across all sce-
narios, only three desktop PM applications and two browser plugins do
not store plaintext passwords in the system memory. Oddly enough, at
the time of writing, only two vendors recognized the exploit as a vulner-
ability, reserving CVE-2023-23349, while the rest chose to disregard or
underrate the issue.

Keywords: Password Managers · Security · Data leaks · Vulnerability

1 Introduction

Twenty years after Bill Gates predicted the death of passwords [14], here we are
still using them. What is more, there are still major data breaches that are due
to weak or insecure passwords, such as in the recent cases of SolarWinds [10] and
Colonial Pipeline [30]. Passwords come in different forms, such as personal iden-
tification numbers (PINs), passphrases, and frequently as one of the components
of multifactor authentication. In between secure but impractical solutions, such
as remembering all passwords, and practical but insecure ones, such as using the
same password everywhere, one of the most popular ways for protecting creden-
tials is password managers (PMs). Moreover, even when using PMs, usability
clearly affects the security and trustworthiness of such applications [7]. Thus,
2 E. Chatzoglou et al.

the main question behind our study is: 25 years after the development of the
first PM [18], how secure are our passwords when stored in such applications?
Looking first at how software developers and vendors handle PM security, as
software applications, PMs capitalize on relevant principles, methodologies and
tools, as well as standards and best practices for secure software development.
Nevertheless, absolute security cannot be guaranteed, even when using all the
above means. Moreover, one of the main building blocks of a secure software
development lifecycle is risk management. During this process, however, software
vendors need to decide which security issues to tackle, wittingly ignoring in
several cases those that they consider of minor importance or extravagant to
address. In fact, during our study, out of the seven PM vendors contacted, only
two recognized the issues reported in this paper and took action to remediate
them.
Moving to how PM end-users perceive the value of security, the work in [26]
suggests that users of standalone password managers may prioritize security,
whereas users of built-in managers seem to value convenience more. The work
in [9] compared users of password managers with non-users of such applications,
finding that the main motivation of password manager users was convenience,
instead of security, and the impeding factor for non-users was security concerns.
These findings suggest that PM users do not always put security as their first
priority when adopting such applications.
There are frequent mentions of PMs in the media in the form of advertise-
ments, comparisons or security analyses [31], attempting to help the user select
the most suitable PM. However, as absolute security cannot be guaranteed, it
turns out that sporadically even popular PMs, which are recognized for the level
of security they provide, can suffer from security issues [25]. One such example
is a recent critical vulnerability affecting KeePass, which allowed the attackers
to recover the master key [29] safeguarding the PM’s vault. In this context, this
paper presents a security analysis of 12 desktop and 12 browser plugin PMs to
understand the level of private information they potentially leak. Our study is
focused on the period during which each of these applications is loaded on the
system memory.
The contributions of this work can be summarized as follows:

– We examine which modern PMs allow the extraction of plaintext credentials

from the RAM, offering exploits that can streamline the retrieval process.
– We investigate to which extent the leaking information reveals repetitive
patterns that augment the attack surface.
– We examine PM vendor conformity to OWASP secure development guide-
lines with respect to the exposure of private information.
– Following responsible disclosure, we notified the respective PM vendors about
the identified vulnerabilities and succinctly discuss our interaction with them.

The rest of the paper is structured as follows. The next section details the
threat model. Section 3 presents our methodology, the derived results, and ways
of exploitation in the context of red teaming. Section 4 elaborates on best prac-
 Keep your memory dump shut: Unveiling data leaks in password managers 3

tices, including possible mitigation strategies. The related work is given in Sec-
tion 5. The last section concludes and offers directions for future work.
2 Threat model
Generally, data leakage attacks directly violate the first two properties of the
Confidentiality, Integrity, and Availability (CIA) triad. For PMs, however, avail-
ability is also indirectly affected in case an attacker obtains the PM’s master
password and subsequently changes it, locking the legitimate user outside the
PM’s vault. Similarly, a user can be locked outside a service account if an attacker
changes the user’s password. Essentially, in the case of PMs, where the stored
information is considered critical, maintaining these properties is paramount.
Nevertheless, as this work proves through an experimental evaluation of sev-
eral renowned PMs in Section 3, data leakage is still feasible under certain cir-
cumstances. This section establishes the threat model under which an outsider
attacker operates.
We concentrate on client-side PMs assuming that the targeted machine is
situated within a local network, typically protected by a firewall, say, the one
provided by default by MS Windows. In this common setting, the adversary
needs to somehow penetrate the network and gain access to the victim’s machine.
This can be done in a plethora of ways, which however are outside the scope of
the current work; for instance, the attacker might lure the victim to download
and execute a piece of malware, often the result of a phishing attack.
After that, the attacker needs to dump the PM’s processes; typically, these
are more than one. With reference to Section 3, for all the 12 standalone PMs
but 1Password this is straightforward; no special privileges are required. On the
other hand, 1Password’s processes run with a high integrity level. This means
that even if the targeted user has administrative privileges, due to the User
Account Control (UAC) Windows security feature, the malware (or generally
the attacker’s process) will often default to medium integrity, obstructing access
to resources with higher integrity levels. In such a case, the attacker needs to
elevate the integrity level silently, without spawning a UAC pop-up to the user.
This can be accomplished through a UAC bypass method, including registry key
manipulation, DLL hijacking, and elevated COM interface. Indicatively, a well-
utilized DLL hijack-based method is given in [13]. Last but not least, the attacker
must devise a way to efficiently search each one of the acquired dump (.DMP)
files, say, through some script implementing pattern matching as detailed in
subsection 3.4.
3 Experiments
The current section details our methodology and findings. Namely, after pre-
senting the utilized testbed, we report on the different test scenarios and discuss
the derived results.
3.1 Testbed and test scenarios
Each of the examined PM applications was installed on a separate clean Virtual
Machine (VM) instance running MS Windows 10; the last OS update was per-
4 E. Chatzoglou et al.

formed in Jan 2024. Every VM was equipped with 5GB of RAM and a quad-core
CPU. For testing each PM, we compiled six distinct, representative of use sce-
narios, S1 to S6, as presented in Table 1. Overall, these test scenarios correspond
to the different states a PM application may be in relation to the actions of the
end-user.
With reference to the leftmost column of Table 2a, the first round of experi-
ments involved 12 popular PM desktop applications [31]. In a subsequent round,
as shown in the leftmost column of Table 3, we repeated all six scenarios against
12 frequently encountered browser PM plugins [8]. The latter checks have been
carried out on Chrome v120.0.6099.216. By comparing the above-mentioned ta-
ble columns, it is obvious that half of the PM products are common in both
Tables 2 and 3. All the experiments were carried out in Jan. 2024 using the
latest at that time version of each PM or browser plugin.

Scenario Description
S1 Enter the master password and dump the relevant processes.
S2 Manually lock the PM and dump the relevant processes.
S3 After a certain amount of idle time, the PM is locked automatically; dump
the relevant processes.
S4 After creating a new entry password, dump the PM’s processes.
S5 While the PM is unlocked, click on a random entry in the corresponding
list and dump the relevant processes.
S6 Kill the relevant processes through the task manager, rerun the application
without entering the master password and dump the relevant processes.

Table 1: Utilized scenarios per PM application. The term “relevant processes”

in the scenarios refers to either the PM’s or the browser’s processes in case of a
plugin.

3.2 Results

Every dump (.DMP) file created after executing each of the scenarios of Table 1
was examined for possibly containing secret information in cleartext. Specifi-
cally, we look for user credentials, either the PM’s master password or entry
passwords; usernames are also of interest, but for the needs of this subsection
the concentration is on passwords. Each PM entry corresponds to the user’s
sign-in credentials to some service, say, Facebook, as they are contained in the
PM’s vault. Typically, an entry comprises a username, password, and the URL
of the corresponding service. No less important, normally, a PM (or browser
in the case of a plugin) spawns more than one processes, therefore a memory
dump event as those in Table 1 may comprise numerous .DMP files. Such a file
contains arbitrary information and its average size may be several megabytes,
which renders its manual analysis with a hex editor cumbersome. Instead, as
detailed in subsection 3.4, this can be relatively easily automated.
The results of applying all six scenarios to each standalone PM are recapit-
ulated in Table 2a, where the ✓ and the ✗ symbols indicate either a positive
 Keep your memory dump shut: Unveiling data leaks in password managers 5

or negative result regarding password leakage, respectively. Specifically, for each

PM and scenario, the table shows if one or more of the respective dump files
contain either or both the end-user’s master and entry passwords. Note that
each scenario is independent of the others, i.e., before executing each scenario,
the PM application (or the browser in the case of plugins) was terminated.
With reference to Table 2a, it is observed that only three PMs do not expose
any plaintext password across all six scenarios. This does not mean that the
password(s) are indeed not present in the memory (dump); contrastingly, they
may exist in the dump, but they are in some secret obfuscated form that only the
PM can parse. Also on the positive side, no PM leaks any plaintext password in
S6, which however was somewhat expected. On the downside, four PMs expose
either or both types of passwords in all scenarios but S6. In addition, three more
PMs leak both types of passwords in at least three different scenarios. On top
of that, half of the PMs leak the master password in S1, which is expected to
be executed much more frequently than the rest of the scenarios. The latter
outcome is not much better for S2 to S5, where three, four, five, and six PMs
leak the master password. With reference to entry passwords, the situation is not
markedly better given that in S1 to S5 at least two PMs expose entry passwords;
the worst results are obtained in S4 and S5, where nine and seven PMs leak
this type of password, respectively. Overall, across all the scenarios and all the
PMs, 50 leaks are perceived, 24 and 26 for the master and entry passwords,
respectively. Naturally, this figure cannot be seen as positive, summoning vendors
up for corrective actions.
An additional important remark that emerged during our experiments with
the standalone PM applications relates to the number of times a password ap-
pears in plaintext in the corresponding memory dump file. This information per
scenario per PM is summarized in Table 2b. It should be clarified that for S4 and
S5, the table contains the number of times the newly added (S4) or clicked on
(S5) entry password is found in the respective .DMP file. From a bird’s eye view,
as expected, the results between the two subtables of Table 2 coincide. Concen-
trating on Table 2b, the worst results for the entry password(s) are observed for
S1, S4, and S5, where two, six, and four PMs expose at least four instances of the
same password, respectively. This number even reaches double digits in S4 (for
three PMs) and S5 (for one PM). Continuing from the previous result, S4 yields
the worst score, demonstrating six PMs exposing at least four instances of the
same newly added entry password. On the other hand, the situation regarding
the master password seems better, with the poorer and best scenario in terms of
security being S1 and S2, respectively. That is, in S1 three PMs expose at least
four instances of the master password, while in S2 no PM exposes more than two
instances. As a general comment, with special reference to S4, and to a lesser
degree to S5 and S1, a significant number of PMs expose user’s entry passwords
too many times, which in turn increases the attacker’s chances of discerning the
password in the dump file, even if the latter is inspected visually.
The corresponding results referring to the 12 browser plugins are given in
Table 3. As perceived, only two plugins expose zero plaintext leaks across all
6 E. Chatzoglou et al.

scenarios. Notably, however, six plugins leak a password in at least two different
scenarios. Significant also is that 9 out of 12 or ≈75% of the plugins leak a
password in S1, which is considered the most common from a user’s perspective.
Altogether, across all the scenarios and all the plugins, 23 leaks are observed,
which are split into 3 and 20 for the master and entry passwords, respectively.
Although somewhat better vis-à-vis the results of Table 2a, this figure reveals
again a rather unfavorable average result in terms of security engineering for this
type of software.
For better appreciating the results of Table 3, the following observations
are noteworthy. First, some plugins, including 1Password and Ironvest require
prior interaction between the browser and themselves for leaking an entry pass-
word. Second, certain plugins, including ⋆ PM, Kaspersky, and Sticky Password
mandate the installation of the homonymous desktop PM; therefore, when the
desktop PM application is locked, the plugin is also locked automatically. Third,
a minority of plugins, e.g., Roboform, need prior browser interaction with any
saved entry URL or the user to click on the plugin’s dashboard for loading all
entries. Fourth, in some cases, e.g., 1Password, the leak is visible after several
seconds, possibly for the browser to finish loading the respective plugin. Lastly,
most plugins do not sweep PM-loaded user credentials away from the browser’s
process after some time has elapsed. Bitdefender and Bitwarden are the only
exceptions to this situation, clearing the browser’s process after 5 and 10 min
respectively. Comparing the common six PMs in Tables 2a and 3 it is extrapo-
lated that, as expected due to the second point above, there are two zero-leak
PMs in both their standalone and plugin version, while for the remaining ones
the situation is more or less better in their plugin version.

PM application S1 S2 S3 S4 S5 S6 PM application S1 S2 S3 S4 S5 S6
1Password ✓ ✗ ✓ ✗ ✓ ✗ ✓✓ ✓ ✗ ✗✗ 1Password 10 - 2- 2- 2 4 1 - -
Bitwarden ✓✓ ✗ ✗ ✗ ✗ ✓✓ ✓✓ ✗✗ Bitwarden 8 2 - - - - 1 7 1 3 -
⋆
PM ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✓ ✗ ✓ ✗✗ ⋆
PM - - - - - - - 1 - 1 -
Kaspersky ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗✗ Kaspersky - - - - - - - - - - -
KeePass 2 ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗✗ KeePass 2 - - - - - - - - - - -
KeePassXC ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✓ ✗ ✗ ✗✗ KeePassXC - - - - - - - 1 - - -
Keeper ✓✓ ✗ ✗ ✓✓ ✓✓ ✓✓ ✗✗ Keeper 4 4 - - 44 4 4 4 4 -
Nordpass ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✓ ✓✓ ✗✗ Nordpass 2 - - - - - - 24 4 19 -
Passwarden ✓✓ ✓✓ ✓✓ ✓✓ ✓✓ ✗✗ Passwarden 2 3 23 23 2 12 2 8 -
PasswordBoss ✗ ✓ ✗ ✓ ✗ ✓ ✗ ✓ ✗ ✓ ✗✗ PasswordBoss - 8 - 4 -1 - 11 - 7 -
RoboForm ✓✓ ✓ ✗ ✓ ✗ ✓✓ ✓✓ ✗✗ RoboForm 1 1 1- 2- 1 2 1 2 -
StickyPassword ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗✗ StickyPassword - - - - - - - - - - -
(a) Leaks per type of password per scenario (b) Password instances per scenario

Table 2: Results for standalone PMs. Master and entry cleartext password leaks
are given in white and light-gray background, respectively (✓: password leak, ✗:
no password leak). The vendor preceded with a star (⋆) requested to remain
undisclosed until the vulnerability has been patched.
 Keep your memory dump shut: Unveiling data leaks in password managers 7

Browser PM plugin S1 S2 S3 S4 S5 S6
1Password ✗ ✓ ✗ ✓ ✗✓ ✗ ✗ ✗✓ ✗ ✗
Avira ✗ ✓ ✗ ✓ n/a ✗ ✗ n/a ✗✓
Bitdefender ✓ ✗ ✓ ✗ n/a ✗ ✗ ✗✓ ✗ ✗
Bitwarden ✗ ✓ ✗ ✗ n/a ✗ ✗ n/a ✗ ✗
Dashlane ✓✓ ✗ ✗ n/a ✗ ✗ n/a ✗ ✗
⋆
PM ✗ ✗ ✗ ✗ ✗ ✗ ✗✓ ✗ ✗ ✗ ✗
Ironvest ✗ ✓ ✗ ✓ n/a ✗ ✗ n/a ✗ ✗
Kaspersky ✗ ✗ ✗ ✗ ✗ ✗ n/a ✗ ✗ ✗ ✗
LastPass ✗ ✓ ✗ ✓ n/a ✗ ✗ n/a ✗✓
Norton ✗ ✓ ✗ ✓ n/a ✗ ✗ n/a ✗✓
RoboForm ✗ ✓ ✗ ✗ n/a ✗ ✗ n/a ✗ ✗
StickyPassword ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗

Table 3: Results for PM browser plugins. Master and entry cleartext password
leaks are given in white and light-gray background, respectively (✓: password
leak, ✗: no password leak). n/a (not applicable) means that either the plugin
does not have an automatic lock feature (S3), or the plugin does not offer an
“add new entry” feature (S4), or the plugin loads all entries automatically when
the browser is started (S5).

3.3 Discussion

Abiding by a Coordinated Vulnerability Disclosure (CVD) process, the results

have been promptly communicated to most of the affected PM vendors along
with the corresponding exploit(s). Two vendors did acknowledge the issue and
reserved a Common Vulnerabilities and Exposures (CVE) ID, namely CVE-
2023-23349, pledging to also provide a respective patch promptly. The rest of
them provided arguments in two directions. The first implies that the vendors
are already aware of the problem, but they largely tend to underrate it. Namely,
their basic claim is that performing such an attack would require an already
compromised system and a malicious actor with escalated privileges. On the one
hand, this assertion is half true; based on our results in subsection 3.2, there
do exist PM products that do not leak secret information in plaintext, and this
stands true for both the standalone PMs (three instances) and the respective
plugins (two instances). On the other hand, as detailed in Section 2, all PMs
except one do not even require elevated privileges for dumping their processes.
In this respect, the attacker does not even need to bypass UAC, which generally
is cumbersome.
In relation to the previous argument, others may reason that a keylogger mal-
ware may achieve the same goal, without collecting and inspecting a PM memory
dump file. The counterargument here is that a keylogger needs to stealthily oper-
ate round-the-clock and opportunistically wait for the victim to type a password.
Even more, the attacker can save the relevant .DMP file and analyze it offline, let
alone that if the respective PM divulges the master password, then the attacker
instantly gains access to every entry the victim keeps in the PM’s vault.
8 E. Chatzoglou et al.

The second line of arguments, even not so common, suggests that some of
the PM vendors are unsure about how to address the issue effectively. That is,
if they apply some form of obfuscation to the passwords loaded in memory, they
may provide a false sense of security; this is a form of security by obscurity,
which generally, as well as in this case, is only effective as long as the (secret)
obfuscation pattern remains confidential. On the flip side, unauthorized access
to the PM will typically lead to multiple breaches (this equals the number of
different entry passwords stored in the PM). In the presence of no other viable
and stronger defense, obfuscation seems, at least for the moment, the only way
forward. To enhance the robustness of the obfuscation procedure, a variable, fre-
quently changing pattern should be used, ideally paired with other techniques,
e.g., the system-protected process security model, also known as Protected Pro-
cess Light (PPL) technology [20]. For more information on this issue, the reader
is referred to Section 4.

3.4 Red teaming and exploits

To propel research and advance red teaming methodologies and responsible dis-
closure in this field, we developed an open-source tool called Pandora, which is
publicly available in a GitHub repository [4]. Pandora assists in harvesting user
credentials, both usernames and passwords, possibly present in cleartext in the
processes spawned by several well-known PMs. The tool supports MS Windows
10 standalone PMs and browser plugins; at the time of writing, it supports 14
PMs, with 18 different implementations, e.g., it can dump end-user credentials
either from the desktop application or the browser plugin of the same prod-
uct. The tool requires the PM to be running and unlocked. For additional and
up-to-date information on the tool, the interested reader is referred to [4].
Moreover, for reasons of completeness, Algorithm 1 offers a generic exploit
in pseudocode. As seen in line 3, after opening the respective .DMP file, the
algorithm applies a search pattern. The latter is based on the common technique
exploited by anti-malware services; a file is flagged as possibly malicious when a
sequence of hex bytes, i.e., a signature, is present within the file. In this work, we
exploit the same logic to identify the patterns that hold the user’s credentials in
the corresponding PM’s process memory dump. To identify a possible pattern,
first, one needs to configure each PM with different credentials, namely, master
and entry passwords along with their matching usernames, if required by the
PM depending on the case. Then, using a hex editor, each dump file is manually
investigated for containing one or more of these entries. If some entry is found,
that entry’s preceding and succeeding bytes are kept as possible search patterns.
Then, the investigator checks if the same bytes (pattern) stay identical across
different PM states with the same or other entries. If yes, then this pattern can
be used to produce an exploit for the specific PM. In Algorithm 1, given the
pattern of line 3, lines 5-21 gather the next or previous n bytes, and convert
them to UTF-8 for revealing the password (and username) in plaintext. The
number of bytes n is defined empirically, and it may be different per PM; for
Algorithm 1 this parameter is set to 300 bytes in line 12.
 Keep your memory dump shut: Unveiling data leaks in password managers 9

Algorithm 1 getCreds
1: function getCreds
2: Open file “app.dmp” in binary mode
3: searchP attern ← [0x80, 0x00, 0x04 ... 0x00]
4: f oundData ← empty list
5: while not end of file do
6: Read a byte from file and store it in variable c
7: if c = next element in searchP attern then
8: Add c to f oundData
9: if length of f oundData = length of searchP attern then
10: extractedData ← empty list
11: dataCount ← 0
12: while dataCount < 300 and not end of file do
13: Read a byte from file and add it to extractedData
14: Increment dataCount
15: utf 8ExtractedData ← convert extractedData to UTF-8 string
16: Print “Pattern Data:” concatenated with utf 8ExtractedData
17: Save into file using saveFile function with parameter
18: utf 8ExtractedData
19: Clear f oundData
20: else
21: Clear f oundData
22: Close file

4 Best practices

The current section offers a brief description of the best practices that should
be employed for sensitive information management by a PM application. As dis-
cussed in Section 3, the success of the attack hinges on the fact that essential
information is written in an unprotected (plaintext) format by the PM appli-
cation. Nevertheless, there exist numerous guidelines [6,23,22] that dictate the
proper way for handling private information by such applications.
Primarily, as delineated by the Open Worldwide Application Security Project
(OWASP), the relevant guidelines concentrate on the proper employment of
cryptographic primitives [23,22]. In this respect, encryption and hashing algo-
rithms are considered the mainstream tools in the quiver of the PM developers
to protect private information, even though key management remains an impor-
tant matter in the whole process. Along the same line, obfuscation techniques
can be used to hide essential information when loaded in memory; note that the
obfuscation pattern must remain secret, which indeed is a form of security by
obscurity. Moreover, the pattern should be frequently changed, which also entails
management operations, and naturally, there is no silver bullet that can ensure
key management security horizontally. No less important, OWASP suggests that
private data should be stored only when necessary during the application life cy-
cle [22] and remain the minimum possible time in the RAM [24]. This can be
achieved through spawning garbage collection requests soon after every critical
10 E. Chatzoglou et al.

operation, or by overwriting the content of a critical object once the object is

no longer needed.
Another commonly used technique when it comes to the application devel-
opment stage is to eliminate variable copies [6]. Precisely, modern programming
languages afford several operations on variables, which essentially create copies
of the same information in the memory stack; each variable assignment creates a
copy of the same information. This might be the case with the scrutinized PMs,
as Table 2b confirms that both the master and entry passwords were identified
multiple times in the respective memory dumps. In turn, this facilitates an at-
tacker to monitor the repeating piece of data, subsequently revealing repeating
private information and the associated byte patterns. Another relevant point is
that some PMs, including Keeper do provide an option for wiping secret data
after the PM is automatically locked. Nevertheless, this option is provided as
opt-in and it is disabled by default, which does not abide by the well-known
principle of establishing security defaults, namely establish default secure set-
tings and possibly provide opt-in and opt-out. Even more, a minority of PMs
support Two-Factor Authentication (2FA), which is positively appraised. Nev-
ertheless, in some of them, the 2FA token created during user sign-in with the
PM leaks in the memory as well.
Last but not least, as already pointed out in Sections 2 and 3.3, developers
should also take advantage of the UAC mandatory access control enforcement
feature, which limits the ability of malicious code to execute with administrator
privileges. By means of UAC, every application that needs the administrator
access token must prompt the end-user for approval, the so-called “elevation
prompt”. Typically, when a user runs a process, that process executes with their
token and can do anything the user can do; in short, a token says who you are
and what you are allowed to do. In this context, every time a Windows thread
wishes to access a protected object, the operating system conducts a security
check. With reference to subsection 3.3, vendors can potentially capitalize on
the so-called Protected anti-malware services, also known as PPL [20]. This
enables specially-signed programs to run in a way that they are invulnerable
to tampering and termination, even by administrative users. On the downside,
running a PM with administrative rights to enable PPL, may open the door
for privilege escalation attacks through DLL sideloading, e.g., as given in CVE-
2023-48861.

5 Related Work

This section elaborates on the related work on PM security, concentrating on

publications from the past decade. The first set of related works focuses on appli-
cations that expose sensitive data while running on different operating systems,
namely Windows, Linux and Android. [2] investigated the potential leakage of
private data from Android applications residing in RAM. According to the find-
ings, 29 out of 30 applications were found to disclose information that facilitated
the retrieval of user passwords. A similar research in [15] presented an analysis
of Android applications, including PMs, regarding the persistence of passwords
 Keep your memory dump shut: Unveiling data leaks in password managers 11

in system memory even after they are not needed. Based on their results, one
of the main components responsible for leaking private information is UI wid-
gets. To address this, they proposed an enhancement to the Android platform by
introducing the SecureTextView, a secure version of Android TextView, which
employs the zeroization of specific buffers. In a related research [19], the authors
explored zeroization techniques across MS Windows and Linux environments.
They concluded that only the MS Windows operating system provides a reliable
function that can be used for this purpose. Finally, they showcased credential
extraction from memory allocated to browsers, highlighting potential security
vulnerabilities.
Extending the analysis to web-based PMs that offer standalone applications
and/or browser extensions, the authors of [21] conducted a security evaluation
of seven web-based PMs. Their evaluation covered both the standalone appli-
cation and browser extension-based versions, encompassing the entire PM life-
cycle, from password generation and storage to autofill functions. Despite the
improvement of the scrutinized PMs in terms of security compared to prior eval-
uations, persistent issues remain. These include unencrypted metadata, insecure
defaults, and vulnerabilities to clickjacking attacks. The authors explored the
methods that each of the PMs utilizes to securely store client data in the re-
spective database files. However, they overlooked the manner in which the very
same data are treated by the host’s OS and how they are stored in RAM.
In the same vein, the authors in [16] performed a security analysis of five
web-based PMs, uncovering varying susceptibilities across all the examined PMs.
Among the identified vulnerabilities were issues related to logic and authoriza-
tion, misinterpretation of the web security model, and sensitivity to CSRF/XSS
attacks. Nevertheless, the authors specifically focused on vulnerabilities stem-
ming from the web-based nature of PMs. In contrast, our study takes a differ-
ent angle by delving into the local security posture of PMs, with a particular
emphasis on examining how sensitive data are stored within the users’ RAM.
Another study [3] presented flaws in the LastPass browser extension. In this
work, the authors performed a password extraction attack directly from the ex-
tension’s memory while the extension was active. In their research, Zhao, Yue,
and Sun [32] provided a vulnerability analysis of LastPass and Roboform, which
both provide browser extensions for operating the software and cloud storage
of the passwords. They identified potential threats, including the storage of cre-
dentials in plaintext locally and/or on cloud servers. Additionally, they provided
recommendations to enhance data protection measures, improving the overall
security level of these products.
A second set of works focused on data leakage during the autofill function
that modern PMs offer. The authors of [28] studied how different PMs han-
dle automatic filling of passwords. Their work encompassed three categories of
password managers: (a) built into browsers, (b) used in mobile devices, and (c)
3rd party applications. Their findings suggested that the various autofill poli-
cies followed by these tools can expose users to serious risks, such as a remote
attacker stealing multiple passwords from their PM without their knowledge.
12 E. Chatzoglou et al.

Similarly, [11] presented a technique, called AutoSpill, to leak users’ saved cre-
dentials during an autofill operation on a webpage loaded into an application’s
WebView.
As a third tendency, some authors have followed forensic techniques to study
the security of PM applications. In [12], three desktop PMs were analyzed,
namely KeePass, Password Safe, and RoboForm, following a systematic forensic
analysis approach. The findings of this study showed that unencrypted passwords
and sensitive data were found in the clipboard, Temp folders, Page files, or the
Recycle Bin. Moreover, the authors of [27] followed a digital forensic procedure
to analyze the storage security of two Android PM applications. Their focus is,
however, on protecting long-term data stored in Android devices, leaving out
attacks targeting encryption keys in main system memory.
In a similar direction to our work, [17] scrutinized the security of three open-
source PMs against various types of attacks, both new and already known. The
PMs they studied were Passbolt, Padlock, and Encryptr; among other vulnerabil-
ities, the authors found that all three applications were susceptible to keyloggers
and clipboard attacks. Additionally, the authors of [5] analyzed five popular
PMs against already disclosed and newly discovered vulnerabilities. Notably,
their findings indicated that four of the five studied PMs, namely Dashlane,
LastPass, Keeper, and RoboForm, were prone to clipboard attacks.
When it comes to tools for password recovery from PMs, LaZagne [1] is an
open-source application capable of retrieving locally stored computer passwords.
It supports various methods that applications use to store their passwords, such
as plaintext, APIs, custom algorithms, and databases. Among the supported ap-
plications are popular browsers, mail clients, chat apps, databases, and memory
dumps from password managers such as Keepass. Pandora [4], the tool we have
developed for our experiments, centers specifically on PMs and delves deeper
than LaZagne. It uncovers passwords that are inadequately managed by 18 dif-
ferent implementations of PMs, spanning Windows apps, browsers, and browser
plugins.

6 Conclusions

Password credentials are still the dominant way to perform user authentication.
Nevertheless, with the numerous accounts that the average user manages today,
it is challenging to create secure passwords while at the same time remembering
them by heart. PMs come with the pledge to fill this gap by proposing strong
passwords and storing them securely on desktop and mobile devices. But leaving
aside the convenience provided by such applications and the widely held opinion
that they are safe to use, can they really be trusted to fully deliver what they
promise?
This paper provides an up-to-date security analysis of the main desktop
and browser plugin PMs. This is done under the strong but viable assumption
that the adversary has somehow gained access to the local system, being also
capable of dumping the respective processes. Our findings suggest that, across
six representative from an end-user’s viewpoint scenarios, 75% of desktop PMs
 Keep your memory dump shut: Unveiling data leaks in password managers 13

and 83% of browser PM plugins store passwords in plaintext in the system

memory while in use. Among others, the key issue with these security-sensitive
applications is that this “storing” is done in a way that creates patterns, which
can be easily discerned by the adversary. Even worse, this secret information not
only remains in the memory for a significant time after serving its purpose, but
it is also stored in multiple copies, making the attacker’s job easier. A possible
direction for future work is to expand this research to mobile platforms and to
several other popular applications of different kinds, including financial/banking,
team collaboration, smart home, etc.

Acknowledgements

This work is supported by the Research Council of Norway through the SFI
Norwegian Centre for Cybersecurity in Critical Sectors (NORCICS) project no.
310105 and by the European Union through the Horizon 2020 project PERSEUS
(Grant No. 101034240).

References

1. AlessandroZ: LaZagne, https://github.com/AlessandroZ/LaZagne, accessed

14/01/2024
2. Apostolopoulos, D., Marinakis, G., Ntantogian, C., Xenakis, C.: Discovering au-
thentication credentials in volatile memory of android mobile devices. In: Confer-
ence on e-Business, e-Services and e-Society. pp. 178–185 (2013)
3. Barten, D.: Client-side attacks on the lastpass browser extension (2019),
https://api.semanticscholar.org/CorpusID:153315475
4. C., E.: Pandora, https://github.com/efchatz/pandora, accessed 14/01/2024
5. Carr, M., Shahandashti, S.F.: Revisiting security vulnerabilities in commercial
password managers. In: ICT Systems Security and Privacy Protection. pp. 265–279
(2020)
6. Chapman, R.: Sanitizing sensitive data: How to get it right (or at least less
wrong. . . ). In: Reliable Software Technologies – Ada-Europe 2017. pp. 37–52 (2017)
7. Chaudhary, S., Schafeitel-Tähtinen, T., Helenius, M., Berki, E.: Usability, security
and trust in password managers: A quest for user-centric properties and features.
Computer Science Review 33, 69–90 (2019)
8. Cybernews: Chrome password managers: Best extensions in 2023.
https://cybernews.com/best-password-managers/password-managers-for-chrome,
accessed 14/01/2024
9. Fagan, M., Albayram, Y., Khan, M.M.H., Buck, R.: An investigation into users’
considerations towards using password managers. Human-centric Computing and
Information Sciences 7(1), 12 (Mar 2017)
10. Fung, B., Sands, G.: Former SolarWinds CEO
blames intern for ‘solarwinds123’ password leak,
https://edition.cnn.com/2021/02/26/politics/solarwinds123-password-intern/index.html,
accessed 14/01/2024
11. Gangwal, A., Singh, S., Srivastava, A.: Autospill: Credential leakage from mobile
password managers. In: Proceedings of the Thirteenth ACM Conference on Data
and Application Security and Privacy. pp. 39–47 (2023)
14 E. Chatzoglou et al.

12. Gray, J., Franqueira, V.N.L., Yu, Y.: Forensically-sound analysis of security risks
of using local password managers. In: 2016 IEEE 24th (REW). pp. 114–121 (2016)
13. hfiref0x: Defeating windows user account control,
https://github.com/hfiref0x/UACME#readme, accessed 14/01/2024
14. Kotadia, M.: Gates predicts death of the password,
https://www.cnet.com/news/privacy/gates-predicts-death-of-the-password,
accessed 14/01/2024
15. Lee, J., Chen, A., Wallach, D.S.: Total recall: Persistence of passwords in android.
Proceedings 2019 Network and Distributed System Security Symposium (2019),
https://api.semanticscholar.org/CorpusID:142503488
16. Li, Z., He, W., Akhawe, D., Song, D.: The {Emperor’s} new password manager:
Security analysis of web-based password managers. In: 23rd USENIX. pp. 465–479
(2014)
17. Luevanos, C., Elizarraras, J., Hirschi, K., Yeh, J.h.: Analysis on the security and
use of password managers. In: 2017 18th (PDCAT). pp. 17–24 (2017)
18. Machine, W.: Counterpane systems brings the se-
curity of blowfish to a password database,
https://web.archive.org/web/19980119124510/http://www.counterpane.com/passsafe.html,
accessed 14/01/2024
19. Malliaros, S., Ntantogian, C., Xenakis, C.: Protecting sensitive information in the
volatile memory from disclosure attacks. In: 2016 11th International Conference
on Availability, Reliability and Security (ARES). pp. 687–693 (2016)
20. Microsoft: Protecting anti-malware services, https://learn.microsoft.com/en-us/windows/win32/services/prot
accessed 14/01/2024
21. Oesch, S., Ruoti, S.: That was then, this is now: A security evaluation of pass-
word generation, storage, and autofill in browser-based password managers. In:
Proceedings of the 29th USENIX. pp. 2165–2182 (2020)
22. OWASP: Cryptographic storage, https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_C
accessed 14/01/2024
23. OWASP: Secure product design, https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Ch
accessed 14/01/2024
24. OWASP: Testing memory for sensitive data.
https://mas.owasp.org/MASTG/tests/android/MASVS-STORAGE/MASTG-TEST-0011/,
accessed 14/01/2024
25. PASCU, L.: 29 vulnerabilities found in android password managers,
https://www.bitdefender.com/blog/hotforsecurity/29-vulnerabilities-found-in-top-rated-password-man
accessed 14/01/2024
26. Pearman, S., Zhang, S.A., Bauer, L., Christin, N., Cranor, L.F.: Why people (don’t)
use password managers effectively. In: SOUPS 2019. pp. 319–338 (2019)
27. Sabev, P., Petrov, M.: Android password managers and vault applications: Data
storage security issues identification. J. Inf. Secur. Appl. 67(C) (2022)
28. Silver, D., Jana, S., Boneh, D., Chen, E., Jackson, C.: Password managers: Attacks
and defenses. In: 23rd USENIX. pp. 449–464 (2014)
29. sysdig: Keepass cve-2023-32784: Detection of processes memory dump.
https://sysdig.com/blog/keepass-cve-2023-32784-detection/, accessed
14/01/2024
30. Turton, W., Mehrotra, K.: Colonial Pipeline,
https://www.governing.com/security/bad-password-gave-colonial-pipeline-hackers-access,
accessed 14/01/2024
31. Wired: The best password managers to secure your digital life.
https://www.wired.com/story/best-password-managers/, accessed 14/01/2024
 Keep your memory dump shut: Unveiling data leaks in password managers 15

32. Zhao, R., Yue, C., Sun, K.: Vulnerability and risk analysis of two commercial
browser and cloud based password managers. Academy of Science and Engineering
Science Journal 1, 183–197 (2013)