Suggestions for improvement
As implementors of the KDBX file format, we have identified several areas where the format could be improved in a future version. This chapter outlines some of these suggestions.
Many of the topics are drawn from the KDBX Standard Discussion (#6229) on the KeePassXC GitHub repository, where maintainers and developers of various KeePass-compatible clients discussed desired improvements to the KDBX format.
Serialize tags as XML elements
Instead of the heterogeneous way tags are processed from strings, the list of tags could be stored using XML elements, with one XML element per tag.
Identify attachments by UUIDs
Currently, attachments in the inner header are referenced in the XML database by their order of appearance. This is the only case where elements in the XML database are not identified by UUIDs, and having attachment UUIDs would simplify unambiguous identification of attachments, e.g. during merge operations.
Argon2id as the Standard KDF
The discussion proposed standardizing on Argon2id instead of Argon2d as the key derivation function. Argon2id is a hybrid variant that provides better resistance to both side-channel and GPU-based attacks compared to Argon2d alone, making it a stronger default choice for password databases.
Source: #6229 (opening post)
Password Modification Datetime
A dedicated timestamp recording when the password field of an entry was last changed was proposed as a “must have.” The use case is that the generic “last modified” timestamp of an entry changes whenever any field is edited — not just the password — so it cannot reliably track password age for rotation policies.
KeePass developer DReichl argued against adding this field, noting that: a user may create an entry for an account that predates the entry; a failed password-change attempt could result in an incorrect automatic timestamp; and KeePass already approximates this via a “Last Password Modification Time (Based on History)” column. KeePassXC maintainer droidmonkey disagreed, arguing that edge cases should not block a broadly useful feature and that the application can detect password field changes through text-change events.
Source: #6229 — DReichl, May 2021; droidmonkey reply
Built-in Entry Layout Specification
The format currently provides no standard way to describe how an entry’s fields should be presented in a UI. A built-in entry layout specification would allow clients to declare structured display templates for different entry types (e.g., credit cards, identity documents, SSH keys), ensuring consistent rendering across all KDBX-compatible applications.
Source: #6229 (opening post); related issue #863
Built-in TOTP Specification
Multiple incompatible TOTP implementations exist across the KeePass ecosystem: KeePass’s own multi-field approach, KeePassXC’s system, and various historical plugin formats. The proposal is to standardize on a single otp attribute using the widely-adopted otpauth:// URL format as the canonical representation.
KeePassXC maintainers confirmed they already prefer otpauth URLs and maintain legacy formats only for backwards compatibility. KeePass’s multi-field approach was criticized for being the only client to implement that particular scheme.
Source: #6229 — sirtao, Apr 2021; phoerious reply; droidmonkey reply
Built-in Hardware Key Specification
The proposal asks for a standardized way to specify hardware key (e.g., YubiKey) parameters as part of the KDBX credential set, including support for multiple hardware keys to allow backup keys. Currently each client implements hardware key support differently, preventing interoperability.
Related: Discussion #9506
Source: #6229 (opening post)
Built-in Quick Unlock Specification
The proposal asks for the KDBX format to define a standard quick unlock mechanism — allowing users to re-open a locked database with a shorter credential (e.g., a PIN or biometric) without repeating the expensive key derivation step. The implementation model would store the fully-derived database key encrypted in memory, with the quick unlock credential as the encryption key for that in-memory store.
KeePass developer DReichl argued the feature should remain application-level rather than database-level, because: different devices need different unlock methods; device capabilities vary; multiple open databases would create ambiguous unlock semantics; and the feature is inherently tied to the operating environment. KeePassDX developer J-Jamet provided a taxonomy of two technical approaches (in-memory re-encryption vs. OS credential store), noting both have different security trade-offs.
Source: #6229 — DReichl, Mar 2021; droidmonkey, Apr 2021; J-Jamet, Apr 2021
Built-in Favorites / Pinned Items
A standard mechanism to mark entries as “favorites” or “pinned” was proposed, allowing clients to surface important entries without requiring workarounds like special group names or tags. Some participants noted that tags can already serve this purpose and that a vendor-specific predefined tag (as done in Enpass) achieves the same effect, but a first-class standard field would ensure cross-client portability.
Source: #6229 (opening post); user858753257, Feb 2020
Key File Format Simplification
The proposal is to support only two key file formats going forward: plain binary key files, and the structured .key/.keyx XML format. Eliminating other ad-hoc formats would simplify implementation across clients and reduce the risk of weak key files being accepted.
Source: #6229 (opening post)
Multi-Valued Fields
Both core fields (e.g., URL) and custom fields should support multiple values natively within the KDBX schema, rather than requiring clients to invent their own conventions (e.g., URL2, KP2A_URL_1, WebDomain[1]). The lack of a standard for multiple values has led to divergent, incompatible implementations across clients.
A related problem raised in the discussion is that KeePassDX uses WebDomain / WebDomain[counter] while Keepass2Android uses KP2A_URL / KP2A_URL_<counter> for storing additional URLs, causing browser autofill failures when switching clients. Standardizing a single prefix — or natively supporting multiple URL values — would resolve this.
Source: #6229 (opening post); ghost comment, Nov 2020; related issues #398, #3558, KeePassDX #524
Passkey / WebAuthn Credential Storage
Strongbox developer strongbox-mark raised the need to standardize passkey (WebAuthn) credential storage across KeePass clients before incompatible implementations emerge. A de facto convention was already present in a KeePassXC work-in-progress PR: the private key is stored as a PEM file attachment named webauthn.pem, the WebAuthn-generated username is stored in the password field, and the user-chosen username/email is stored in the username field. Entries are identified as passkey entries by scanning for the webauthn.pem attachment name.
Open issues noted in the discussion include: how to export WebAuthn credentials portably for import into other password managers; and uncertainty about whether major browsers would expose APIs allowing third-party passkey providers.
Source: #6229 — strongbox-mark, Jan 2023; varjolintu reply; related PR #8825
Database-Level Transactional History
Currently, history is tracked at the entry level only. The proposal asks for transactional history at the database level, enabling undo of destructive operations such as entry deletions and group moves, and ensuring overall database consistency across operations. This would require the format to store a global change log rather than — or in addition to — per-entry history snapshots.
Source: #6229 (opening post)