KeePass has long been the gold standard and darling of the tech world due to its unrelenting commitment to security, stability, and data sovereignty. However, the XML format which the KDBX file format has been predicated on since 2007 has become a persistent friction point for developers and users in the adoption of modern security and convenience features.
The Problems with KDBX
Let us first start by explaining what a KDBX (4.1) file actually is. Barring the technicalities, a KDBX file is an encrypted & authenticated gzipped XML file which contains the typical fields you may expect of a password manager. Attachments are stored as binary data (the old KDBX 3 format used to base64 encode the files), while custom icons are stored as base64 strings within the XML file. Important to note is that every time a KDBX file is updated, no matter how small the edit was, the entire file gets rewritten. The entire file is also loaded into memory. Perhaps the most relevant part of the spec to this post are the TProtectedString and CustomData references, which, respectively, are the user-facing custom attributes, and non-user-facing plugin or app data.
Brittle Schema
The primary issue is that new features cannot be added natively to the XML tree without causing breaking changes for older clients or third-party clients which have not adopted the change yet. This has led to significant problems implementing new standards that were solved ad hoc, in a backward compatible manner using the custom attributes.
Prior to any KeePass client supporting TOTP, third-party KeePass Proper plugins implemented the feature by adding a TOTP entry to the custom attributes. The problem was that different plugins used different field names and stored the generation parameters differently, making them mutually incompatible. Certain mobile clients then began to include support for the most common plugins’ TOTP format. Then, KeePassXC implemented it into the main client, opting for a standard otp URI that was interoperable with most standalone authenticator apps. Like the plugins, this otp field was stored in the attributes. When KeePass Proper came around to implementing TOTP support natively, Dominik Reichl, the founder, disliked the URI format due to parsing and UX issues. This caused another discontinuity, where KeePass Proper used TimeOtp-Secret while the community forks and plugins mostly used the previously described otpauth format.
Passkey support is another example where complex data was shoehorned into the custom attributes rather than being treated as a first class citizen. StrongBox was the first client to implement passkey support and actively collaborated with KeePassXC to ensure compatibility for KeePassXC’s future release. However, there was a brief period of incompatibility between the two programs, which was promptly resolved. Passkeys litter the user-facing attributes with five different entries, which makes it difficult to select entries which actually matter to the user.
Further adding to the clutter, some mobile clients add attributes which associate app IDs to entries for autofill. Here is a particularly egregious entry I have which best demonstrates this issue:
The first three security question attributes are the only ones that are mine!
The lead developer of KeePassXC summarizes the whole issue well:
... continue reading