Souverän wechseln: von 1Password zu KeePass unter macOS, Linux, iOS und iPadOS
Photo by Jason Dent on Unsplash
Passwörter sind Vertrauenssache. Eine Förderentscheidung von 1Password und der anschließende Umgang mit Kritik haben dieses Vertrauen für mich beendet. Der Wechsel war zugleich eine Gelegenheit, meine Zugangsdaten künftig souveräner zu verwalten: in einem offenen Dateiformat, mit frei wählbaren Anwendungen sowie einem selbst bestimmten Speicher- und Synchronisationsweg.
In diesem Beitrag zeige ich, wie ich meine Daten von 1Password zu einer KeePass-basierten Lösung migriert habe, die ich unter macOS, Linux, iOS und iPadOS verwende.
Was digitale Souveränität für mich bedeutet
Einem Passwortmanager vertraue ich besonders sensible Daten an. Deshalb möchte ich mich nicht nur darauf verlassen können, dass diese sicher verschlüsselt werden. Ebenso wichtig ist mir die Kontrolle darüber, wo meine Passwortdatenbank gespeichert wird, mit welchen Anwendungen ich sie öffne und wie sie zwischen meinen Geräten synchronisiert wird.
Digitale Souveränität bedeutet für mich nicht, jede Komponente selbst entwickeln oder einen eigenen Server betreiben zu müssen. Entscheidend ist vielmehr, dass ich nicht dauerhaft von einem bestimmten Anbieter, einem Benutzerkonto oder einer vorgegebenen Cloud abhängig bin. Ich möchte einzelne Komponenten austauschen können, ohne meine gesamte Passwortverwaltung neu aufbauen zu müssen.
Der konkrete Anlass für den Wechsel war meine Unzufriedenheit mit einer Unternehmensentscheidung von 1Password. Ausschlaggebend für die Wahl der neuen Lösung waren jedoch vor allem die Möglichkeiten, die mir ein offenes Format und ein herstellerunabhängiges Ökosystem bieten.
Meine Anforderungen an einen neuen Passwortmanager
Aus diesen Überlegungen ergaben sich folgende Anforderungen:
- ein offenes, von mehreren Anwendungen unterstütztes Datenformat
- eine etablierte und aktiv gepflegte Open-Source-Lösung
- eine sichere Verschlüsselung der Passwortdatenbank
- kein Zwang zu einem bestimmten Clouddienst
- freie Wahl des Speicherorts und des Synchronisationswegs
- Unterstützung für macOS, Linux, iOS und iPadOS
- eine gute Browserintegration einschließlich der Unterstützung von Passkeys
- die Nutzung auf mehreren Geräten durch eine einzelne Person
- unabhängige Backups und eine nachvollziehbare Versionshistorie
Das Teilen von Passwörtern mit anderen Personen und die Verwaltung gemeinsamer Zugänge in einem Team gehören dagegen nicht zu meinem Anwendungsfall. Dafür eignet sich wahrscheinlich eine zentral verwaltete Lösung mit Benutzerkonten, Berechtigungen und Freigabefunktionen besser.
KeePass als offenes Ökosystem
Meine Wahl fiel nicht auf eine einzelne Anwendung, sondern auf das Ökosystem rund um KeePass und das offene KDBX-Dateiformat. Dadurch ist meine Passwortdatenbank nicht an einen bestimmten Client gebunden. Verschiedene Anwendungen können dasselbe Format lesen und schreiben, sodass ich für jedes Betriebssystem ein geeignetes Programm auswählen kann.
Auf dem Desktop verwende ich KeePassXC. Die plattformübergreifende Open-Source-Anwendung ist für Linux, macOS und Windows verfügbar und bietet Erweiterungen für gängige Browser. Auf dem iPhone und iPad kommt KeePassium zum Einsatz, eine kommerziell angebotene Open-Source-App für iOS und iPadOS.
Dass dabei unterschiedliche Anwendungen zusammenarbeiten, ist für mich kein Nachteil, sondern eine wesentliche Stärke der Lösung. Meine Passwortdatenbank gehört weder zu KeePassXC noch zu KeePassium. Beide Programme sind austauschbare Werkzeuge, mit denen ich auf dieselbe KDBX-Datei zugreife.
Auch der Synchronisationsweg wird nicht von den Anwendungen vorgegeben. Ich kann selbst entscheiden, wo die Datenbank gespeichert, wie sie zwischen meinen Geräten übertragen und auf welche Weise sie gesichert wird.
Diese Freiheit bringt zusätzliche Verantwortung mit sich. Ich muss mich selbst um Backups, Schlüsseldateien und mögliche Synchronisationskonflikte kümmern. Für meinen persönlichen Anwendungsfall ist das ein guter Tausch: mehr Eigenverantwortung gegen weniger Abhängigkeit von einem einzelnen Anbieter.
Im ersten Schritt müssen die vorhandenen Daten aus 1Password exportiert und in eine neue KeePassXC-Datenbank übernommen werden.
Vorbereitungen in 1Password
Zum Zeitpunkt der Migration verwaltete ich meine Passwörter in drei Tresoren, den sogenannten Vaults.
Zusätzlich hatte ich zahlreiche archivierte Einträge und einige Passkeys gespeichert. Da Passkeys nicht über die Exportfunktion übernommen werden, musste ich sie später neu anlegen.
Dazu suchte ich in 1Password nach “passkey” und kennzeichnete die betroffenen Einträge zusätzlich mit dem Tag “Passkey”. So konnte ich sie nach der Migration leicht wiederfinden. Anschließend entfernte ich die Passkeys sowohl aus den jeweiligen 1Password-Einträgen als auch aus den zugehörigen Benutzerkonten.
Vor dem Entfernen eines Passkeys sollte unbedingt geprüft werden, ob weiterhin eine andere Anmeldemethode oder ein Wiederherstellungsverfahren verfügbar ist. Andernfalls besteht die Gefahr, den Zugriff auf das jeweilige Konto zu verlieren.
Anschließend exportierte ich meine Daten über den Dateidialog im Format “1PUX”. 1Password weist dabei auf zwei wichtige Einschränkungen hin:
- Passkeys werden nicht exportiert.
- Die Exportdatei ist nicht verschlüsselt.
Die 1PUX-Datei enthält daher sämtliche exportierten Daten unverschlüsselt und muss entsprechend vorsichtig behandelt werden. Sie sollte nur so lange wie nötig auf einem vertrauenswürdigen, möglichst verschlüsselten Datenträger gespeichert und nach erfolgreicher Migration umgehend gelöscht werden. Dabei sollte auch geprüft werden, ob Kopien in Backups, Papierkörben oder Cloudspeichern entstanden sind.
Vor der Migration empfiehlt sich außerdem ein unabhängiges Backup. So lässt sich der ursprüngliche Zustand wiederherstellen, falls beim Import oder bei der anschließenden Bereinigung etwas schiefgeht.
Import in KeePassXC
Die Exportdatei lässt sich direkt über den Startbildschirm von KeePassXC importieren.
Als Importformat wählte ich “1Password Export (.1pux)”. KeePassXC kann die Daten entweder in eine neue oder in eine bestehende Datenbank importieren. Für die Migration legte ich eine neue Datenbank an.
Anschließend vergab ich einen Namen und optional eine Beschreibung für die Datenbank.
Danach folgten die Einstellungen zur Verschlüsselung. Ich verwendete das empfohlene Datenbankformat und ließ KeePassXC die Parameter der Schlüsselableitung auf meinem Computer auf eine Zielzeit von fünf Sekunden kalibrieren. Dadurch benötigt jeder Schlüsselableitungsversuch mehr Rechenzeit, was automatisierte Offline-Angriffe auf das Datenbankpasswort verlangsamt. Auf anderen, insbesondere leistungsschwächeren Geräten kann das Öffnen der Datenbank länger dauern.
Im nächsten Schritt legte ich ein starkes Datenbankpasswort fest. Optional kann zusätzlich eine Schlüsseldatei erstellt werden.
Eine Schlüsseldatei schützt die Passwortdatenbank zusätzlich, bringt aber auch weitere Verantwortung mit sich:
- Die Schlüsseldatei sollte getrennt von der Passwortdatenbank gespeichert und über einen unabhängigen Weg auf die benötigten Geräte übertragen werden.
- Sie darf nicht gemeinsam mit der Datenbank synchronisiert werden.
- Ohne die Schlüsseldatei lässt sich die Datenbank nicht öffnen.
- Deshalb benötigt auch die Schlüsseldatei ein zuverlässiges, getrennt aufbewahrtes Backup.
Nach Abschluss der Einrichtung importierte KeePassXC die Einträge in die neue Datenbank. Anschließend prüfte ich stichprobenartig, ob Benutzernamen, Passwörter, URLs, Notizen und Anhänge korrekt übernommen worden waren.
Archivierte Einträge trennen
Nach dem Import erschienen die bisherigen Tresore als Gruppen in KeePassXC. Unterhalb jeder dieser Gruppen legte ich eine weitere Gruppe namens “Archive” an.
Über die Suchfunktion suchte ich anschließend nach archivierten Einträgen innerhalb der jeweiligen Gruppe:
tag:"Archived" group:"<Name der Gruppe>"
Die gefundenen Einträge verschob ich in die jeweilige Archivgruppe und markierte sie als abgelaufen.
Alternativ hätte ich die Einträge löschen können. Sie wären dadurch zunächst im Papierkorb der Datenbank gelandet. Ich wollte sie jedoch vorerst als Archiv behalten, um bei Bedarf auf ältere Zugangsdaten zurückgreifen zu können.
Browsererweiterung konfigurieren
Anschließend installierte ich die KeePassXC-Erweiterung für meinen Browser und deaktivierte die Erweiterung von 1Password.
Damit die Browsererweiterung auf KeePassXC zugreifen kann, muss sie einmalig mit der Desktopanwendung verbunden werden. Diese Verbindung ist für jedes Browserprofil separat einzurichten.
Die Verbindungsanfrage muss anschließend in KeePassXC bestätigt werden.
Damit war die grundlegende Einrichtung auf dem Desktop abgeschlossen. Anschließend rief ich die zuvor mit “Passkey” markierten Einträge auf und richtete die Passkeys bei den jeweiligen Diensten neu ein.
Überlegungen zur Synchronisation
Meine Passwortdatenbank ist ungefähr 6 MB groß. Da es sich um eine verschlüsselte Binärdatei handelt, verändert bereits die Aktualisierung eines einzelnen Eintrags die gesamte Datei.
Das ist insbesondere bei mobilen Geräten und unzuverlässigen Verbindungen relevant. Wenn zwei Geräte unterschiedliche Versionen der Datenbank bearbeiten und anschließend hochladen, können Synchronisationskonflikte entstehen. Je nach verwendetem Dienst gewinnt im ungünstigsten Fall die zuletzt hochgeladene Datei. Änderungen aus der anderen Version könnten dadurch verloren gehen.
Viele Clouddienste legen bei Konflikten zwar zusätzliche Dateikopien an, darauf wollte ich mich bei einer Passwortdatenbank jedoch nicht verlassen. Eine verlässliche Versionshistorie und die Möglichkeit, voneinander abweichende Datenbanken gezielt zusammenzuführen, waren mir deshalb wichtig.
Gleichzeitig wollte ich keine eigene Serverinfrastruktur betreiben, wie sie beispielsweise bei einer selbst gehosteten Installation von Bitwarden erforderlich wäre. Dafür stellt Bitwarden unter anderem ein Docker-Image bereit.
Für Teams oder mehrere Personen, die Passwörter gemeinsam verwalten und gezielt freigeben möchten, ist eine solche zentral verwaltete Lösung wahrscheinlich die bessere Wahl. Für meinen persönlichen Anwendungsfall wäre sie jedoch unnötig aufwändig.
KeeShare als mögliche Alternative
KeeShare ist eine Funktion von KeePassXC, mit der sich ausgewählte Gruppen zwischen verschiedenen KeePass-Datenbanken austauschen und synchronisieren lassen.
Für meinen Anwendungsfall kam KeeShare jedoch nicht infrage, da weder KeePassium noch die alternative iOS-App Strongbox diese Funktion unterstützen. Dazu existieren weiterhin offene GitHub-Issues:
Deshalb entschied ich mich für eine andere Lösung. Sie funktioniert für mich als technisch versierten Nutzer gut, dürfte für viele andere Menschen aber zu umständlich sein.
Versionierung und manueller Abgleich mit Git
Für die Synchronisation und Versionierung meiner Passwortdatenbank verwende ich Git. Die KDBX-Dateien werden in das Repository aufgenommen, die zugehörigen KEYX-Schlüsseldateien dagegen ausdrücklich ignoriert.
Zusätzlich markiere ich KDBX-Dateien als binär. Dadurch versucht Git bei einem Konflikt nicht, sie wie Textdateien zeilenweise zusammenzuführen.
git init
echo "*.keyx" > .gitignore
echo "*.kdbx binary" > .gitattributes
git add .gitignore .gitattributes *.kdbx
git commit -S -m "Add initial version"
git remote add origin <origin>
git push -u origin main
Auch eine verschlüsselte Passwortdatenbank sollte nicht leichtfertig in einem öffentlichen Repository gespeichert werden. Das Datenbankpasswort könnte langfristig angegriffen werden, und versehentlich eingecheckte Dateien bleiben unter Umständen in der Git-Historie erhalten. Ich verwende deshalb ein privates Repository und achte darauf, dass weder Schlüsseldateien noch unverschlüsselte Exporte aufgenommen werden.
Da Änderungen an der verschlüsselten Datenbank große Teile der Binärdatei betreffen, kann Git die einzelnen Versionen nur eingeschränkt als platzsparende Deltas speichern. Das Repository wächst deshalb mit der Zeit deutlich an. Bei meiner derzeit etwa 6 MB großen Datenbank ist das für mich vertretbar, ich behalte die Größe des Repositorys jedoch im Blick.
Git kann Binärdateien nicht automatisch inhaltlich zusammenführen. Der normale Arbeitsablauf besteht daher aus folgenden Schritten:
- Vor dem Öffnen oder Bearbeiten der Datenbank die aktuelle Version abrufen.
- Änderungen in KeePassXC oder KeePassium durchführen.
- Die geänderte KDBX-Datei committen.
- Den neuen Stand in das Remote-Repository übertragen.
- Parallele Bearbeitungen auf mehreren Geräten möglichst vermeiden.
Entstehen dennoch zwei voneinander abweichende Versionen, müssen die Datenbanken mit der Merge-Funktion von KeePassXC zusammengeführt werden.
Abweichende Datenbanken zusammenführen
KeePass und KeePassXC verfügen über eine Merge-Funktion, mit der sich zwei auseinanderentwickelte Passwortdatenbanken wieder zusammenführen lassen. Die Zusammenführung erfolgt auf Eintragsebene und berücksichtigt unter anderem die jeweiligen Änderungszeitpunkte.
Wurde beispielsweise ein Passwort auf dem iPhone geändert und gleichzeitig ein neuer Eintrag auf dem Mac angelegt, kann KeePassXC daraus eine Datenbankversion erzeugen, die beide Änderungen enthält.
Auf der Kommandozeile lässt sich die Zusammenführung mit folgendem Befehl starten:
keepassxc-cli merge -s A.kdbx B.kdbx
Die Option -s beziehungsweise --same-credentials gibt an, dass beide Datenbanken mit denselben Zugangsdaten geöffnet werden können. Das Ergebnis wird in die zuerst angegebene Datenbank geschrieben, in diesem Beispiel also in A.kdbx.
Vor einer Zusammenführung lege ich eine Kopie beider Datenbankversionen an. Anschließend prüfe ich das Ergebnis, bevor ich es committe und auf die übrigen Geräte verteile.
Git und KeePassium unter iOS und iPadOS einrichten
Eine komfortable Möglichkeit, Git-Repositories unter iOS und iPadOS zu verwenden, ist Working Copy.
Dort klonte ich mein Git-Repository und stellte die enthaltene KDBX-Datei über die Dateien-App für KeePassium bereit. KeePassium kann dadurch auf die von Working Copy verwaltete Datei zugreifen.
Mein Arbeitsablauf auf dem iPhone und iPad sieht damit grundsätzlich so aus:
- In Working Copy die aktuelle Version aus dem Remote-Repository abrufen.
- Die Datenbank mit KeePassium öffnen und bearbeiten.
- Die geänderte Datei in Working Copy committen.
- Den Commit in das Remote-Repository übertragen.
Auch hier gilt: Ich vermeide es möglichst, dieselbe Datenbank gleichzeitig auf mehreren Geräten zu bearbeiten. Sollte dennoch ein Konflikt entstehen, behalte ich beide Versionen und führe sie anschließend auf dem Desktop mit KeePassXC zusammen.
Abschied von 1Password
Nachdem ich die importierten Daten überprüft, die Browserintegration eingerichtet, die Passkeys neu angelegt und die Synchronisation getestet hatte, konnte ich die 1Password-App von meinen mobilen Geräten löschen.
Anschließend kündigte ich mein Abonnement.
Damit spare ich jedes Jahr mehr als 50 Euro. Vor allem unterstütze ich kein Unternehmen mehr finanziell, dessen Förderentscheidung und Umgang mit Kritik ich nicht mittragen möchte.
1Password unter macOS deinstallieren
Wenn 1Password über Homebrew installiert wurde, lässt es sich mit folgendem Befehl entfernen:
brew uninstall --cask 1password
brew uninstall 1password-cli
Abhängig von der ursprünglichen Installation können die tatsächlichen Paketnamen abweichen. Mit brew list lässt sich vorab prüfen, welche Pakete installiert sind.
1Password unter Debian deinstallieren
Unter Debian entfernte ich die installierten Pakete sowie die Paketquellen und den zugehörigen Signaturschlüssel:
sudo apt purge 1password 1password-cli
sudo apt autoremove --purge
sudo rm -rf /opt/1Password/
sudo rm -f /etc/apt/sources.list.d/1password.list
sudo rm -f /etc/apt/sources.list.d/1password.sources
sudo rm -f /usr/share/keyrings/1password-archive-keyring.gpg
sudo apt update
Je nach Installationsweg sind möglicherweise nicht alle Dateien vorhanden. Die Befehle mit rm -f ignorieren fehlende Dateien, während rm -rf das angegebene Programmverzeichnis einschließlich seines Inhalts entfernt.
Fazit
Die Migration von 1Password zu KeePassXC und KeePassium war aufwändiger als der Wechsel zwischen zwei vollständig verwalteten Passwortdiensten. Besonders die Passkeys, die Schlüsseldatei und die Synchronisation über Git erforderten zusätzliche Planung.
Dafür liegt meine Passwortdatenbank nun in einem offenen Format vor. Ich kann die verwendeten Anwendungen, den Speicherort und den Synchronisationsweg unabhängig voneinander austauschen. Gleichzeitig verfüge ich über eine eigene Versionshistorie und kann voneinander abweichende Datenbankstände bei Bedarf zusammenführen.
Diese Lösung ist nicht für jeden Anwendungsfall ideal. Wer Passwörter im Team verwalten, Zugänge komfortabel teilen oder sich nicht selbst um Synchronisation und Backups kümmern möchte, ist mit einem zentral betriebenen Dienst wahrscheinlich besser beraten.
Für mich überwiegen jedoch die Vorteile: mehr Kontrolle, weniger Abhängigkeit und die Freiheit, einzelne Komponenten meiner Passwortverwaltung jederzeit ersetzen zu können.
Tags: