Attack - KeeShare attachments can be inferred because of attachment de-duplication.
Solution - Prevent de-duplication of normal database entry attachments with those entry attachments synchronized/associated with a KeeShare database. This is done using the KeeShare database UUID injected into the hash calculation of the attachment prior to de-dupe. The attachments themselves are not modified in any way.
--------
Attack - Side channel byte-by-byte inference due to compression de-duplication of data between a KeeShare database and it's parent.
Solution - Generate a random array between 64 and 512 bytes, convert to hex, and store in the database custom data.
--------
Attack vector assumptions:
1. Compression is enabled
2. The attacker has access to a KeeShare database actively syncing with the victim's database
3. The victim's database is unlocked and syncing
4. The attacker can see the exact size of the victim's database after saving, and syncing, the KeeShare database
Thank you to Andrés Fábrega from Cornell University for theorizing and informing us of this attack vector.
Otherwise, assertions in TestKdbx4::testCustomData() may fail on rare
occasions, because the customData in a cloned entry won't be identical
to its original, because of its potentially-updated LastModified
property.
Originally noticed in
https://github.com/keepassxreboot/keepassxc/pull/7783#issuecomment-1101404487.
Shows a warning when trying to open with a newer minor version than what is currently supported.
We always try to save with the lowest KDBX version possible for maximum compatibility.
The challenge-response key buffer is explicitly cleared
before the key transformation if no such key is configured
to ensure one is never injected into the hash even if the
database had a challenge-response key previously.
This patch also adds extensive tests for verifying that a
key change will not add any expired key material to the hash.
Fixes#4146
The Database, DatabaseWidget, and DatabaseTabWidget classes share many responsibilities in inconsistent ways resulting in impenetrable and unmaintainable code and a diverse set of bugs and architecture restrictions. This patch reworks the architecture, responsibilities of, and dependencies between these classes.
The core changes are:
* Move loading and saving logic from widgets into the Database class
* Get rid of the DatabaseManagerStruct and move all the information contained in it into the Database
* Let database objects keep track of modifications and dirty/clean state instead of handing this to external widgets
* Move GUI interactions for loading and saving from the DatabaseTabWidget into the DatabaseWidget (resolves#2494 as a side-effect)
* Heavily clean up DatabaseTabWidget and degrade it to a slightly glorified QTabWidget
* Use QSharedPointers for all Database objects
* Remove the modifiedImmediate signal and replace it with a markAsModified() method
* Implement proper tabName() method instead of reading back titles from GUI widgets (resolves#1389 and its duplicates #2146#855)
* Fix unwanted AES-KDF downgrade if database uses Argon2 and has CustomData
* Improve code
This patch is also the first major step towards solving issues #476 and #2322.
This patch implements a new database wizard to guide users through the process
of setting up a new database and choosing sane encryption settings.
It also reimplements the master key settings to be more
user-friendly. Users can now add, change, or remove individual composite
key components instead of having to set all components at once. This
avoids confusion about a password being reset if the user only wants to
add a key file.
With these changes comes a major refactor of how database composite keys and key
components are handled. Copying of keys is prohibited and each key
exists only once in memory and is referenced via shared pointers. GUI
components for changing individual keys are encapsulated into separate
classes to be more reusable. The password edit and generator widgets
have also been refactored to be more reusable.
* Tests: Speed up AutoType testing
Decrease default autotype delay to 1 to improve test suite speed by
seconds. This shaves multiple seconds off the whole test suite. In some
cases, the largest part.
Also, initialize config just creating the test instance, just in case
that it ever depends on the configuration values at that point already.
* Tests: Speed up Kdbx4 testing
This speeds up the Kdbx4 tests by using parameters optimized for speed
for the key derivation functions. On an i7-6700K the tests run close to
50% faster with this change (about 1.5s vs. 3s).
