Keepassxc: Key file & database permissions are world-readable by default

[tedjp]

Expected Behavior

I expect the key file and the key database to be created mode 0600 (-rw-------) but instead they get default permissions, generally 0644 (-rw-r--r--).

This is not the most secure default because other users on the system can access the key file and password database. A misconfigured system, such as one with a web server, could inadvertently allow access to the key file & database remotely. Defaulting to mode 0600 would help prevent exposure.

Users can change the file mode if desired (see #1871).

Steps to Reproduce

On Linux,

1. Create a new password database.
2. Create a new key file.
3. Inspect file permissions (eg. ls -l *.key *.kdbx)

Debug Info

KeePassXC - Version 2.3.4
Revision: 6fe821c

Libraries:

• Qt 5.11.2
• libgcrypt 1.8.4

Operating system: Debian GNU/Linux 9 (stretch)
CPU architecture: x86_64
Kernel: linux 4.18.0-3-amd64

Enabled extensions:

• Auto-Type
• Browser Integration
• Legacy Browser Integration (KeePassHTTP)
• SSH Agent
• YubiKey

[droidmonkey]

This is not the most secure default because other users on the system can access the key file and key database.

That depends on where you store the file. If the folder does not provide group/other permission to execute and read then it doesn't matter what the file permissions are. (ie, if /home/user is chmod 700 than my database stored there can be 777 and still no one else can access it except for root).

File permissions are far less important than folder permissions or correctly configured web servers (egad!). Also, what a great way to find your key file and database by searching for chmod 600 files: find -perm 600

I am not in favor of mucking with file permissions as it, more often than not, causes issues rather than prevents disclosure.

[tedjp]

If you install a new Ubuntu system and KeePassXC and make a new database and a new key file in your home directory, they're going to be readable by anyone. I'd prefer these sensitive files to be secure by default.

I don't know whether you're suggesting find . -perm 600 is a good thing or a bad thing. Seems like a mild convenience,[1] and other users can't do anything with it if it's 0600, but if it's 0644 they can start cracking the master passphrase because the key file is compromised.

Please enumerate some cases where mode 0600 is problematic. I can't think of any.

For comparison with other tools, OpenSSH will refuse to use a private key that is world-readable.

As for directory permissions, they don't protect the file if it's hardlinked elsewhere. (Yes, this is a corner case, but exploits love corner cases.)

[1] Or just find . -name '*.kdbx' -o -name '*.key' regardless of permissions.

[droidmonkey]

OpenSSH also does not generate keys with 0600 permissions....

0600 permissions can cause issues with [intentional] network shares.

I have noticed that Ubuntu user home directories are 755 which is ridiculous.

[tedjp]

OpenSSH absolutely uses 0600 for private keys:

$ ssh-keygen -f new_key
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in new_key.
Your public key has been saved in new_key.pub.
The key fingerprint is:
SHA256:TYYqX7prI5ZQyFedIDuRGyx+njr5t1GJp/Qms1Gl9+s ted@computer
The key's randomart image is:
+---[RSA 2048]----+
|   .o..o .       |
|  . ++. o.       |
| o oo+  . +      |
|  + =. o B       |
|   =..+ S o      |
|  . o+ O . .     |
|   + .O o   .    |
|  + + +O     .   |
|   +.+=+   .E    |
+----[SHA256]-----+
$ ls -l new_key*
-rw------- 1 ted ted 1679 Jan  3 17:07 new_key
-rw-r--r-- 1 ted ted  391 Jan  3 17:07 new_key.pub

[droidmonkey]

Interesting! I had to chmod mine in the past. Thanks for correcting me there. I do agree with 0600 a generated key file, but not the database file due to network sharing.

[LogicDaemon]

shouldn't user manage sharing permissions if he wants sharing?

I also agree about defaulting to 600 and don't see why sharing is more important than security. Is password sharing a primary KeePassXC function? It should at least allow setting multiple key/passwords then, so keyfiles/passwords won't need to be shared along with database and could be changed independently… Currently I only see "network sharing" as side-effect of overall design instead of intended feature.

[blittlewood]

Exporting a database to a file (something that I do periodically to an encrypted USB) also results in the generated file having permissions 0644 (-rw-r--r--). Yes, my intended target device is encrypted and my target directories have restricted permissions, but what if a file ends up getting inadvertently saved somewhere that I don't expect it to be, and I don't notice it. This is particularly a concern to me because I now (with the latest release) have to move very quickly to complete the save dialog before it times out.
Is it ok if I create a new, separate issue to request 0600 permissions for exported files?
thanks,
Bill

[droidmonkey]

No need for another issue

[Bill-cpp]

As I see it, the permissions for keyfiles should be more restricted than the permissions for databases. For keyfiles, write permissions are not only unnecessary, but can be dangerous. Unnecessary because there's no legitimate reason to write to a keyfile. Dangerous because if you or someone else writes to (or deletes) the keyfile and there's no backup, your database becomes inaccessible. So in my view, keyfiles should be created with permission 0400 (-r--------).

As things stand now, if you use KeePassXC to try to generate a new keyfile on top of an existing one, thereby possibly making any associated databases inaccessible, KeePassXC warns you that the keyfile already exists and asks whether you want to replace it. If you (foolishly) say “yes”, the keyfile is written over. For a R/O keyfile, KeePassXC then responds “Unable to create key file: Permission denied”, which is much safer. Bash commands and most other apps are also respectful of R/O files.

Although I agree that databases should be created with mode 0600, I don't see 0644 as a major security issue. After all, the whole point of a password manager is that the database's secrets are protected by encryption, right? Unfortunately, with KeePassXC 2.5.1, both keyfiles and databases are created with permissions 0664 (-rw-rw-r--) – not 0644. This means that in the worst-case – a database protected by a keyfile but no master password – any group member can read everything in the database, and unless both the database and the keyfile are backed up, can delete both files, thus causing the original user to lose all access.

As _blittlewood_ has hinted, it is risky to depend on the directory restrictions to override file accessibility. KeePassXC does not set directory permissions. Directory permissions can be changed; also, keyfiles and databases can be moved or copied to other directories without these restrictions. As I see it, KeePassXC should set permissions so as to protect the naive user from revealing secrets to others, or from losing access.