Need more info: Are KeepassXC's database files vulnerable to attacks when the attacker has access to multiple versions of the file?

[a20eac1d]

Summary

Please add more information about the encryption methods and parameters used to the website/the program and how this affects security in different contexts, such as uploading the password database to the cloud.

Context

The website gives us the information, that KeepassXC is using "Complete database encryption using industry standard 256-bit AES". I would like to know more, such as the mode being used (CBC?) and how the IV is being generated.

For example: Let's say I setup a KDBX-file with a secure password. When I upload it to the cloud with auto-synchronization setup in the cloud's client, does that make the password database vulnerable for attacks when the cloud provider has access to different versions of the file and is therefore able to track changes made to the database over time whenever it changes? This attack vector depends on the encryption method used and I would like to have more clear and specific information on this topic.

As far as I know using AES in CBC mode with random IVs that change everytime the file gets saved would prevent this from being an issue, but I was unable to find in-depth information / confirmation about this on the KeepassXC website.

Can anybody enlighten me?

[droidmonkey]

The default settings for a new database are AES-256-CBC, random IV in every save, Argon2d Key Derivation (Stretching) Function with a one second nominal derivation time.

The only risk to saving your database in a cloud storage provider is if you have a very weak password. If you save history then any history item could be attacked so of you upgrade your password then prune your history.

[a20eac1d]

@droidmonkey Thank you, this clears things up a bit! I assume that by "prune your history" you mean the different file versions that may be kept by the cloud provider. And the way I understand is that they don't gain any advantage by having multiple file versions because they would still have to attack one of them and they don't gain any more information by comparing the file differences?

I'm also wondering about Argon2d / Argon2id. Does storing the database file on a cloud service introduce the risk of side channel attacks that can be mitigated by choosing Argon2id? From what I've read in other places so far, "one should choose Argon2id, if you don't know what you are doing". Would it be a bad idea to choose Argon2id in this context?

[droidmonkey]

Yes clearing the file version history is what I meant. There is no advantage to having multiple versions of the files due to the random seed/IV and CBC encryption.

Argon2d timing attack is only relevant for client-server relationships. Since keepass databases are entirely local, there is no additional information gained from knowing the time the algorithm takes to complete. The default settings also preclude this from being a reality since 1 second is an eternity for these algorithms. The normal kdf delay for server based implementation is likely in the hundred millisecond range or less.

As of KeePassXC 2.6.6, you can also use Argon2id and it is the new default.

Note: The choice of Argon2d only was made by the original keepass author, we pushed to also include Argon2id and it was accepted for kdbx 4.1.

[succeedmr123]

thanks to @droidmonkey for the kind clarification.

I was in the process of bug searching before posting an issue here involving stacked encryption (for the whole concern of multiple versions / deriving from that situation, I am running keepass db within Cryptomator FS that is saving (over cached FuseFS mechanism) to cloud )

However, need to note that in this setup you could stumble into messages like "the database changed on disk, need to merge" from KeepassXC, and then KPXC freeze indefinitely, got to kill the process.

For more detailed report, I will open separate issue just for all of us be able to narrow down the point of failure here between the chained apps/technologies.

Cryptomator is desirable exactly for the multiple file versions attacks and general establishing of user privacy in the cloud - hence the Value of debugging and making it usable for users wanting privacy and security guaranteed.

New anchor issue is #7474
KeepassXC db within Cryptomator container FS freeze - after automatic merge request msg (accepted) #7474

Thanks,