On The Security of Password Manager Database Formats

On The Security of Password Manager Database Formats
On The Security of
Password Manager Database Formats
Paolo Gasti and Kasper B. Rasmussen
Computer Science Department
University of California, Irvine
Abstract. Password managers are critical pieces of software relied upon
by users to securely store valuable and sensitive information, from online
banking passwords and login credentials to passport- and social security
numbers. Surprisingly, there has been very little academic research on
the security these applications provide.
This paper presents the first rigorous analysis of storage formats used
by popular password managers. We define two realistic security models,
designed to represent the capabilities of real-world adversaries. We then
show how specific vulnerabilities in our models allow an adversary to
implement practical attacks. Our analysis shows that most password
manager database formats are broken even against weak adversaries.
As the number of services offered on the Internet continues to increase, the number
of passwords an average user is required to remember increases correspondingly,
to the point where it is no longer feasible for most people to remember a new,
strong password, for every account.
Users typically solve this problem in one of two ways. A common solution
is to reuse the same password on many different websites [39]. This approach
increases the potential damage if a password is stolen, cracked, or if a service that
has access to it is compromised, since the attacker will be able to reuse it on all
online services that share the password. Another approach is to use a “password
manager” to store strong (random) passwords for each site. A password manager
is a piece of software that requires a user to remember a single strong master
password, used to decrypt the password manager’s database. Remembering a
single master password is much more feasible for users, who still get the security
benefits of using a different password for each online service.
Using a password manager has other potential benefits. Full URLs (or at least
domain names) of are typically stored alongside the corresponding passwords,
and used to fill login form automatically. As such, users who rely on password
managers are less susceptible to typo-squatting and phishing attacks [11,19]: even
if a user is directed to a malicious website that is designed to look identical to
the website the user expects, the password manager will not log in automatically,
providing an extra layer of protection.
Due to the sensitivity of the information typically stored in password databases,
most password managers protect their content from unauthorized access. Database
formats typically rely on encryption for data protection, where the encryption/decryption key is generated from a master password entered by the user.
This protection is also often designed to allow users to store the password
manager database on untrusted storage. Several producers of password managers
suggest storing password databases on USB sticks [34, 36, 38], in the cloud [1, 23]
or on mobile devices [2, 4, 26], to allow convenient access to stored passwords.
These storage options however, can also enable potential attackers to get hold of
the database. Even when a password database is stored on a local hard drive, it
may be possible for an attacker to obtain a copy through other means.
If the password manager database format is insecure, then all the advantages
of a good password manager are wasted and the user may actually be less secure
and more susceptible to, e.g., leakage of private information: privacy-conscious
users may want to keep their browsing habits private and therefore delete cookies,
history and cache often. On the contrary, password managers represent long-term
storage facilities, storing (ideally) the only copy of passwords, and therefore
their content is typically never deleted. If a password manager database leaks
information about browsing habits, e.g., by storing URL’s unencrypted, then
clearing the cache and browsing history does not prevent an attacker from learning
sensitive information.
In this paper we analyze the security provided by the database formats of
some of the most poplar password managers in use at the moment. We define two
different adversaries: a passive attacker that only tries to infer information from a
password database, and an active attacker that modifies the content or meta-data.
We highlight that using “industry standard practices”, such as AES-CBC, is not
enough to obtain a secure database format, even assuming the implementation of
AES-CBC is correct. Note that we do not attempt to provide an exhaustive list
of all possible attacks on all password managers. Rather, we model the security
provided by common password manager database formats and provide examples
of practical attacks.
The rest of this paper is organized as follows: Section 2 provides a brief overview
of password managers used in our study; Section 3 introduces our system- and
attacker models, while we present our security definitions in Section 4. Section 5
analyzes the various database formats. In Section 6 we discuss various general
issues regarding database formats, and Section 7 covers related work. We conclude
in Section 8.
Overview of Password Managers
Password managers differ in many aspects, including database format, functionality, availability of source code, supported platforms and access to cloud
storage. Table 1 summarizes the main features of the password managers we
considered. Some popular password managers invent their own database format,
used exclusively by them. This is especially true for the password managers
Source Platform
Google Chrome [17] Chrome
local/cloud X Win/Mac/Linux
Mozilla Firefox [29] Firefox
local/cloud X Win/Mac/Linux
Internet Explorer [27] MSIE
× Win
1Password [2]
local/cloud × Win/Mac
KeePass 1.x [22]
X Win
KeePass 2.x [22]
KDB/KDBX4 local
X Win/Mono
KeePassDroid [4]
KDB/KDBX4 local
X Android
KyPass [26]
KDB/KDBX4 local
PassDrop [35]
KDB/KDBX4 local
× iOS
PINs [33]
× Win
Password Safe [31]
PasswordSafe local
X Win
Password Gorilla [13] PasswordSafe local
X Win/Mac/Linux
Roboform [37]
local/cloud × Win/Mac/Linux
Table 1. This table shows the password managers that where analysed in detail, along
with the database format used by the software, the storage options available and the
platforms supported. In addition we indicate whether the source code is available and
whether the password manager is integrated with a browser.
embedded in major browsers. We include these in our analysis because these
password managers are widely used [15]. Several stand-alone password managers
share the same database format, so even though each password manager provide
a different experience to the user, the underlying storage format is the same.
In the rest of this paper focus solely on database formats and the security they
provide, rather than on each password manager implementation. We assume that
the password managers themselves correctly implement what the format specifies.
As such, we do not consider, e.g., side channel attacks on the cryptographic
primitives, or other attacks against the implementation. Rather we investigate
the best possible security achievable given a specific storage format. For this
reason our analysis focuses primarily on password managers that provide local
storage, at least as an option. We leave the analysis of “cloud-only” password
managers to future work.
We investigate nine popular password database formats. Three database
formats used by in-browser password managers: Google Chrome, Mozilla Firefox
and Microsoft Internet Explorer; and six formats used by a large number of
stand-alone password managers: 1Password, KDB, KDBX4, PasswordSafe v3,
PINs and RoboForm (refer to Table 1.)
Adversary and System Model
We consider two efficient adversaries: Advr who has read access to the password
database, and Advrw who has read-write access. The goal of both adversaries is
to extract as much information as possible and, for Advrw , to produce a database
that (1) was not created by the user and (2) once opened, will not trigger any
warning or error message from the password manager. Clearly, Advrw is strictly
stronger than Advr : any attack that can be performed by Advr is also available to
Advrw . Both adversaries are allowed to gather multiple snapshots of the database
at different points in time, in order to detect modifications in the database
We emphasize that our analysis does not rely on any modification of the user
environment, e.g., tampering with the password manager code or installing a
key logger. We focus solely on the security provided by the password manager
databases, when the password manager software is operated in the “most secure”
setting provided. We assume that users choose a strong, high-entropy, master
password and that all underlying cryptographic algorithms (e.g., encryption,
MAC, etc.) are properly implemented. Additionally, we assume that no additional
mechanisms are in place to prevent file tampering. This allows us to compare
the security offered by the database formats themselves.
Untrusted Storage
Consider an adversary who has full access to an encrypted password database,
and is able to record different versions of it. Such an adversary can clearly use any
of the recorded versions to replace the current database, as long as the master
password did not change. This is essentially a replay attack that applies to both
cloud-based- and local database formats.
The security notions we define below do not capture this attack, nor do we
attempt to address it in any other way. In order to protect against it, a password
manager must maintain some local state (e.g., a hash of the latest version of the
encrypted database) on a trusted medium. As such, while this attack is clearly
relevant when a password database is stored on the cloud or on an unattended
USB drive, it cannot be mitigated by the database format alone. Therefore we
exclude it from our analysis.
Security Definitions
We model password managers by defining four algorithms that represent various
functionalities: Setup, Create, Open and Valid. These algorithms are defined as
Definition 1. A password manager PM consists of the following efficient algorithms: Setup(·) a probabilistic algorithm that, given a security parameter 1κ ,
outputs a master password mp; Create(·, ·) a probabilistic algorithm that, on input
mp and a set of triples RS = {(r1 , n1 , v1 ), . . . , (r` , n` , v` )} (which represents a
record-set), outputs a database DB; Open(·, ·) a deterministic algorithm that,
given mp and a database DB, outputs the record-set RS encoded in DB if RS is
a valid record-set, i.e, there exist DB 0 such that DB 0 ← Create(mp, RS), and ⊥
otherwise; and Valid(·, ·) a deterministic algorithm that takes as input a master
password mp and a database DB and returns 1 if Open(mp, DB) 6=⊥.
In practice, Valid is implemented by password managers within the Open
functionality: if validation fails, the password manager returns an error rather
than the database content. We also define two new games, indistinguishability of databases game (IND-CDBA) and malleability of chosen database game
(MAL-CDBA). The former captures the capabilities of a realistic passive adversary,
i.e., an adversary that has read-only access to a password database. The latter
models and active adversary, which is allowed both read and write access to a
password database.
Game 1 (Indistinguishability of databases game IND-CDBAAdvr ,PM (κ)) A
challenger Ch running PM interacts with Advr in as follows:
– Ch runs mp ← Setup(1κ ).
– Advr outputs two record-sets RS0 , RS1
– Ch selects a bit b uniformly at random and the database DBb ← Create(mp, RSb )
is returned to Advr .
– Advr eventually outputs bit b0 ; the game outputs 1 iff b = b0 .
We say that Advr wins the IND-CDBA game if it can cause it to output 1.
Definition 2 (IND-CDBA security). A password manager PM = (Setup,
Create, Valid, Open) is IND-CDBA-secure if there exists a negligible function negl
such that, for any probabilistic polynomial time adversary Advr , we have that
Pr[IND-CDBAAdvr ,PM (κ) = 1] ≤ 1/2 + negl(κ).
For most database formats an attacker can trivially win the IND-CDBA game
by submitting two record-sets of different sizes. In practice, this corresponds to
the fact that the size of the database file is often roughly proportional to the
number of records in the database and therefore an adversary may be able to infer
information by simply observing the size of an encrypted database. While we do
consider this a valid attack, we ignore it in the vulnerability analysis. Database
formats that are only vulnerable to this attack will be considered secure.
Game 2 (Malleability of chosen database game MAL-CDBAAdvrw ,PM (κ))
A challenger Ch running PM interacts with Advrw in the following way:
– Ch runs mp ← Setup(1κ ).
– Advrw adaptively outputs n record-sets RSi and receives, from Ch, the corresponding databases DBi ← Create(mp, RSi ).
– Advrw eventually outputs DB 0 ; the game outputs 1 iff Valid(DB 0 ) = 1 and
DB 0 6= DBi for i ≤ n.
We say that Advrw wins the MAL-CDBA game if it can cause it to output 1.
Definition 3 (MAL-CDBA security). A password manager PM = (Setup,
Create, Valid, Open) is MAL-CDBA-secure if there exists a negligible function negl
such that, for any probabilistic polynomial time adversary Advrw , we have that
Pr[MAL-CDBAAdvrw ,PM (κ) = 1] ≤ negl(κ).
Our definition of MAL-CDBA security is equivalent to the notion of “existential
unforgeability” of ciphertexts, introduced in [21]. As shown in the same paper,
this security notion along with IND-CPA security implies IND-CCA security.
“Integrity of ciphertexts” [6] (also known as INT-CTXT security) is a related security notion. In particular, the main difference between MAL-CDBA
and INT-CTXT is that an adversary for INT-CTXT is also given access to the
Verify(mp, ·) oracle.
We argue that MAL-CDBA security (together with IND-CDBA security) is
an appropriate security notion for a password manager database format in
practice. Consider a database format that is not MAL-CDBA-secure, i.e., where
Advrw can compute the encryption of a record-set of its choice, and produce
the corresponding valid output DB 0 . This format would be vulnerable to the
following four-step attack:
(1) Advrw replaces Alice’s password database DB with a new database
DB 0 containing the login credentials for an amazon.com account created
by Advrw . (2) Advrw now induces Alice to go to amazon.com, at which
point the password manager automatically logs into the account created
by Advrw . (3) Alice buys something; during checkout, Alice is requested
to add her credit card to the account; since she trusts amazon.com,
she complies. (4) Advrw now replaces DB 0 with Alice’s original password
Advrw is now in possession of an account which can be used to purchase goods
on Alice’s behalf. It is very hard for Alice to detect this attack; she does not
receive any warning from her password manager or from amazon.com, since the
database is well formed and the login information corresponds to an existing
account. Additionally, SSL/TLS does not help since Alice is communicating
with amazon.com. Furthermore, Alice may not even be able to find out which
username was used in the maliciously crafted account after the adversary restores
her original password database.
In the next section we shed light on the relationship between our notion of
IND-CDBA-security and the standard IND-CPA-security.
Relationship Between IND-CPA and IND-CDBA
In this section we show that IND-CPA security implies IND-CDBA security. Let
Π = (Setup, Enc, Dec) be a IND-CPAAdvr ,Π (κ)-secure encryption scheme. We recall
the standard definition of IND-CPA security [20]:
Game 3 (IND-CPAA,Π (κ)) Indistinguishability of chosen plaintext attack. A
challenger Ch running Π interacts with A as follows:
Ch runs mp ← Setup(1κ ).
A is given oracle access to Encmp (·)
Eventually A outputs two same size messages RS0 , RS1
Ch selects a bit b uniformly at random and the ciphertext DBb ← Enc(mp, RSb )
is returned to A.
– A eventually outputs bit b0 ; the game outputs 1 iff b = b0 .
Definition 4 (IND-CPA security). An encryption scheme Π = (SetupΠ , EncΠ ,
DecΠ ) has indistinguishable encryptions under chosen plaintext attack if there
exists a negligible function negl(·) such that for any efficient adversary A,
Pr[IND-CPAA,Π (κ) = 1] ≤ 1/2 + negl(κ).
We show that IND-CPA security implies IND-CDBA security. Let Π = (Setup,
Enc, Dec) be a IND-CPAAdvr ,Π (κ)-secure encryption scheme.
It is easy to see that IND-CPAA,Π (κ) security implies IND-CDBAAdvr ,PM (κ)
security. Let PM = (Setup, Create, Open, Valid) where Setup = SetupΠ , Create =
EncΠ , Open = DecΠ and Valid is defined as in Section 3.
Assume Advr is an adversary that has a non-negligible advantage in the
IND-CDBA game. We show how to build a simulator SIM that uses Advr to win
the IND-CPA game. SIM lets Advr choose RS0 and RS1 , and forwards these to Ch.
Ch returns DBb which is forwarded to Advr . Eventually Advr outputs its choice
for b0 , and SIM uses it to answer the challenger. Since (Setup, Create, Open) is
defined as (SetupΠ , EncΠ , DecΠ ), Sim’s advantage is identical to Advr ’s.
Database Format Vulnerabilities
We now present our analysis, which includes several database formats currently
in use by stand-alone and browser-based password managers. For each format,
we provide a short description of the relevant features and analyze its security
with respect to the security model defined in Section 3. If the format allows for
different levels of security, we analyze the most secure configuration.
Google Chrome
Format Description. Google Chrome stores usernames and passwords in an
SQLite database file in the user profile directory. This database provides neither
secrecy nor integrity.
Google Chrome can optionally store all browser preferences (including passwords) on Google’s servers to allow synchronization between different devices.
Chrome’s support pages claim that passwords are stored in encrypted form on
Google’s servers [18].
Security Analysis. Any user with access to the database file can recover all its
content and make arbitrary modifications. As such, users cannot rely on Chrome’s
password manager for integrity or secrecy of their data, and should implement
additional security layers around it.
Mozilla Firefox
Format Description. Mozilla Firefox stores login data in an SQLite database.
Users can specify an (optional) master password that is used to encrypt the
database content. URLs are always stored unencrypted regardless of whether a
master password is used or not.
Since the database is part of Firefox’ user profile, it can be automatically
synchronized across multiple devices, either through Firefox Sync [30], manually
(e.g., using rsync [25]), or stored on a USB stick and used on different computers.
Security Analysis. Firefox does not provide an effective protection against
Advr . In order to win in the IND-CDBA game, Advr creates two same-size recordsets RS0 , RS1 which differ in at least one URL field. The encrypted database
DBb can be immediately identified since URLs are not concealed. In practice
that means that an attacker can learn a considerable amount of information,
such as the websites in which the user has password-protected access, and it can
mount effecting phishing attacks based on user information. Moreover, given two
different versions of the same database, the attacker can identify which entries
have been modified and their corresponding domain name.
Similarly, given any non-empty database DB an active adversary Advrw can
trivially win the MAL-CDBA game by building DB 0 from DB replacing one
or more URLs with a different valid URL. Since the entries are not integrity
protected, Firefox cannot detect such an attack. This can be used to mount a
very effective man-in-the-middle attack by replacing legitimate domain names
with fraudulent ones controlled by Advrw . In this way, the password manager will
automatically submit sensitive information to an adversary-controlled website.
The attack is even more effective if Advrw can also modify Firefox’ bookmark
database, which is stored in the profile alongside the password database.
Microsoft Internet Explorer
Format Description. Internet Explorer stores usernames and passwords
in the registry. Each record is stored as a separate registry entry and encrypted using the system login credentials. When a user fills-in a password
form at address url, Internet Explorer computes h = SHA-1(url) (where and
url uses the unicode character set) and encrypts username and password as
c = Ek (metadata k username k 0x00 k password k 0x00), where metadata
contains additional information such as the size of encrypted elements.
The encryption is performed using the CryptProtectData [28] system call,
which uses Triple-DES in CBC mode and a hash-based MAC. k is derived from
(1) a random salt (also stored in the ciphertext), (2) url and (3) the Windows
login credential for the current user. Finally, Internet Explorer creates a new
registry entry with key h and value c.
The security of Internet Explorer’s password manager depends on the strength
of the user account password. As such, accounts with no password provide no
protection of the password database.
Security Analysis. Internet explorer is not secure against Advr . Similarly to
Firefox, Advr wins the IND-CDBA game by building two same-size record-sets
RS0 , RS1 which differ in at least one URL.
Say record rec with URL url is in RS0 but not in RS1 . Advr can immediately
recognize which record-set corresponds to the challenge DBb by computing h =
SHA-1(url) and verifying whether h is in DBb .
In practice, a passive adversary can use Internet Explorer’s password database
to determine whether a user has visited a particular web page and entered his
username/password, even if the user deletes his browsing history and cache.
Assuming that CryptProtectData uses a secure MAC, an active adversary
cannot alter password entries. However, Advrw can delete password entries by
removing the corresponding registry entry, and as such Advrw can easily win the
MAL-CDBA game.
Format Description. 1Password stores its database in multiple files. Each file
contains a database entry, stored in JavaScript Object Notation (JSON). Entries
are listed in an index file called “content.js”.
1Password allows users to select a different “security level” for each record [3].
The lowest security level corresponds to unencrypted entries, while the highest
level means that sensitive fields, such as username and password, are encrypted
with a key derived from the user’s master password. Regardless of the security
level, some fields, e.g., the title of an entry, are never encrypted. We analyze the
protection offered by the highest security level.
The encryption scheme used is AES-128 in CBC mode. Neither the records
nor the index file are integrity protected. As a result, database corruption is only
detected when the JSON parser fails to process the database.
Security Analysis. 1Password’s database format is affected by vulnerabilities
that give adversaries a non-negligible advantage in both the IND-CDBA and
MAL-CDBA games.
Advr can win IND-CDBA with probability 1 as follows: Advr builds two samesize record-sets RS0 , RS1 such that there exist two records r0 , r1 from RS0
and RS1 respectively, which differ in at least one of the following fields: title,
location, locationKey, createdAt, updatedAt or typeName. These fields correspond to: the title of the record, the record URL, the URL used by the browser
plugin to perform auto-complete, the time of creation and last update and the
type of record (e.g., web form, protected note, credit card information). Since
these fields are never encrypted, Advr can trivially determine bit b by testing
which record belongs to DBb . In practice this means that an adversary with
access to a 1Password database can read these fields and thus gather sensitive
information about the user’s browsing habits.
Advrw can win the MAL-CDBA game with probability 1 as follows. Advrw
selects an arbitrary record-set RS and receives the corresponding database DB.
Then, Advrw can (1) alter any of the fields listed above, and/or (2) remove any
entry by deleting the corresponding database file and altering the “content.js”
index file correspondingly. In general, as long as the database is still composed of
a set of correct JSON strings, 1Password will not show any warning. In practice,
this means that an adversary can mount phishing attacks by replacing a legitimate
URL with one pointing to an adversary-controlled website.
Additionally, if Advrw outputs at least two record-sets, say RS 6= RS 0 and
receives the corresponding databases DB, DB 0 in the MAL-CDBA game, it can
construct DB 00 selecting records from both DB and DB 0 . This allows an adversary,
among other things, to replace individual records in a database with older versions.
KDB (aka KeePass 1.x)
Format Description. The KDB database is composed of a single file, divided
in two sections: an unencrypted header (hdr) and an encrypted body (bdy). bdy
stores the encryption of the various database entries. hdr contains, among other
things, the number of groups and entries in the database and the hash of bdy
before encryption [22]. This hash is computed every time the database is modified,
and is used to check integrity. After decryption, the password manager verifies
that the computed plaintext hashes to the same value stored in hdr. If this check
fails, the application reports that either the database is corrupted or the master
password entered by the user is incorrect.
Security analysis. Given a database DB, the hash stored (unencrypted) in hdr
is computed deterministically from the record-set RS encoded in DB. This allows
an adversary Advr to win the IND-CDBA game with probability 1 as follows.
Advr selects two same-size record-sets RS0 =
6 RS1 and computes their hash
hi = H(RSi ). Once it receives a challenge database DBb , Advr checks whether
the header of DBb contains h0 or h1 and outputs its choice for b0 accordingly.
In practice, given two databases, this allows Advr to determine whether their
content is identical even if their corresponding ciphertexts are different. Also,
assuming that the record-set encrypted in a database has lower entropy than
the database master password, Advr can recover the content of the record-set by
simply making a guess and comparing it against the hash value in hdr. In other
words, the complexity of breaking the database is a function of min(ηmp , ηRS ) –
where ηmp is the entropy of the master password and ηRS is the entropy of the
record-set – rather than just a function of the master password.
hdr is not authenticated and, as such, is susceptible to malicious modifications.
This can be used by Advrw to win the MAL-CDBA game with probability 1 by
selecting a challenge record-set RS which contains one or more entries. When
Advrw receives DB he changes the value corresponding to the number of entries
(stored in hdr) to a smaller number. Since bdy is not altered, the hash verification
does not fail. However, the record-set has been altered since the number of entries
shown in the password manager is now the one chosen by Advrw .
We verified that the latest version of KeePassX (0.4.3) is susceptible to this
attack. Moreover, if the victim makes any change in the modified database,
KeePassX stores only the entries displayed. This can lead to silent (undetected)
corruption of the database.
KDBX4 (aka KeePass 2.x)
Format Description. The KDBX4 database format is composed of a single
password-protected file, divided in two sections: an unencrypted header (hdr) and
a main encrypted body (bdy). hdr contains several fields, including mseed and
tseed (used to compute the encryption/decryption key from the user-provided
password), IV, pskey and ssbytes, used for secrecy and integrity protection as
detailed below.
bdy contains the database records encoded as a single XML string, optionally
compressed using the gzip algorithm [16] before encryption. bdy is encrypted
using AES-256 in CBC mode, although Twofish is also available. The first 32
bytes of bdy contains the encryption of the ssbytes field in order to efficiently
verify whether the provided master password is correct. The next 32 bytes of the
body contain the hash of the (possibly gzip-compressed) XML string representing
the various entries. This hash is used to detect modifications in the database.
In addition, all passwords in the XML string are XOR-ed with a pseudorandom string, computed using Salsa20 [7]. Every time the database is saved, a
random 256-bit key k is generated and stored unencrypted in the pskey field;
each password pwdi is then encoded as si = pwdi ⊕ Salsa20(k, IV ) using a fixed
value IV . Each pwdi uses a different portion of the keystream generated by
Salsa20. Passwords are recovered as pwdi = si ⊕ Salsa20(k, IV ).
Security Analysis. KDBX4 fixes some of the weaknesses of KDB. hdr does
not store the (unauthenticated) number of entries, therefore an adversary cannot
alter this value to remove content from the password database. Also, the hash of
the unencrypted record-set is now stored in encrypted form. This prevents an
adversary from verifying its guesses on the database content and from determining
whether two encrypted databases carry the same content. More generally, Advr
cannot mount any successful attack on a KDBX4 database except with negligible
A KDBX4 database is composed of an unencrypted header hdr and an
encrypted body bdy. hrd contains the following fields: file signature sig, which
is a constant used by password managers to identify KDBX4 files; database
version ver; cipher id cid, which indicates which block cipher was used to
encrypt the database (currently, the two only available options are AES and
Twofish); compression flag cflag, which indicates whether the database content
is compressed before encryption using gzip; master seed mseed, which is used
together with transform seed tseed and the number of transformation rounds
rounds to compute the decryption key for bdy; an initialization vector IV , used
for the encryption of bdy; a protected key stream pskey string, used to obfuscate
passwords; stream start bytes ssbytes, which corresponds to the first 32 bytes of
bdy and is used to verify that the provided master password is correct. Each field
is preceded by a one-byte field identifier and a two-byte field length attribute.
We observe that the values of cid and rounds are not encrypted and can be
considered as public parameters. In our analysis, we simply fix cid to identify
AES (the default value) and rounds to poly(κ) for some polynomial poly(·).
Similarly to PasswordSafe v3, also KDBX4 fixes the value κ.
Theorem 1. Assuming that AES-CBC is a IND-CPA-secure encryption scheme
KDBX4 is IND-CDBAAdvr ,KDBX4 (κ)-secure.
Proof. (Sketch) Let A be a PPT algorithm. We claim that A cannot distinguish
between the following distributions:
D0 = {(db, m) | mp ← {0, 1}κ ; m ← M; db ← Create(mp, m)}
D1 = {(db, m) | m ← M; f lds ← OrKDBX4 (m);
bdy ← {0, 1}|m| ; db = Encode(f lds)kbdy}
where OrKDBX4 (m) outputs a set of fields, corresponding to the fields in a KDBX4
database, computed as detailed below. Encode(f lds) takes in input a set of fields
and outputs their encoding as in a KDBX4 database, i.e., field type followed by
field length and value – except for sig and ver, which are simply copied as is.
WLOG, in this proof we assume that no compression is applied to the recordset.
OrKDBX4 (m) builds the various fields as follows: it sets sig, ver, cflag, ciphid
and rounds to their respective public values. Then it sets mseed, tseed, IV, pskey
and ssb to random strings of appropriate lengths. Since Create(·, ·) selects these
values from the same distribution, A cannot use them to distinguish distributions
D0 and D1 .
bdy from distribution D0 is computed by Create(·, ·) as the AES-CBC encryption of m with initialization vector IV and key derived from mp, mseed, tseed
and rounds. However, since such encryption is indistinguishable from a random
string for any PPT algorithm, A cannot distinguish distributions D0 and D1 .
Therefore, it is easy to see that Advr can guess b0 = b with only negligible advantage: since both the distributions defined by Create(mp, RS0 ) and
Create(mp, RS1 ) are indistinguishable from the distribution defined by OrKDBX4 (m)
for |m| = |RS0 | = |RS1 |, we have that the distribution of Create(mp, RS0 ) and
Create(mp, RS1 ) are indistinguishable for Advr .
Unfortunately, this format introduces new vulnerabilities. Similarly to KDB,
the main problem of this format is the lack of authentication of hdr. As such, is it
susceptible to modifications. In particular, Advrw can win the MAL-CDBA game
with probability 1 as follows. Advrw outputs a challenge record-set RS. Then,
after receiving the corresponding database DB, it replaces the value stored in the
pskey field of hdr with an arbitrary 256-bit string and outputs that as DB 0 . This
modification is not detectable by the password manager, i.e., Valid(DB 0 ) = 1,
since the integrity check on the records is performed before the XOR with the
output of Salsa20. However, a different pskey value will cause all passwords to
appear as pseudo-random data after the decoding process.
It is impossible to recover from this attack unless it is detected immediately,
i.e., before the user applies any modification to the record-set. The only way
to recover the database content is to restore the original pskey value. However,
this value is replaced with a fresh one, and all passwords are “re-scrambled”
accordingly, each time the database is modified and saved. For this reason if
a user alters, and then saves, a corrupted database, all passwords previously
affected by the attack are lost forever.
This attack highlights a remarkable design flaw. Even an accidental bit-flip
in the pskey field, e.g., due to a transmission error, cannot be detected, and
leads to complete corruption of the database. Such corruption is unlikely to be
immediately detected by users, who may subsequently add new entries. Over time,
the database will be composed of both correct and corrupted entries, making it
difficult to reconstruct the damaged records from a backup.
As an extension to the previous attack, Advrw can alter pskey in such a way
that an arbitrary (small) number of bits of the first password(s) in the database
are not altered. To do that Advrw computes a value k 0 such that the first n bits
of Salsa20(k, IV ) are equal to the first n bits of Salsa20(k 0 , IV ). Then Advrw
stores k 0 in pskey. k 0 can be computed in exponential time in n, and therefore is
practical only when n is small.1
Finally, Advrw can also win the MAL-CDBA game as follows. Given an arbitrary
database DB, Advrw flips a bit in the first 16 bytes of ssbytes, and then flips the
corresponding bit in the IV field of hdr to create DB 0 . The password manager
cannot detect the change, i.e., Valid(DB 0 ) = 1, since flipping a bit in IV causes
the corresponding bit in the first block of plaintext to be flipped as well (using
CBC-mode), and no additional side effect. Since the first block of plaintext
corresponds to the first 16 bytes of ssbytes, the modification produces a new
correct database. This allows Advrw , given a database DB, to produce up to
2128 − 1 different databases DB10 , . . . , DB20 128 −1 containing the same record-set
as DB.
Format Description. The PINs database is stored in a single file, and encrypted
using AES in CBC mode. Records are encrypted separately and stored one record
per line, using hexadecimal representation written as ASCII text.
The first line of each database defines the version of the software used to
create the database, while the second line contains the encryption of the string
“#TEST VERIFY” followed by a variable number of up to fifty random bytes. This
is used to verify that the user-provided master password is correct. After deriving
the database encryption/decryption key from the user’s input, PINs decrypts
the second line and determines whether the result corresponds to the expected
Security Analysis. Each line containing user data is encrypted with AES in
CBC mode, which is known to be IND-CPA-secure [10]. As shown in Section 4.1,
IND-CPA security implies IND-CDBA security. Therefore Advr cannot extract any
information from an encrypted database, besides the number of records and their
approximate length.
As a proof of concept, we developed an application that implements such attack. The
application is available upon request.
However, PINs’ database file does not provide any kind of data integrity. As
such, an adversary can exploit the malleability of the CBC mode of operation
to modify the content of the database. Since each line is encrypted separately,
changes in one record do not affect other records. Advrw can exploit this property
to win the MAL-CDBA game with probability 1. After receiving a challenge
database DB corresponding to an arbitrary record-set RS, Advrw flips one bit in
any of the records to obtain a new database DB 0 which is considered correct by
PINs, i.e., Valid(DB 0 ) = 1. Advrw can also remove arbitrary entries, or replace
them with versions collected from different challenge databases.
PasswordSafe v3
Description. The PasswordSafe v3 database is composed of a single file containing all entries [32]. In particular, a PWDS3 database is a string:
tag k salt k iterations k H(f (mp, salt)) k E(K1 ) k
E(K2 ) k E(L1 ) k E(L2 ) k IV k c k eof k hmac
where “k” denotes string concatenation. tag is a constant that represents the
database version; salt is a random value used to derive the encryption/decryption
key from the user-provided master password; H(·) is a collision-resistant hash
function; f (·, ·) is a PRF, E(Ki ) and E(Li ) are the ECB-encryptions of two 256-bit
random values K = K1 kK2 and L = L1 kL2 under key f (mp, salt); IV is a random
initialization vector used to compute the ciphertext c = AES−CBCK (RS),
where RS is the XML-encoded recordset; eof is a constant string that represent
the end of the encrypted recordset; and hmac is the HMAC computed under all
fields from salt to eof under key L. WLOG, we assume that iterations is
computed deterministically from the security parameter κ.
Security Analysis. PasswordSafe v3 is both IND-CDBA-secure and MAL-CDBAsecure. As such, neither Advr nor Advrw can win their respective games with
non-negligible probability over 1/2.
Let db ← Create(mp, m) denote the creation of an encrypted database db
with master password mp and content m, where db conforms to the PWDS3
specifications. In the rest of this section we denote κ as a variable, even though
the PWDS3 format fixes it.
Theorem 2. Assuming that Twofish is a pseudorandom permutation, TwofishCBC is a IND-CPA-secure encryption scheme, SHA-256 is a collision-resistant
hash function and that HMAC-SHA-256 is a secure PRF, PWDS3 is
IND-CDBAAdvr ,PWDS3 (κ)-secure.
Proof. (Sketch) We now show that the distributions defined by Create(mp, RS0 )
and Create(mp, RS1 ) are indistinguishable for Advr , and therefore it can only
guess bit b with negligible advantage. Let A be a PPT algorithm. We claim that
A cannot distinguish between the following distributions:
D0 = {(db, m) | mp ← {0, 1}κ ; m ← M; db ← Create(mp, m)}
D1 = {(db, m) | m ← M; db ← OrPWDS3 (m)}
OrPWDS3 (m) outputs a string constructed as s1 k . . . k s10 where s1 = tag,
(s2 , s4 , s5 , s6 , s7 , s10 ) ← ({0, 1}κ )6 , s3 = iterations, s8 ← {0, 1}|m| and s9 =
The output of OrPWDS3 (m) (i.e., D1 ) does not carry any information about
m, except for |m|. Therefore OrPWDS3 (m) and OrPWDS3 (m0 ), where |m| = |m0 |,
are distributed identically. Let us denote by ≡ computational indistinguishac
bility. If, for any efficient algorithm, we have Create(mp, m) ≡ OrPWDS3 (m), then
Create(mp, m0 ) ≡ OrPWDS3 (m). As such, Create(mp, m) ≡ Create(mp, m0 ), and
therefore any efficient adversary has only negligible advantage in winning the
IND-CDBAAdvr ,PWDS3 (κ) game.
We now show that the output of OrPWDS3 (m) is computationally indistinguishable from the output of Create(mp, m). In particular, each field of the output of
OrPWDS3 (·) is indistinguishable from the corresponding field of Create(·).
s1 , s3 and s9 have the same value as the corresponding strings in Create(mp, m).
s2 is distributed identically to salt, which is uniformly selected from {0, 1}κ .
f (mp, salt) is a PRF, and therefore no efficient algorithm can distinguish its
output from random. As such, also H(f (mp, salt)) is indistinguishable from
random [5], and hence distributed as s4 .
Since Ki and Li for i ∈ {1, 2} are random strings and E is a pseudorandom
permeation, E(K1 )kE(K2 ) and E(L1 )kE(L2 ) are indistinguishable from random
strings. IV is random, and therefore distributes as s7 . HMAC is a PRF [5], and
therefore its output is indistinguishable from s10 for any efficient algorithm.
Finally, c is the Twofish-CBC encryption of m. IVkc is uniformly distributed in
{0, 1}|IV|+|m| for each m ∈ M for any PPT algorithm.
As such, there exist no efficient algorithm that can distinguish the distribution
of s1 , . . . , s10 from the corresponding substrings of the output of Create(mp, m),
and therefore A cannot distinguish D0 from D1 . As argued above, this implies
that Advr has only negligible advantage in winning the IND-CDBAAdvr ,PWDS3 (κ)
Theorem 3. Assuming that HMAC-SHA-256 is a Mac-Forge-secure message authentication code (as defined in Appendix A), PWDS3 is MAL-CDBAAdvrw ,PWDS3 (κ)secure.
Proof. (sketch) We prove Theorem 3 by reduction. Assume that there exists an
adversary Advrw that can – with non-negligible probability – output a database
DB 0 such that DB 0 6= DBi for each query RSi with 0 ≤ i ≤ n. Then we can build
a simulator SIM that uses Advrw to break HMAC-SHA-256 as follows.
For each query RSi from Advrw , SIM sends a string s2 k . . . k s9 , computed
using oracle OrPWDS3 (·) from Theorem 2, to the MAC oracle, which returns the
corresponding tag ti . SIM then returns s1 k . . . k s9 k ti to Advrw .
Eventually Advrw outputs DB 0 = s1 k . . . k s10 , and SIM uses (s2 k . . . k s9 , s10 )
as its output. It is easy to see that SIM wins iff Advrw wins. In fact, Valid(DB 0 ) = 1
iff HMAC-SHA-256L (s2 k . . . k s9 ) = s10 (where L is unknown to SIM).
Since SIM can win the Mac-Forge game with only negligible probability, also
Advrw can win with only negligible probability. Moreover, Advrw can only detect
the simulation with negligible probability since the distributions of Create(·, ·)
and OrPWDS3 (·) are indistinguishable, as shown in the proof of Theorem 2.
Nevertheless, we identified a design flaw that, although irrelevant in our
security model, should be considered when adopting this format.
The PasswordSafe v3 database format stores both the encryption key and the
MAC key used to secure the database content in the file header. In this way, if
the master password is changed, the database does not need to be re-encrypted.
This technique is usually adopted by encrypted file systems (e.g., [14]) to avoid
having to re-encrypt all the data if the master password is changed. However, we
believe that this choice may not be appropriate for a password database file. In
particular, every time the database is modified, IV is changed and therefore the
whole database is re-encrypted. For this reason, the reuse of the same values for
K and L does not imply any savings.
Additionally, this specification detail opens the door to an attack. Assume
that an adversary is able to obtain the master password for an encrypted database.
Using the master password, the adversary would also be able to retrieve (and
store) K and L. Subsequently, even if the user changes her master password, the
adversary can still decrypt and/or modify any new version of the database. The
only way to recover from a compromise of the master password is to completely
discard the database and create a new one, i.e., changing the master password
serves no purpose. It should be noted that some implementations that use the
PasswordSafe v3 format are not vulnerable to this attack (e.g., Password Safe [31]),
since they choose a new random K and L every time the database is saved. This
makes such implementations less efficient than they could be, but secure.
Format Description. Roboform stores its password database in several files.
Each file contains a header, which encodes two URLs: goto, which is used as a
bookmark by Roboform’s browser plugin, and match, which is used by Roboform’s
plugin to determine which username/password record should be used on each
web form.
The rest of the record is composed of a short header and an encrypted payload.
Roboform allows users to choose between AES, Blowfish, DES, Triple-DES and
RC6 for payload encryption.
Security Analysis. Roboform’s password format is vulnerable to attacks from
both Advr and Advrw in our security model.
Adversary Advr can win the IND-CDBA game with probability 1 by constructing two same-size record-sets RS0 and RS1 which differ in at least one of the
URLs in their records. Since neither the goto nor the match fields are encrypted,
Read-Only Attacker
Read-Write Attacker
Google Chrome
Mozilla Firefox
Microsoft Internet Explorer
KDB (aka KeePass 1.x)
KDBX4 (aka KeePass 2.x)
PasswordSafe v3
Table 2. Vulnerabilities overview. This table shows, for each format, whether it is
secure (X) or broken (×) in the two security games IND-CDBA and MAL-CDBA, defined
in Section 3. 1 PasswordSafe v3 is secure in our model but with an interesting design
flaw (see Section 5.8).
Advr can always identify which record-set corresponds to challenge DBb .2 In
practice, this allows Advr to gather recover a list of web site visited by the user
even if web cache and history have been deleted.
Similarly, Advrw can win the MAL-CDBA game with probability 1, since neither
of the URLs stored in Roboform’s database are integrity protected. Advrw requests
a database corresponding to an arbitrary recordset RS, and after receiving the
corresponding database DB, creates DB 0 by altering one or both URLs. The lack
of integrity protection means that Valid(DB 0 ) = 1.
In practice, an adversary can use this vulnerability to mount a phishing attack
by altering URLs and redirecting users to a malicious website designed to capture
login credentials.
Table 2 summarizes the result of our security analysis. Almost all the formats
are vulnerable to attack either in the IND-CDBA or MAL-CDBA security model,
or both. What does that mean for the use of these formats in practice? The
answer depends on the security provided by the storage mechanism that hosts the
password database. We divide the database formats into three classes: Class I :
those that can be used on an insecure storage medium. According to our analysis,
the only format in this class is PasswordSafe v3; Class II : those that can be used
if the underlying storage mechanism provides integrity and data authenticity.
This class contains KDBX4 and PINs; and Class III : those that can be used
securely only if the underlying storage provides integrity, authenticity and secrecy.
This class contains the remaining formats.
As a proof of concept, we wrote a small script that decodes the goto and match
URLs. The script is available upon request.
Class I password managers can be used safely without any special considerations, except for one caveat with PasswordSafe v3 described in Section 5.8. To
safely use Class II password managers in practice, users should make sure never
to rely on any information in the database that could have been changed by a
malicious adversary. For example, if privacy is not a concern and the password
database is kept on, e.g., a read-only smart card, KDBX4 and PINs can be used
to securely store passwords.
There is nothing inherently wrong with storing passwords in a Class III
password manager, e.g., an unencrypted text file, as long as the user is made
aware that the format provides no secrecy, integrity or authenticity. In fact, if
the user is taking additional steps to store an unencrypted password database
on a secure medium (e.g., an encrypted file system) this may be a perfectly safe
approach. As an example, Google Chrome stores passwords in a database format
that is not designed to provide security. To use the Google Chrome password
manager in practice, users should completely prevent access to the database from
any unauthorized party (e.g., other users of the same machine).
It seems fair to require that a password manager that asks users to authenticate
themselves with a password, at least provides secrecy and data authenticity.
This is currently only achieved by a single password database format, namely
PasswordSafe v3. As a general rule, a password manager should be explicit about
the security offered by the underlying database format.
Related Work
Although the concept of a password manager is well known and used by people
all over the world, there is very little scientific literature on the subject.
In 2003 Luo and Henry proposed a method for protecting multiple accounts [24]. Their solution requires a user to remember only one password,
called a common password, to access any of a number of accounts. The authors
propose a Web based implementation with a password calculator written in
In an attempt to solve the same problem, Blasko published an IBM Research
Report in 2005 [8] proposing a Wristwatch-Computer Based Password-Vault.
Blasko describes the design and implementation of a wearable computer with
wireless connectivity, processing, input, and display capabilities, that is meant to
store a users passwords for different services.
A year later, Gaw and Felten published a study of Password Management
Strategies for Online Accounts [15]. The authors studied how many passwords 49
undergraduates had, and how often they reused these passwords. At that time
about 38% of the people participating in the study used password managers. More
than two thirds of those used online, web based password managers. With the
inclusion of password managers in popular browsers, that number is presumably
significantly higher today.
In 2009 Englert and Shah published a paper on the Design and Implementation
of a secure Online Password Vault [12]. This works describes an architecture
where encryption and decryption is done locally on the user’s machine but storage
done online.
Bonneau and Preibusch reported results of, what they claim is, the first largescale empirical analysis of password implementations deployed on the Internet [9].
This study included 150 websites which offer free user accounts for a variety of
purposes, including the most popular destinations on the web and a random
sample of e-commerce, news, and communication websites. This work does not
deal directly with password managers but the findings support the claim that
many online services use poor practices when dealing with user credentials. This
serves to highlight the need for password managers and consequently, the need
for secure password manager database formats.
To the best of our knowledge, there is no related work that attempts to
analyze the state of password manager security, or provide design guidelines for
password manager database formats.
Password managers are critical pieces of software used to securely store sensitive
information. This paper presents the first rigorous analysis of the storage formats
used by popular password managers.
We defined two realistic security models, designed to represent the capabilities
of real-world attacks. One for passive and one for active attackers. We analyzed
popular password manager database formats in our security models; for each
vulnerable format, we provided a formal argument for why it is broken. We also
showed what the theoretical vulnerability means in terms of practical attacks.
Additionally, when a database format was found to be secure, we provided a
formal proof.
Unfortunately, most formats turned out to be broken even against very weak
adversaries. For this reason, users should carefully consider whether a particular
database format is acceptable for storing data in the cloud, on a USB drive or
on a machine shared with other users.
Finally, our works shows that it is indeed possible to construct a format that
provides security, usability and low computation and storage overhead, using
standard cryptographic tools.
1. 1Password. Automatic Syncing Using Dropbox. http://help.agilebits.com/
2. AgileBits, Inc. 1password. https://agilebits.com/onepassword.
3. AgileBits, Inc. 1password agile keychain design. http://help.agilebits.com/
4. B. Pellin. Keepassdroid. http://www.keepassdroid.com.
5. M. Bellare, R. Canetti, and H. Krawczyk. Keying Hash Functions for Message
Authentication. CRYPTO98, 1996.
6. M. Bellare and C. Namprempre. Authenticated Encryption: Relations among
Notions and Analysis of the Generic Composition Paradigm. J. Cryptology, 21(4),
7. D. Bernstein. The Salsa20 Family of Stream Ciphers. In New Stream Cipher
Designs - The eSTREAM Finalists. Springer-Verlag, 2008.
8. G. Blasko, C. Narayanaswami, and M. Raghunath. A Wristwatch-Computer Based
Password-Vault. Technical report, IBM Research Division, 2005.
9. J. Bonneau and S. Preibusch. The Password Thicket: Technical and Market Failures
in Human Authentication on the Web. Information Security, 8(1), 2010.
10. I. Damgaard and J. Nielsen. Expanding Pseudorandom Functions; or: From KnownPlaintext Security to Chosen-Plaintext Security. In CRYPTO 2002, 2002.
11. R. Dhamija, J Tygar, and M. Hearst. Why Phishing Works. In SIGCHI conference
on Human Factors in computing systems, New York, NY, USA, 2006. ACM.
12. B. Englert and P. Shah. On the Design and Implementation of a secure Online
Password Vault. In ICHIT 09. ACM Press, 2009.
13. F. Pilhofer. Password Gorilla. http://www.fpx.de/fp/Software/Gorilla/.
14. N. Ferguson. AES-CBC + Elephant diffuser A Disk Encryption Algorithm for
Windows Vista. Technical report, Microsoft Research, 2006.
15. S. Gaw and E. Felten. Password Management Strategies for Online Accounts. In
SOUPS ’06, Pittsburgh, PA, USA., 2006. ACM Press.
16. GNU zip. The GZIP homepage. http://www.gzip.org/.
17. Google. Get a fast, free web browser. https://www.google.com/chrome/.
18. Google. Protect your synced data. http://support.google.com/chrome/bin/
19. A. Herzberg. Why Johnny can’t Surf (Safely)? Attacks and Defenses for Web Users.
Computers & Security, 28(1-2), 2009.
20. J. Katz and Y. Lindell. Introduction to Modern Cryptography. Chapman &
Hall/CRC, 2008.
21. J. Katz and M. Yung. Unforgeable Encryption and Chosen Ciphertext Secure
Modes of Operation. In In FSE 00. Springer-Verlag, 2000.
22. KeePass – A Free and Open-source Password Manager. http://keepass.info/.
23. KeePassDroid. Dropbox and KeePassDroid. http://blog.keepassdroid.com/
24. H. Luo and P. Henry. A Common Password Method for Protection of Multiple
Accounts. In International Symposium on Personal, Indoor and Mobile Radio
Communication, 2003.
25. M. Frazier. Sync Firefox from the Command Line. http://www.linuxjournal.
26. M. Vanhove. Kypass. http://itunes.apple.com/us/app/kypass/id425680960?
27. Microsoft.
Internet Explorer 9.
28. Microsoft Dev Center. CryptProtectData function. http://msdn.microsoft.com/
29. Mozilla. Firefox. http://www.mozilla.org/.
30. Mozilla. Firefox Sync for Mobile. http://www.mozilla.org/en-US/mobile/sync/.
31. Password Safe – Simple & Secure Password Management. http://passwordsafe.
32. Password Safe V3 Database Format. http://passwordsafe.svn.sourceforge.
33. PINs, Secure Passwords Manager. http://www.mirekw.com/winfreeware/pins.
34. Portable Apps. Keepass password safe portable. http://portableapps.com/apps/
35. R. Muiznieks.
USB password manager: When your password
36. RomanLab Co. Ltd.
database is right where you need it.
37. Siber Systems, Inc. RoboForm. http://www.roboform.com/.
38. Siber Systems, Inc. Roboform2go for USB drives. http://www.roboform.com/
39. Trusteer. Reused Login Credentials. http://www.trusteer.com/sites/default/
Mac-Forge Security Notion
Let Π = (Setup, Mac, Vrfy) be a MAC. The standard definition of unforgeability
for message authentication code (MAC) functions is as follows [20].
Game 4 (Mac-ForgeA,Π (κ)) Existential unforgeability under an adaptive chosenmessage attack. A challenger Ch running Π interacts with A as follows:
– Ch runs mp ← Setup(1κ ).
– A is given oracle access to Macmp (·)
– Eventually A outputs a pair (m, t); the game outputs 1 – and A wins the
game – iff Macmp (m) = t and m was never queried before to Macmp (·).
Definition 5 (Mac-Forge security). A MAC Π is Mac-Forge-secure if there
exists a negligible function negl(·) such that for any efficient adversary A,
Pr[Mac-ForgeA,Π (κ) = 1] ≤ negl(κ).
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF