KDBX Standard Discussion

[droidmonkey]

Placeholder for KeePass Database (KDBX) standard discussion. This post will be edited to include a list of features and upgrades we would like to bring to Dominik for consideration in the next KDBX format update.
Must Haves:

• Standardize on Argon2id instead of Argon2d
• Password Modification Datetime
• Database/Entry Custom Data modification time
• Built-in Entry Layout Specification (Add support for customizable entry layouts #863 (comment))
• Built-in TOTP Specification (otp attribute)
• Built-in Hardware Key Specification
• Built-in Quick Unlock Specification
• Built-in favorites/pinned items
• Only support straight binary key files or key/keyx files
• Multi-valued core and custom fields
• Proper storage format for and deduplication of BLOBs (SQLite can handle this)
• Transactional edits/global history on database level, not entry level (e.g., to undo deletes or moves and to ensure overall consistency)

Nice To Haves:

• Custom icon naming
• Graph instead of tree structure (one item can belong to multiple groups, makes tagging somewhat redundant)

[droidmonkey]

Looping in @keepassium @mmcguill @PhilippC
Original issue that spawned this conversation: #4293 (comment)

[droidmonkey]

Correct, I am trying to avoid implementing a multitude of "minor" interim solutions. That creates significant code bloat with exceptions and workarounds depending on which version of the standard you are on. The myriad of plugins made for KeePass over the years demonstrates why this is not a good thing. They all made their own unique standards.

[user858753257]

Example from Enpass for tags :

Here they are user defined and the developers from Enpass using a pre defined “Apple Watch” Tag to display all entries on the watch which get tagged with this .

In my eyes “pinning” should be in the standard and tags only for special things a developer decide

[ghost]

Related #398 #3558

KeePassDX, the alternative KeePass client for Android, recently added multiple URL formats that are incompatible with Keepass2Android. The app uses WebDomain and WebDomain[counter] instead of KP2A_URL and KP2A_URL_<counter>.
Kunzisoft/KeePassDX#524 (comment)

Given the popularity of Keepass2Android, it's reasonable for KeePassXC to support its vendor prefix at this time, but I'd like to see this feature standardized with a common prefix in the future.

[rjt]

Instead of adding every possibility to the standard, maybe the end user could supply a list of keys that indicate URLs. Or KeePassXC could search for http in all advanced entries by default? I use URLx where X is from 1 to infinity because keepass was doing that. Now, KeePassXC does not recognize these advanced entries as URLs for the browser extension.

[strongbox-mark]

I'd like to start recommending to my users that they upgrade their databases from KDBX3.1 and KDB to KDBX4.

Does anyone see any issue with that?

[phoerious]

Not at all. KDBX4 should be the default for everyone.

[J-Jamet]

For the moment, I generate a basic KDB3.1 file and migrate to the KDBX 4 format only if there are the migration conditions in the database content. https://keepass.info/help/kb/kdbx_4.html
Since not everyone has given their opinion and I haven't studied all the alternatives, I'm sticking with the current rules for now.
I will give the choice once I have redone the creation workflow.

[strongbox-mark]

In line with KeePassXC's usage, Strongbox will also start using the property "KnownBad" to mark items that are to be excluded from Audit/Health Reports. Currently Strongbox stores this data outside of the database.

Unless there are objections, I think it's best just to use the existing KeePassXC convention:

Entry Custom Data ["KnownBad"] = true (standard boolean)

Usually these are items like 4 digit PIN codes (which are detected as weak) which users have no choice but to use... etc

[strongbox-mark]

Fair enough, I'll try explain this to my users.

[droidmonkey]

I think you can have the feature to apply to a group, and just apply the custom data to each entry in the group. Don't apply any setting to the group itself, just it's entries.

[strongbox-mark]

Another question here for the KeePassXC crew, do you plan on supporting this "native" Password Quality flag, or will you continue with the "KnownBad" custom attribute?

I ask because it would be great if Strongbox only had to support one (probably favouring the native non custom attribute).

[droidmonkey]

Yah we'll support that with kdbx 4.1 and do a migration from the current custom data setting to the built in standard upon database upgrade.

[strongbox-mark]

That's great, I'll work with the native version 4.1 then. Ta!

[phoerious]

One more thing I would like to propose here is deprecating entries in the root group. I know that some users store information there, but it leads to a (visually) unnecessarily complex group tree. If we could instead just skip the root group, we could render the first-level folders as a simple flat list. If someone still wants to put all their passwords into one big "catch-all" group, they can easily create a second-level "root" group and it will look the same.

[Fraetor]

I personally think that having multiple databases open on the sidebar looks the most natural, as I've never really liked the tabbed approach, though I think removing the ability to collapse the root group makes sense if only one database is open.

[Fraetor]

What I will say, is that it may make better UX sense to keep the root group visible as then is is the exact same dialogue for the root group as for subgroups.

[phoerious]

Yes, this is only about Entries in the root group, not the root group itself. Any setting applied to the root group can (and IMHO should) be moved to the database settings. Depending on the modularity of your code and GUI widgets, this involves very little or no duplication. Also, there is nothing stopping you from showing it if you want do want to edit these settings on the group instead of the more logical database settings. It means that the user cannot add entries directly to this root group.

[J-Jamet]

This isn't implementation, it is the way the standard is written. The Root Group currently allows entries to be added to that group. This precludes the ability to hide it in database settings.

Maybe I misread it. But what do you mean by hiding the root group in database settings?
If there is an option to hide the root group, how will we be able to see the other groups that contain it if it is a user interface that only allows to see one group at a time. The parameter should be ignored in this case.

I see it as a Linux folder architecture, a folder can contain files. Here the root group can contain entries.
The settings of the database influence obviously the root group, after that it's just a matter of UI.
In the visual interface of KeePassDX, the KDB implementation without entry in the root group is annoying because it makes additional filter rules compared to the KDBX4 format (because it is not a group like any other).

The alternative in my mind is to get rid of the tabbed database interface and treat the root group as the database itself. Then you can stack multiple root groups under each other which really are multiple databases.

Indeed I think this is a good approach.

[Fraetor]

Maybe I misread it. But what do you mean by hiding the root group in database settings?

The way I interpreted that is that while the root group exists in the database file as it does now (possibly sans entry capability), the UI does not show it, and instead moves the group settings for the root group to a database setting UI.

My personal preference is to leave it as is, and then implement some UI tweaks in the implementation as illustrated above. If a program wants to hide the root group from view then it can, but other implementations can show it.

[DReichl]

Graph instead of tree structure (one item can belong to multiple groups, makes tagging somewhat redundant)

Currently, entries can be organized using the group tree and tags. The group tree allows to organize entries hierarchically, whereas tags allow to mark certain entries independent of a hierarchy. Both the group tree and tags have unique advantages and disadvantages; they complement each other. Combining a tree with tags is a common approach (e.g. most e-mail programs store e-mails in folders and allow to assign tags, Firefox organizes bookmarks in folders and allows to assign tags, ...).

Allowing an entry to have multiple parent groups would induce problems. When an entry/group has at most one parent group, properties can be inherited (e.g. an entry/group inherits the 'Searching entries in this group' setting and the default auto-type sequence of its parent group). If an entry/group could have multiple parent groups, it would be unclear from which parent group a certain property is inherited. One could allow users to specify a primary parent group for each entry, but this would be hard to manage for users (and the primary parent groups would form a tree again). Furthermore, the behavior of various operations would become non-obvious (for example, would moving an entry into the recycle bin also remove it from all other groups?).

A different extension would be a tag graph/hierarchy, i.e. allowing tags to include other tags. Unfortunately, this could encourage some users to use tags only, by which they'd lose the benefits of inheritable properties (and get other problems). Furthermore, I think that the diameter of the tag graph would be very low for most users and the overtags would not really be useful for an entry search. KeePass already supports searching for multiple tags (e.g. 'A or B') at once; in fact, the search function allows complex queries (e.g. finding entries having the tags 'A or (B and C)'), and such queries can be saved as search profiles (to quickly perform the same search again at a later time).

The group tree and tags (and the search function) should be sufficient for most users to organize their entries. As mentioned, the two extension ideas above aren't unproblematic; I currently prefer to not implement them.

[droidmonkey]

Concur this should be dropped

[DReichl]

Built-in Quick Unlock Specification

I think that a quick unlock feature should be configurable using application settings, not database settings.

• From a user's point of view, opening a database and quickly unlocking it are similar operations, but from a technical point of view, they are very different. Opening a database requires the computation of a cryptographic key (for decrypting the data), whereas a quick unlock typically only requires an authentication. The latter is often easier than the former (for example, transforming a fingerprint scan into a cryptographic key is more difficult than comparing it with a reference fingerprint scan). For an authentication, there are many possible methods (possibly with parameters) and some depend on the environment (operating system component, driver, library, ...). With application settings, this is no problem, because the application knows the authentication method (and parameters) and the environment.
• A user may use one database on multiple devices and use a different quick unlock method on each device. For example, assume that a user has a smartphone with a camera (but no fingerprint reader) and a laptop with a fingerprint reader (but no camera), then the user may want to perform a quick unlock on the smartphone by facial recognition and on the laptop by fingerprint scan. If the quick unlock settings are (local) application settings, this is possible directly. Making them database settings would be complicated, because they'd need to be associated with device/application combinations (the support for a specific authentication method depends on both the capabilities of the device and the support of the application).
• If the user wants to enter a short password for quickly unlocking a database, this short password can be a part of the master password (e.g. the first few characters, requiring the whole master password after a few failed quick unlock attempts). The point of a password manager is that the user needs to remember only one master password; I don't see any good reason for additionally remembering a completely different quick unlock password. Furthermore, this again is device-dependent; the user may want to enter a shorter quick unlock password on a smartphone than on a laptop/PC.
• Some applications allow to open multiple databases within one process. It would be convenient if a quick unlock would unlock all databases that were open before the quick lock (the application may have an option for enabling/disabling this behavior). If the quick unlock settings would be database settings, we'd get ambiguities/contradictions in this situation; with application settings, there are fewer ambiguities/contradictions.

[droidmonkey]

Biometric unlock is precisely quick unlock. Your real database key (post transformation) is stored in the credential store of Android or windows and the biometrics authenticate you to that store. That is quick unlock as described here. Your database is not actually unlocked with the biometrics, that just gains access to the actual encryption key.

[J-Jamet]

Actually here, Quick Unlock is a term used to define an unlocking method from a functional point of view while the implementation is different for each program, which is rather confusing. There are two main categories if we talk about technical implementation:

• The method that has an additional authentication to access the already opened decrypted database in memory. It can be a part of the password but it is arbitrary. If the authentication fails once the memory is cleared.
• The method that uses an encrypted key store on the device. In this case, the database key is stored in this encrypted key store and it is up to the system to deliver the key when requested by KeePass program.

Both methods have their advantages and disadvantages, I have already made my choice (method 2 which I renamed Advanced Unlock to avoid confusion in KeePassDX ecosystem) after having studied the different ways of accessing the data and I felt that the user comfort/security ratio was better on Android devices. But this may not be the case on all devices because it depends on many criteria (OS modification, credential store security, easy access to RAM, etc...) so can't really be subject to stantardization.

In the case of KeePassXC, I'm not going to give a precise opinion because I don't know all the OS on which the program is deployed but I think that you have to make a choice according to the different possible attacks on a system keeping in mind a comfortable use and not to make a method because there are habits on another type of device.

[droidmonkey]

Your first bullet is not entirely correct. The database would be encrypted in memory, not "opened". The post-transformed key would also be stored encrypted in memory, using the quick unlock as the key to that encryption. Quick unlock then decrypts the in memory key which then decrypts the database in memory. This saves the time of key transformation and less typing for the end user.

[J-Jamet]

Sorry, I may have misunderstood, the first method is the one I deduced when I looked at the code of KeePass2Android. @PhilippC don't hesitate to contradict me if I'm wrong.

If the database is encrypted in RAM, does that mean that you want to re-encrypt all the contents of the database temporarily during the Quick Unlock with a faster key to decipher? I had thought about this but it requires rebuilding the whole database structure and it takes memory for small devices. As the decryption time is often defined at 1 second, I didn't see the added value of this technique when it is enough to decrypt the file directly.

I don't understand what you technically mean by :

using quick unlock as the key to this encryption.

The Quick unlock key is somewhere, if it's in a credential store, then it's the method 2 I described but instead of decrypting the file, you have to decrypt the content of the database temporarily encrypted in RAM.

Edit: When I say that the database is "open" in memory, it means that its content is not encrypted. Maybe I should have used the term "decrypted". From a user's point of view, the database requires authentication so it can be seen as closed or locked. It is also this confusion that I wanted to avoid.

[JohnLGalt]

Your first bullet is not entirely correct. The database would be encrypted in memory, not "opened". The post-transformed key would also be stored encrypted in memory, using the quick unlock as the key to that encryption. Quick unlock then decrypts the in memory key which then decrypts the database in memory. This saves the time of key transformation and less typing for the end user.

TY for the explanation. I was mistaken in my understanding of how (the proposed) quick-unlock actually works.

[sirtao]

Hi all.
I've become a KeepassXC(and DX on mobile) user only recently, and I was exploring the various options for in-built TOTP management.
This seems the best place to talk about it, correct me if I'm wrong.

If I understand correctly, XC currently supports various TOTP systems:

• the "vanilla" KeePass system, which combines values in different extra fields
• XC own system, which uses a different values per extra field names
• different systems from various historical plugins

If this is correct, as first thing I suggest to actually EXPLAIN it to the users:
I had to waste some time to actually understand what was going on.
A simple "XC has its own TOPT system but it's also compatible with [LIST of app\programs\pugins]" would be useful.

As end-user, I think the best solution would be use the KDBX system, as, I suppose it's going to be the most common\de facto standard, with whatever wrap-around to manage other stuff and systems.
Other systems might be more efficient, but I do believe maximize the compatibility is more important.

My own experience is quite simple but an effective example:
I had to use a PC running vanilla Keepass because of work.
Of course it resulted in my OTPs in the database, all of the made with the XC system, being useless.
Luckily I had my phone with me.
It's, obviously, a quite fringe example.

Still, I do believe it's better to be as much as retro\wide-compatible as possible: you never know when you only have access to a Keepass version that doesn't support a non-standard system.
Even if it costs some efficiency.

So, yeah. Sorry for the wall of text.

[phoerious]

otpauth URLs are a standard and we are preferring that. All other formats are there for historical reasons.

[droidmonkey]

KeePass only recently supported TOTP natively. Unfortunately the decision was to go with a multi field approach that no one else implemented. This is actually discussed above in one of the subthreads.

[DReichl]

Password Modification Datetime

I'm not planning to add a separate field for this.

Adding/editing an entry doesn't always coincide with changing a password. For example, consider a user who creates or imports an entry for an account that already exists for a while; the last password change happened before the creation/import of the entry. Another example is a failed attempt to change a password; if the password change time would be updated automatically, it could become incorrect in this scenario. So, a way for manually editing the password change time would be required. In order to have correct times, the user would need to carefully maintain them (when entering/editing a password). Users who don't want to put that much time into maintaining these times would have potentially incorrect times in their database, making them unreliable. One could make saving the time optional (per entry), but there are also problems with this (option turned off for entries where you could need the times, users forgetting to maintain the time when the option is turned on, etc.).

In general, most users probably wouldn't want to maintain this manually; they'd like the time to be updated automatically when changing the password of the entry. In this case, the saved password change time is equivalent to the last modification time of the entry or one of its history entries, i.e. it's usually redundant. KeePass supports a column 'Last Password Modification Time (Based on History)' in the main window (activatable in 'View' → 'Configure Columns'), which determines the last password change time based on the last modification times. Of course, when history entries are deleted, the determined password change time may be incorrect, but the default history limits should usually be sufficient.

[droidmonkey]

I don't think we should be excluding a feature because some edge cases are thought up. Handle the edge cases or accept that sometimes it won't work "as advertised" but the vast majority of the time it works great. All your examples are easily handled though, imo. We know when a user edits their password based on text changed notifications on the password text edit. Also modified time actually often does not correlate with a password change which is why this feature was requested in the first place.

[Ilutio]

[phoerious]

This is not the correct place to discuss this issue. Please open a separate feature request for this, although I highly doubt that we will implement separate options for locking and turning off the screen. The database will lock when you lock your session. It won't lock when you simply turn off the screen, which is expected behaviour IMHO.

[Ilutio]

Thank you. I'll paste it as new discussion so it will seen as I hope.

[jakeparis]

Feature Request to consider: Instead of turning on "Auto-Submit" globally and allowing entries to opt-out with "Skip Auto-Submit for this entry", allow auto-submit only on specific entries that "opt-in".

If I've misunderstood the purpose of this thread, sorry!

[SvenMarquardt5772]

Is there any documentation, that documents the outcome of the standardization? A document that describes the format?

[droidmonkey]

https://github.com/keepassxreboot/keepassxc-specs

[ghost]

Hi all.

I would like to know why kdbx format is in xml and not json-scheme. Have you all ever thought about having a kdbx format in json-schema? like as kdbx-samplejson-scheme.json?

Why?

1. As we can see in this file there is the kdbx format in json-schema.
2. The main advantage is that SQLite accepts json file format by default, which makes it easy to import passwords from kdbx to a sqlite database, as well as, mongodb accepts json by default, which on the other hand also makes it easier importing passwords from kdbx, and postgres - which is another database, also accepts json format.
3. In other words, any nosql or document-oriented database accepts json format like mongodb, and databases like sql also accept json like sqlite, postgres. What I mean by this argument is that kdbx must be in json for easy adoption in various databases like mongodb, postgres, sqlite, sql-server, raven-db, couchdb, lowdb, node-json-db, tinydb among others.

What do you think about this idea?

[ghost]

Hi phoerious.

No and there is no advantage in switching from XML to JSON.

So... why? With binary json file format like bson-spec or ubjson you can take kdbx database anywhere, any database like sqlite, postgres, raven-db, couchdb, pouchdb, sql-server etc

[ghost]

Hi 0xpr03.

Also which json do you mean?

Bson-spec or ubjson.

I'm sure KPXC would end up being the only one actually switching to json, and every author of every keepass implementation will ask you to pay them for changing their whole internal data store code.

You can have an input format like xml, and on the other hand have a binary json output format with bson-spec or ubjson format.

I hope you don't really want to store passwords in mongodb as json plaintext blob.

So... this solves that problem: *"an encryption schema is a JSON object which uses a strict subset of JSON Schema Draft 4 standard syntax along with the keywords encrypt and encryptMetadata to define the encryption rules that specify how your CSFLE-enabled client should encrypt your documents."

[droidmonkey]

Can you please stop spamming this thread. Your proposal has been submitted, it is extremely unlikely to be implemented, if you have other tips on how to improve kdbx we'd be happy to hear them, but not json.

[ghost]

Hi droidmonkey, thank you for feedback and sorry for any inconvenience.

[phoerious]

We don't use MongoDB or any other external DBMS, nor do we ever plan to. There is no point in discussing this.

[strongbox-mark]

Passkeys

Hi all, I thought it might be a good idea to mention/discuss and possibly standardize "Passkeys" within the KeePass world. I was just speaking with Wolfram separately about this and thought this might be the right place to bring it up with the developers of KeePassXC and other clients.

We'd love to find a way to support passkeys in Strongbox and it seems there's already sort of a de facto implementation in KeePassXC already (see #8825).

This stores (correct me if I'm wrong @varjolintu ) the key pair as a PEM file attachment called "webauthn.pem" with the webauthn generated username in the password field. Without having done any implementation on the Strongbox side yet, this seems fine to me so far... e.g. We could display a list of Passkeys by scanning entries for this attachment name.

The purpose of this comment is just so that we're all aware of this de facto implementation and can try to standardize/agree on this convention early rather than individually coming up with our own solutions. Hope that makes sense, passkeys seem like a pretty exciting new development. 😀

[varjolintu]

@strongbox-mark You're correct. Generated username is stored in the password field, and the username/email selected for the site is stored as the username. The filename of PEM attachment always remains the same. This was the simplest solution I could quickly think of for storing credentials as simple as possible without using any Custom Data etc. Scanning the entries with the attachment name is how the work-in-progress PR also does it.

One other feature that's still missing is a possibility to export WebAuthn credentials easily (with the username and generated ID) so those could be imported to another password manager without copying the values around. Not sure how that should be handled because so far there's no standard way to do that.

[strongbox-mark]

Sounds good to me.

Am I right in saying that the key pair are stored in the PEM file rather than just the private key?

[varjolintu]

It's just the private key.

[droidmonkey]

To me, it is yet to be seen if the major browsers will allow swapping in a third-party passkey provider besides the operating system. I have come around to supporting them, especially considering it's just a leg up on web authentication, but the utility might be small right now.

[strongbox-mark]

It's just the private key.

I guess after registration we will never need to know the public key again, right?

To me, it is yet to be seen if the major browsers will allow swapping in a third-party passkey provider besides the operating system. I have come around to supporting them, especially considering it's just a leg up on web authentication, but the utility might be small right now.

I hear you, I'm more optimistic because the big players 1Password/Bitwarden etc will be pushing for an API for this, and Apple has already enabled an API on iOS/macOS for regular password filling, so fingers crossed!

[strongbox-mark]

Disabling AutoFill Suggestion for an Entry

Hi all, I just wanted to give a heads up about an extension to KeePass format that I'm implementing in Strongbox after some fairly regular requests from users.

It is a simple way for a user to specify that they don't want a particular entry "Suggested" to them in AutoFill, for example in the Dropdown suggestions menu in the browser.

To do this I'm using a CustomData key/value pair like this:

"KPEX_DoNotSuggestForAutoFill" = "True"

Where the value is the standard KeePass boolean string "True". Here is what the KeePass XML entry looks like:

<Entry>
	<UUID>3m+H+PlcSASzTVYaDNFyVA==</UUID>
	<String>
		<Key>Title</Key>
		<Value>My Entry</Value>
	</String>
	<String>
		<Key>UserName</Key>
		<Value>user</Value>
	</String>
	<String>
		<Key>Password</Key>
		<Value Protected="True" />
	</String>
	<Times>
		<LastModificationTime>p4JE3A4AAAA=</LastModificationTime>
		<CreationTime>nYJE3A4AAAA=</CreationTime>
		<LastAccessTime>p4JE3A4AAAA=</LastAccessTime>
		<Expires>False</Expires>
		<UsageCount>2</UsageCount>
		<LocationChanged>nYJE3A4AAAA=</LocationChanged>
	</Times>
	<CustomData>
		<Item>
			<Key>KPEX_DoNotSuggestForAutoFill</Key>
			<Value>True</Value>
			<LastModificationTime>p4JE3A4AAAA=</LastModificationTime>
		</Item>
	</CustomData>
</Entry>

It'd be cool if this could be available on other platforms and Apps but I understand it might not make sense for some.

Hope that makes sense!

Cheers,
-Mark

[strongbox-mark]

Haha, OK, got it... I think it's also slightly different functionality, so let's have both :)

[varjolintu]

Our option does not return the entry to outside at all, so it will be ignored by the extension. So these are both the same thing? 🤔 Of course we could add support for that Custom Data key also.

[droidmonkey]

I think as part of our overall browser experience overhaul we could standardize on something like:

Don't share entry with plugins (eg, Browser, SSH Agent, etc)

This would be a setting that exists at the top level and not explicitly within browser settings. Just an idea, we might be over thinking it though 🤔

The problem I see with the exclusion settings, like blocking search and auto-type, is that users forget they set them and then complain when the UI doesn't return them in the action they are requesting. It's a doubl edge sword and adds a lot of overhead if we then offer them to be unblocked in the dialog we are supposed to block them in.

[strongbox-mark]

Our option does not return the entry to outside at all, so it will be ignored by the extension. So these are both the same thing? 🤔 Of course we could add support for that Custom Data key also.

Slightly different, in that we would allow a user to search or browse and use this entry in AutoFill, but just not present it as a suggestion inline on the webpage.

Definitely hear you when you say this is a pain as users forget they've set it pretty often! :/

[JohnLGalt]

Hey, guys, pure user here, just giving some food for thought.

Irfanview has a setting that it implores users to remember if enabling, but that is about it.

However, if the user attempts to do something that they have restricted, could a popup show explaining it has been restricted?

This could also extend to things like screenshots, and other activities restricted by default. Since it would be the same call over and over for any sort of restricted action, it would naturally be useful in many applications in the app, right?

[sorairolake]

Hi all.

I suggest adding Zstandard (RFC 8878) as a compression algorithm, or replacing the existing gzip with this. This was designed to give a compression ratio comparable to that of the gzip format, but faster, especially for decompression. Also, when the compression speed is comparable to gzip, the compression ratio of this is better than gzip.

[droidmonkey]

Compression speed is not a problem here, we aren't dealing with terabytes of data.

[sorairolake]

This is inspired by #4317 (comment).

I think gzip is necessary and sufficient. Also, adding or replacing this will only marginally improve the compression ratio or the compression speed. So I think it is unnecessary to add or replace this.

However, if they deliberately add or replace a compression algorithm, I think Zstandard is better. This is because other compression algorithms improve the compression ratio or the compression speed, but deteriorate the other.

Export demo.kdbx

keepassxc-cli export demo.kdbx > demo.xml

Benchmarks

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
bzip2 -ck demo.xml	20.4 ± 1.2	19.0	25.3	17.58 ± 2.50
gzip -ck demo.xml	6.6 ± 0.5	6.1	8.6	5.68 ± 0.85
lz4 -c demo.xml	1.2 ± 0.2	1.0	2.5	1.00
xz -ck demo.xml	53.7 ± 1.6	51.6	58.2	46.37 ± 6.19
zstd -c demo.xml	2.4 ± 0.3	2.1	3.9	2.04 ± 0.34

Results

Filename	Bytes
./demo.xml	201463
./demo.xml.bz2	77790
./demo.xml.gz	76303
./demo.xml.lz4	103452
./demo.xml.xz	74260
./demo.xml.zst	75552

Versions

Command	Version
bzip2	1.0.8
gzip	1.10
lz4	1.9.3
xz	5.2.3
zstd	1.5.0

[brokkoli71]

Hello everyone,
I would like to refer to the request for multiple security keys as suggested in #9506. This would allow 2FA for daily use and have a backup password in case I lose the second factor.