Passwork vs KeePass: Verschlüsselungsarchitektur im Vergleich

KeePass hat bessere kryptografische Primitive als viele kommerzielle Passwortmanager, und genau dort beginnt dieser Vergleich. Das Format KDBX 4 unterstützt eine memory-hard Schlüsselableitungsfunktion, authentifiziert seinen Geheimtext, bevor überhaupt etwas entschlüsselt wird, und verschlüsselt die gesamte Datenbank statt nur der Passwortfelder.

Was KDBX nicht hat, ist eine Schlüsselverwaltung für mehr als eine Person. Es gibt einen Schlüssel, er gehört zu einer Datei und nicht zu einem Menschen, und er öffnet alles. Jede Mehrbenutzer-Eigenschaft, die ein Team irgendwann braucht – einer Person den Zugriff entziehen, wissen, wer welche Zugangsdaten gelesen hat, begrenzen, was ein einzelner abgeflossener Schlüssel offenlegt –, muss außerhalb des Formats entstehen, meist aus Dateisystemrechten und guten Absichten.

Das ist die eigentliche Trennlinie, und sie zeigt sich in drei Momenten: wenn zwei Personen die gemeinsame Datenbank gleichzeitig speichern, wenn jemand das Unternehmen verlässt und wenn ein Auditor fragt, wer im letzten Quartal welche Zugangsdaten geöffnet hat.

Was KDBX 4 tatsächlich leistet

Eine KDBX-4-Datei wird mit AES-256 im CBC-Modus mit PKCS#7-Padding oder mit ChaCha20 verschlüsselt, so die Formatspezifikation. Der Schlüssel entsteht, indem die Komponenten des Masterschlüssels zu einem 256-Bit-Wert gehasht werden, dieser Wert durch eine Schlüsselableitungsfunktion läuft und das Ergebnis anschließend mit einem bei jedem Speichern neuen Seed gehasht wird. Drei Ableitungsfunktionen sind ohne Plugins enthalten: AES-KDF, Argon2d und Argon2id.

Bei der Integrität hat KDBX 4 den Vorsprung gegenüber dem Vorgänger gewonnen. Die Datei speichert einen SHA-256-Hash des Headers, sodass Beschädigungen ohne den Masterschlüssel erkennbar sind, anschließend einen HMAC-SHA-256 des Headers, und die Nutzdaten werden in 1-MB-Blöcke aufgeteilt, die jeweils ihren eigenen HMAC tragen. Die Spezifikation nennt das „ein Encrypt-then-MAC-Schema“, das heißt, die Authentizität wird geprüft, bevor überhaupt etwas entschlüsselt wird. KDBX 3.1 hashte stattdessen den Klartext, und die Anmerkung des Autors zu dieser Änderung ist wegen ihrer Zurückhaltung ein Zitat wert:

Obwohl das Encrypt-then-MAC-Schema (KDBX 4) allgemein als sicherer gilt als ein MAC-then-Encrypt-Schema (KDBX 3.1), glauben wir nicht, dass KDBX-3.1-Dateien unsicher waren.

Für ein Team sind zwei Einschränkungen wichtig. KDBX 3.1 ist in KeePassXC weiterhin ein natives Format, deshalb gilt „KeePass bedeutet Argon2 und HMAC“ erst, sobald jemand die Datenbank tatsächlich migriert hat – ein manueller Schritt in den Verschlüsselungseinstellungen. Und der Speicherparameter von Argon2 ist durch das schwächste Gerät begrenzt, das die Datei öffnet: KeePass empfiehlt die Hälfte des Arbeitsspeichers des kleinsten Geräts und warnt, dass ein großer Speicherparameter unter iOS AutoFill beeinträchtigen kann; dort werden 64 MB oder weniger empfohlen. Eine KDF ist nur so stark wie die Parameter, die Ihr Telefon verkraftet.

Der Umfang der Verschlüsselung ist tatsächlich besser als bei mehreren gehosteten Wettbewerbern: „KeePass verschlüsselt die gesamte Datenbank, das heißt nicht nur Ihre Passwörter, sondern auch Ihre Benutzernamen, URLs, Notizen und so weiter.“ Eine gestohlene KDBX-Datei verrät nichts über ihren Inhalt, nicht einmal die Titel der Einträge.

Eine Sache sieht wie eine zweite Schicht aus, ist es aber nicht. KDBX wendet auf geschützte Felder innerhalb des XML zusätzlich Salsa20 oder ChaCha20 an, und die Spezifikation begegnet dem Missverständnis direkt:

Wir betonen, dass der einzige Zweck der inneren Verschlüsselung darin besteht, den Schutz des Prozessspeichers zu unterstützen. Die innere Verschlüsselung hat keinen Einfluss auf die kryptografische Sicherheit des KDBX-Dateiformats.

Ihr Schlüssel liegt im inneren Header und hängt nicht vom Masterschlüssel ab.

Wo der Schlüssel liegt – und warum das alles andere entscheidet

Der Masterschlüssel von KeePass ist zusammengesetzt: ein Masterpasswort, eine Schlüsseldatei und ein über DPAPI an das aktuelle Windows-Konto gebundener Schlüssel, in beliebiger Kombination. Alle gewählten Komponenten sind erforderlich, und die Dokumentation zum Masterschlüssel wird dabei deutlich:

Wenn Sie eine der Komponenten des Masterschlüssels vergessen oder verlieren (oder die Zusammensetzung vergessen), sind alle in der Datenbank gespeicherten Daten verloren. Es gibt keine Backdoor und keinen Universalschlüssel, der Ihre Datenbank öffnen kann.

Beachten Sie, was diese Komponenten gemeinsam haben. Ein Passwort ist Wissen, eine Schlüsseldatei ist Besitz, ein DPAPI-Schlüssel ist ein Maschinenkonto. Keine davon ist eine Identität, die die Datenbank erkennt und später von einer anderen unterscheiden kann. Der Schlüssel ist eine Eigenschaft der Datei.

Passwork setzt bei der Person an und folgt demselben Prinzip der Zero-Knowledge-Architektur (der Server verarbeitet ausschließlich Geheimtext), aufgebaut um die individuelle Identität statt um ein einzelnes Dateigeheimnis. Jeder Benutzer hat ein eigenes RSA-Schlüsselpaar, das clientseitig erzeugt wird; der private Teil wird mit einem Schlüssel verschlüsselt, der aus dem Masterpasswort abgeleitet ist. Ein Tresor erhält bei der Erstellung einen eigenen AES-256-Schlüssel, und jeder Benutzer mit Zugriff hält eine separate Kopie dieses Tresorschlüssels, verschlüsselt mit seinem eigenen öffentlichen Schlüssel (Schlüsselhierarchie). Der Server verarbeitet immer nur Geheimtext (Überblick zur Kryptografie).

Die gemeinsame Nutzung folgt aus dieser Struktur. Eine Zugriffsvergabe verschlüsselt den Tresorschlüssel neu für den öffentlichen Schlüssel des Empfängers, statt die Daten neu zu verschlüsseln (Mechanik der Freigabe). Ein Entzug löscht die verschlüsselte Kopie dieser Person. Alle anderen arbeiten mit demselben Tresorschlüssel weiter, und nichts wird neu verschlüsselt.

Wo die Kryptografie von KeePass für Einzelnutzer stärker ist

Bei der Schlüsselableitung zeigt sich das. Argon2 ist memory-hard, und genau diese Eigenschaft macht das Knacken mit GPUs und ASICs teuer; KeePass erklärt, warum in diesem Zusammenhang Argon2d bevorzugt wird: „ein besserer Schutz gegen eine tatsächlich bestehende Bedrohung (das Knacken von Passwörtern mit GPUs/ASICs ist Stand der Technik) ist wichtiger als ein Schutz gegen bestimmte Seitenkanalangriffe, die auf Client-Geräten in Zukunft zu einem Problem werden können oder auch nicht.“ Passwork leitet den Masterschlüssel mit PBKDF2 über 300.000 Iterationen auf SHA-256 ab – eine vertretbare, von NIST anerkannte Einstellung, aber nicht memory-hard, und gegenüber spezialisierter Cracking-Hardware macht dieser Unterschied etwas aus.

An der Schlussfolgerung für ein Team, das Zugangsdaten über mehr als eine Person hinweg nutzt, ändert das nichts: dort entscheidet die Schlüsselverwaltung, nicht die Stärke des Verschlüsselungsverfahrens, und um diese Frage geht es im weiteren Vergleich. Für einen einzelnen Benutzer mit einem Laptop und einer Datei, der nichts mit anderen teilt, ist das die Eigenschaft, die gegen Offline-Knackversuche am meisten zählt.

Was passiert, wenn ein Team die Datei gemeinsam nutzt

Hier zeigt sich das Entwurfsziel. Die KeePass-Dokumentation zu mehreren Benutzern formuliert es ohne Einschränkung:

Alle Benutzer verwenden dasselbe Masterpasswort und/oder dieselbe Schlüsseldatei, um die Datenbank zu öffnen. Es gibt keine Zugriffskontrolllisten (ACLs) pro Gruppe oder pro Eintrag. Um den Schreibzugriff auf die Datenbankdatei einzuschränken (das heißt, nur eine ausgewählte Gruppe von Benutzern darf die gespeicherten Daten ändern), verwenden Sie Dateisystem-Zugriffsrechte.

Zugriffskontrolle gibt es, aber sie liegt in NTFS oder in Ihrer SMB-Freigabe, nicht im Produkt und nicht in der Kryptografie. Lesezugriff ist konstruktionsbedingt alles oder nichts, denn Lesen setzt den einen Schlüssel voraus, der alles entschlüsselt.

KeePass 2.x erkennt Konflikte. Beim Speichern „prüft es zunächst, ob die Datei auf der Festplatte seit dem Laden geändert wurde“, und bietet dann an, zu synchronisieren statt zu überschreiben. Das Zusammenführen erfolgt auf Eintragsebene, und die unterlegene Version eines konfliktbehafteten Eintrags wird in der Historie dieses Eintrags aufbewahrt, nicht verworfen.

Konflikte werden über den Vergleich der Zeitstempel der letzten Änderung gelöst; entscheidend ist damit die Systemuhr jedes Benutzers und nicht eine Form von Autorität. Die Abfrage erscheint nur beim Speichern: „Die Synchronisierungsabfrage wird nur durch den Befehl ‚Speichern‘ ausgelöst, nicht durch den Befehl ‚Speichern unter‘. Wird der Befehl ‚Speichern unter‘ ausgeführt und eine Datei manuell ausgewählt, wird diese Datei immer überschrieben.“ Historieneinträge überdauern ein Zusammenführen, „können aber von der automatischen Historienpflege gelöscht werden“ – diese richtet sich nach der Größe. Und KeePass 1.x hat überhaupt keine Synchronisierung, sodass ein Speichern dort tatsächlich überschreibt, was sich darunter geändert hat.

KeePassXC unterscheidet sich in einem Punkt, der wichtig ist, wenn es Ihr Client ist. Es hat eine Funktion zum Zusammenführen in der Oberfläche und als keepassxc-cli merge, die Einträge über UUID und Änderungszeit vergleicht. Eine integrierte Cloud-Synchronisierung fehlt aber absichtlich, und die FAQ nennt den Grund: Die Datenbank soll in einem gemeinsamen Cloud-Ordner liegen und der Synchronisierungsdienst soll sich darum kümmern, was „die Komplexität unseres Codes niedrig hält“. Vertretbare Technik mit einer konkreten betrieblichen Folge. Dropbox, Nextcloud und OneDrive wissen nichts über KDBX, deshalb entstehen bei gleichzeitigen Änderungen Konfliktkopien der Datei, und sie wieder zusammenzuführen ist Handarbeit, an die jemand denken muss.

Das von KeePass selbst empfohlene Muster für gemeinsam genutzte Dateien ist ein Trigger: eine lokale Kopie behalten und mit der Hauptdatei synchronisieren – ein Verfahren, das die Dokumentation damit beschreibt, es verhindere „Datenverlust, wenn Datenbankdateien von anderen Anwendungen überschrieben werden (zum Beispiel von Software für Cloud-Speicherdienste)“. Es funktioniert. Es bedeutet aber auch, dass Ihr Zugriffsmodell nun von einem Trigger abhängt, der in einer Konfigurationsdatei liegt, die laut Trigger-Seite unverschlüsselt ist und „für alle Benutzer dieser KeePass-Installation gilt“.

Zugriff zurücknehmen

Fragen Sie das in jeder Evaluierung zuerst. Ein dateibasiertes Modell hat darauf keine gute Antwort, und die Antwort, die es hat, überrascht die meisten.

Ein ausscheidender Mitarbeiter hatte den Masterschlüssel. Möglicherweise hat er außerdem eine Kopie der KDBX-Datei auf einem Laptop, in einem Backup, in einem Synchronisierungsordner oder in einer Konfliktkopie, die niemand aufgeräumt hat. Ein Wechsel des Masterschlüssels verschlüsselt die Datenbank für die Zukunft neu und ändert nichts an bereits bestehenden Kopien. Diese bleiben mit dem Schlüssel entschlüsselbar, unter dem sie gespeichert wurden – unbegrenzt. Die Eintragshistorie verschärft das: Wird ein Passwort in der Datenbank rotiert, bleibt der vorherige Wert in der Historie dieses Eintrags, sodass eine veraltete Kopie sowohl das alte als auch das neue Geheimnis enthält.

Der einzige echte Entzug besteht darin, alle Zugangsdaten zu rotieren, die diese Person erreichen konnte – in einem Einzeldateimodell also alle. Der Aufwand richtet sich nach der Größe Ihrer Datenbank und nicht nach dem Aufgabenbereich dieser Person.

In Passwork ist dasselbe Ereignis begrenzt. Der Entzug des Zugriffs löscht die verschlüsselte Kopie des Tresorschlüssels dieses Benutzers, und die übrigen Mitglieder arbeiten mit dem unveränderten Schlüssel weiter. Eine Rotation nach dem Offboarding bleibt die richtige Maßnahme für alles, was die Person tatsächlich gelesen hat, und kein Produkt kann Zugangsdaten zurückholen, die sich jemand gemerkt hat. Der Unterschied ist, dass der Schaden auf einen Tresor begrenzt bleibt statt auf alles und dass der Entzug eine einzelne Operation ist und kein Projekt.

Wo die LDAP-/Active-Directory-Integration von Passwork konfiguriert ist, muss dieser Vorgang gar nicht manuell erfolgen: Wird das Konto in AD deaktiviert, entzieht Passwork den Zugriff automatisch entsprechend dem Verzeichniszustand, sodass ein Offboarding im Verzeichnis ein Offboarding im Tresor ist. Und das Sicherheits-Dashboard überlässt die Nachbereitung nicht dem Gedächtnis – es markiert Zugangsdaten, die ein Benutzer nach dem Entzug seines Zugriffs weiterhin erreichen könnte, als Kompromittierungsrisiko und macht aus dem, was diese Person erreichen konnte, eine sichtbare Arbeitsliste statt etwas, das von Hand rekonstruiert werden muss.

Wer hat was gelesen

KeePass ist eine Desktop-Anwendung ohne Serverkomponente – ein Punkt, den die eigenen Hinweise machen, während sie einen Bericht über einen Timing-Angriff zurückweisen: KeePass „verfügt über keine Serverfunktionen (insbesondere kann das automatische Öffnen einer Datenbank nicht extern ausgelöst werden)“.

Das hat Folgen für das Audit. KDBX erfasst Änderungszeitstempel und Eintragshistorie, also ein Protokoll der Änderungen an der Datei, nicht ein Protokoll der Zugriffe. Nichts hält fest, dass jemand die Datenbank geöffnet und Zugangsdaten gelesen hat, denn das Lesen findet vollständig im Client statt. Bei einem gemeinsamen Masterschlüssel kann selbst ein Änderungseintrag nicht zuverlässig sagen, welcher Mensch ihn verursacht hat.

Passwork protokolliert Aktionen serverseitig und kann sie im CEF-Format an syslog oder das Windows-Ereignisprotokoll für ein SIEM weiterleiten (Aktivitätsprotokoll, Ereignisliste). Vergaben, Änderungen und Entzüge werden einzeln erfasst und einem Konto zugeordnet.

Einer Datei vertrauen, die alle bearbeiten

Das schärfste Argument gegen das Muster der gemeinsamen Datenbank kommt aus der Dokumentation von KeePass selbst.

KeePass unterstützt Platzhalter in Einträgen. {CMD:...} führt eine Befehlszeile aus, und Feldreferenzen können Daten aus anderen Einträgen holen, sodass eine präparierte URL andere Zugangsdaten abfließen lassen kann. Die Sicherheitsseite nennt das Beispiel selbst: https://example.com/?u={REF:U@T:Facebook}&p={REF:P@T:Facebook}. Der darauf folgende Hinweis ist eindeutig:

Wenn Sie eine Datenbank öffnen, die von jemand anderem erstellt oder geändert wurde, sollten Sie alle Daten, die Sie verwenden möchten, sorgfältig prüfen. Wenn Sie dem Ersteller der Datenbank nicht vollständig vertrauen, öffnen Sie keine an Einträge angehängten Dateien.

Lesen Sie das vor dem Hintergrund einer Bereitstellung auf einem Netzlaufwerk. Eine Team-Datenbank wird per Definition von anderen Personen erstellt und geändert, und jeder mit Schreibzugriff kann Einträge hinzufügen, die die anderen anklicken werden. Das von KeePass dokumentierte Vertrauensmodell setzt voraus, dass eine Datenbank einen Besitzer hat, der für ihren Inhalt bürgt – und genau das ist eine gemeinsam genutzte Team-Datei nicht.

Dokumentierte Schwachstellen

CVE-2023-32784 (CVSS 7,5) erlaubte es, das Masterpasswort im Klartext aus einem Speicherabbild in KeePass 2.x vor 2.54 zu rekonstruieren, auch aus einer Auslagerungs- oder Ruhezustandsdatei und selbst nach dem Beenden des Prozesses; nur das erste Zeichen blieb nicht rekonstruierbar. Ursache war ein eigenes Textfeld, das pro Zeichen Reste im .NET-Speicher hinterließ. Der Fehler wurde in 2.54 behoben, und der Forscher bescheinigte eine schnelle Reaktion.

CVE-2023-24055 (CVSS 5,5) ist von MITRE als umstritten markiert. Ein Angreifer mit Schreibzugriff auf die XML-Konfigurationsdatei konnte einen Export-Trigger hinzufügen und Passwörter im Klartext abgreifen. Der NVD-Eintrag hält die Position des Herstellers fest: „Die Passwortdatenbank soll nicht gegen einen Angreifer sicher sein, der diese Zugriffsebene auf dem lokalen PC hat.“ Diese Position ist konsistent, und die Security-Issues-Seite begründet sie allgemein: Wer Ihre Konfigurationsdatei schreiben kann, kann meist auch die ausführbare Datei ersetzen.

Zur Einordnung: KeePassXC hat ein externes Audit durchlaufen, abgeschlossen im Januar 2023, und sagt offen, dass ein Audit „nur für eine ‚Momentaufnahme‘ des Codes gilt“.

Vergleichstabelle

Migration – und worauf dabei zu achten ist

Passwork importiert KeePass-XML, daneben JSON und CSV. Die verschlüsselte KDBX-Binärdatei wird nicht gelesen, und das Parsen findet im Client statt und nicht auf dem Server – die einzige Anordnung, die dazu passt, dass der Server nie Klartext sieht.

Die Folge sollte ausgesprochen und nicht übergangen werden. Ein Export aus KeePass nach XML erzeugt eine unverschlüsselte Datei mit allen Zugangsdaten, und sie liegt so lange auf der Festplatte, wie die Migration dauert. Führen Sie ihn auf einem Rechner aus, den Sie kontrollieren, auf lokalem Speicher statt in einem synchronisierten Ordner, und löschen Sie die Datei mit einem Werkzeug, das überschreibt und nicht nur den Verweis entfernt. Es ist der eine Schritt einer Migration, in dem ein unachtsamer Nachmittag die Kryptografie beider Produkte gleichzeitig aushebelt.

Wann KeePass die richtige Wahl ist

Wenn Sie konkret abwägen, ob KeePass für ein kleines Team ausreicht, behandelt Passwort- und Zugriffsverwaltung für KMU: Reicht KeePass aus? genau diese Frage. Dieser Artikel bleibt enger gefasst, allein auf der Achse der Verschlüsselungsarchitektur, für Teams jeder Größe.

Wenn Sie eine Person sind oder zwei Personen, die ohnehin alles gemeinsam nutzen, ist KeePass mit einer KDBX-4-Datenbank und vernünftigen Argon2-Parametern eine ausgezeichnete Wahl – und kostenlos. Die Kryptografie ist stark, das Format ist öffentlich dokumentiert, und ohne Server gibt es keinen Dienst, in den eingebrochen werden kann.

Das Modell passt nicht mehr, sobald Sie Antworten brauchen, die eine Datei nicht geben kann. Wer genau hat hierauf Zugriff. Was genau ist verloren gegangen, als dieser Laptop verschwand. Was bricht, wenn diese Person am Freitag geht. Belegen Sie, dass der externe Dienstleister nie Produktions-Zugangsdaten gesehen hat.

Ein nützlicher Test vor der Entscheidung: Zählen Sie, wie viele Personen heute den Masterschlüssel zu Ihrer gemeinsamen Datenbank besitzen, und fragen Sie dann, was Sie rotieren müssten, wenn eine von ihnen morgen ginge. Lautet die Antwort „alles“, ist das kein Konfigurationsproblem, das sich wegstellen lässt. Es ist das Dateimodell, das genau wie vorgesehen funktioniert. Die Referenz zur Schlüsselhierarchie zeigt, wie die alternative Grenze aussieht.

Eine Datei hat einen Schlüssel für alle. Ein Tresor hat einen Schlüssel pro Tresor, verschlüsselt pro Person. Dieser Abstand wird nicht kleiner, wenn ein Team wächst; er wird größer. Wenn KeePass nicht die einzige Alternative auf Ihrer Auswahlliste ist, geht der Vergleich der Tresor-Verschlüsselungsarchitektur von Passwork und Bitwarden dieselben drei Momente (gleichzeitiges Speichern, Offboarding, Audit) für einen cloud-nativen Wettbewerber anstelle eines Dateiformats durch.

Führen Sie den Masterschlüssel-Test in Ihrem eigenen Team durch und sehen Sie sich dann die Alternative an. Kostenlose Passwork-Testversion starten.

Häufig gestellte Fragen

Passwort- und Zugriffsverwaltung für KMU: Reicht KeePass aus?

Jeder IT-Administrator, der KeePass für ein Team betreibt, erzählt dieselbe Geschichte. Es beginnt mit einer gemeinsam genutzten .kdbx-Datei auf einem Netzlaufwerk. Dann kann jemand sie nicht öffnen, weil ein Kollege sie gesperrt hat. Dann überschreibt ein junger Systemadministrator eine Änderung, die jemand anderes eine Stunde zuvor gemacht hat. Dann verlässt ein Mitarbeiter das Unternehmen, und niemand weiß genau, auf welche Passwörter er Zugriff hatte. KeePass ist ein wirklich ausgezeichnetes Werkzeug – für eine Person. Sobald Sie es einem Team vorsetzen, verwalten Sie keine Passwörter mehr. Sie verwalten ein

PassworkAlex Muntyan

Was ist Zero-Knowledge-Verschlüsselung? So funktioniert sie in 5 Minuten

Zero-Knowledge-Verschlüsselung bedeutet, dass der Server nie Ihre Entschlüsselungsschlüssel hält, sondern nur Geheimtext. Erfahren Sie, wie die Schlüsselkette funktioniert, wogegen sie schützt, wogegen nicht und wie sich die Aussage eines Anbieters überprüfen lässt.

PassworkPasswork Team

Passwork vs Bitwarden: Tresor-Verschlüsselungsarchitektur im Vergleich

Passwork verschlüsselt jeden Tresor mit einem eigenen Schlüssel. Bitwarden verschlüsselt eine ganze Organisation mit einem gemeinsamen Schlüssel. Dieser Vergleich zeigt, was das für den Schadensumfang, die Isolation von Teams, die Kontowiederherstellung und die Audit-Antworten bedeutet, wenn Zugangsdaten abfließen.

PassworkPasswork Team