Password managers like KeePass often have an option to use a key file in addition to a master password.

I don't understand how this increases security.

(Note: KeePass also allows using a key file instead of a master password, but in this question I'm asking specifically about using one in addition to a master password.)

Since the password database cannot be decrypted without the key file, the key file needs to be stored somewhere - much like the password database itself. Why is the key file harder for an adversary to get at than the password database itself?

5 Answers 5


Authentication methods can often be divided into one of three areas: something the user knows, something the user has and something the user is.

Passwords are something the user knows. The user memorizes it in his head and can "retrieve" it from memory as and when it is needed.

The key file acts as something the user has. Ideally, this key file needs to be stored in a secure location.

Personally, I have copies of my password database everywhere. My desktop has a copy, my laptop has a copy, my phone has a copy, my tablet has a copy. I store my password database on Dropbox which allows me to keep it in sync between my various devices.

However, I do not store my key file together with my password database. My phone and tablet has a copy of it, because there is no way I can insert a USB drive into those devices, but my desktop and laptop does not. I store my key file on a USB drive which I keep on my person at all times. This makes it slightly more difficult for an attacker to obtain my key file.

Using a key file in addition to a master password is helpful, as it raises the difficulty of successfully compromising your password database.

  • 3
    @HighCommander4 What? I only store the key file on my phone or database because I do not have any means to conveniently use a USB drive with those devices. The point is, I do not distribute the key file the same way I distribute my password database.
    – user10211
    Oct 19, 2013 at 6:41
  • 1
    But you need the key file every time you want to use the password database. So, wouldn't it be equally convenient to only store the password database wherever you store the key file? Oct 19, 2013 at 6:48
  • 4
    @LucasKauffman: Right, so let's say you only store the keyfile on your USB stick and nowhere else. Let's say you store the password database both on your USB stick and on your computer. Since the database is useless without the keyfile, you need to plug in your USB stick every time you want to use the database. Since you already have your USB stick plugged in, why not just use the database from the USB stick too - why store the database on the computer as well? Oct 19, 2013 at 8:00
  • 2
    It's a bit like storing your keys on a keychain. But you won't store your key next to your locked door, right? Well this is similar. Oct 19, 2013 at 8:13
  • 2
    @LucasKauffman: I understand now: you store the key file and the database in mutually exclusive sets of locations. That does give you extra security. It's a bit worrying backup-wise because to protect losing your passwords, you need to back up both the key file and the password database, into distinct backup locations - but nevertheless it's a good option to have. Oct 19, 2013 at 8:19

They key file contains the key used to encrypt the database. It's often also protected by a password. If you do not have the key file it's impossible to derive the key from the ciphertext obtain the plaintext equivalent. So should an attacker obtain your database, he would still need to get your keyfile, something you have. If the keyfile is additionally encrypted with a password (as you should) then he also needs something you know. So this is two factors of authentication.

If you store the keyfile along the database, an attacker would "just" need to bruteforce or dictionary attack the keyfile (which is a lot smaller and takes a lot less time than attack the whole database). However if you have a complex password, this should still take almost forever (depending on your password randomness/entropy).

But adding another factor does add extra security as an attacker will still have to get two things from you, rather than one.

It's a bit like storing your keys on a keychain. But you won't store your key next to your locked door, right? Well this is similar.

  • "But you won't store your key next to your locked door" If you have your password database on lots of computers and your key file on a usb key in your pocket, it's more like having vaults around the country and a key in your pocket. But wouldn't it be much more secure to have the vault in your pocket (only keep your database on a usb key)? I guess you could leave the key at locations around the country to limit where the vault can be opened, but as a physical analogy that feels less secure.
    – idbrii
    Apr 24, 2020 at 17:36

In addition to acting as "something you have", the option to use a keyfile allows for more flexibility in the other two factors ("something you know" and "something you are") without having to explicitly implement such behaviour in the application.

Example 1: "Something you know" could be run through a custom or stronger key derivation function than KeePass (especially v1.x compatible) can support; then loaded in as a keyfile.

Example 2: "Something you are" could be run through a biometric scanner that writes out a bio-signature which is then run through a trapdoor function and/or key derivation function to be loaded into KeePass which has no native awareness of biometrics, especially on operating systems with no "TWAIN" equivalent biometric standard.

Example 3: "Something you are" in the more generic sense of prove you are a human* by regenerating the keyfile (or one stage thereof) from a human typing in a CAPTCHA image (or one or another possible successors) stored publicly along with the keystore.

Basically, the keyfile option can act as a generic catch-all for any entropy source you can imagine - within the limit of the underlying keystore encryption scheme (256 bit for KeePass).

* Or HAL 9000.


There is a second advantage of a key file, separate from simulating two-factor authentication (2FA). Although your revision of your question suggests that the two factor answer is what you are looking for in your answer.

Another reason to not have the encryption key be derived directly from the Master Password is to allow the key to be created at random instead of being directly derived from the master password. If we create the key with a CSPRNG and then encrypt that key with a Key Encryption Key (KEK), then we can ensure that the master key has the full strength of its bit size. That is a 128 bit key will really be 128 bits strong, even if an individual picks a poor master password.

Although this isn't required for symmetrical keys (as used in password managers), it is absolutely vital when looking at public key systems. In those cases the private key can't just be anything, and so can't really be a function of a password and some salt. So this is why for things like PGP or SSH the keys are generated by the software and are then encrypted with a KEK derived from the password.

Of course the derivation of the KEK from the master password still needs to be "stretched" with a key derivation function such as PBKDF2 or scrypt.

Two factors, but not authentication

Note: The reason I said "simulate two factor authentication" is because there is actually no authentication in these cases. Instead there is decryption. For many purposes, the distinction doesn't matter, but there are crucial cases where distinguishing between an authentication password (or token) from an encryption token is enormous.

In the case of something like KeePass, which are not authentication based (You are not proving who you are to some service which then releases stuff to you upon success), you need to get your key file to every computer or device you need to use your data on. So putting it on a USB-thing may not work if you also wish to decrypt your data on a phone. There may very well be ways to do this with KeePass, but given my (possibly flawed) understanding of the architecture it would present some difficulties that would need to be overcome.

  • "That is a 128 bit key will really be 128 bits strong, even if an individual picks a poor master password." This reason makes the most sense to me. And I assume it's completely defeated if you keep the key with the database, so you need to keep the key with the password (on the user).
    – idbrii
    Apr 24, 2020 at 17:39

The answers here are very good but I think something should be noted here more explicitly:

The key file in KeePass Database is not like other two factor methods used in online accounts. the Key file here (and also OTPKeyProv plugin if someone use it instead of) are like your password.

I mean if someone wants to brute force your KeePass database they don't need to have your key file or your OTP code because KeePass used these items like your password for encrypting database. so there is not much something you have like online accounts here in terms of security.

The only advantage of these methodes is that your database will have a better KEK in terms of quality/security that used to encrypting it and if your password be low quality it won't affect the security of database very much in comparison of using password itself.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .