Da ich vorhin [Anmerkung: Dieses Posting entstand ursprünglich auf Facebook] in einem kleinen Posting erwähnt habe, dass ich mich in den letzten Tagen etwas mit Passwort-Management und Synchronisierung auseinander gesetzt habe, und ich gefragt wurde, wie meine Lösung aussieht, dachte ich, ich schreibe das mal als Notiz zusammen. Es wurde nämlich leider ein bisschen umfangreich für einen Kommentar zum Posting (und wird so in Zukunft auch leichter wieder gefunden, für alle, die es interessiert).
Zugegeben, mein Ansatz ist schon etwas nerdig. Aber mir war wichtig, dass ich verstehen kann, wie es funktioniert (und deshalb auch einschätzen kann, wie sicher das ist), dass es unabhängig von anderer Infrastruktur funktionieren kann und ich es dadurch selbst gut backupen kann.
Gelandet bin ich jetzt bei pass, dem sogenannten “standard UNIX password manager”, der tendenziell etwas jünger und bisher eben nicht so “standard” ist, sich inzwischen aber gewisser Beliebtheit erfreut.
Dieses Tool speichert die Passwörter in einzelnen Textdateien, die mir sehr große Flexibilität darüber erlauben, was ich da überhaupt speichern möchte. Neben Usernames und Passwörtern eben auch weitere Keys, Notizen, Pre-shared-Keys, PUKs, Wifi-Passwörter, Sicherheitsfragen und -antworten, usw. Und zwar aller Art, also nicht nur Passwörter für die Nutzung von Onlinediensten im Browser sondern eben auch sowas wie PINs, Kombinationen von Zahlenschlössern oder Fahrradrahmennummern.
Diese Dateien werden dann wiederum GPG-verschlüsselt, was wiederum den Vorteil hat, dass ich volle Kontrolle übers Schlüsselmanagement behalte. Das führt direkt dazu, dass ich auch mehrere Schlüssel einsetzen kann und einen davon auf einem NFC-fähigen Hardware-Token (Yubikey NEO) halten kann, das ich dann nämlich zusammen mit dem Smartphone benutzen kann, ohne dort einen Schlüssel vorhalten zu müssen. Es bedeutet aber auch, dass der Zugang zu meinen Passwörtern nicht von einer grafischen Oberfläche abhängt, sondern auf der Konsole sogar in eigene Skripte integriert werden kann.
Das Synchronisieren dieses Passwort-“Repositories” wiederum übernimmt einfach die Versionsverwaltung Git. Die zu benutzen ist einerseits zwar nicht trivial, wird aber von pass von vornherein so mitgedacht, dass es im Alltag eigentlich sehr, sehr einfach ist. Außerdem ist Git auf dem besten Wege, das Universalwerkzeug in meinem beruflichen Alltag zu werden. Es ist die wahrscheinlich beste Lösung für das sehr komplexe Problem des “Merging” von unterschiedlichen Versionsständen von verteilten Quellen, was das fundamental Schwierige bei jeder Art von Synchronisierung ist. Dank Git behalte ich auch hierbei die Kontrolle und muss keine Angst davor haben, dass beispielsweise der Synchronisierungsalgorithmus von Chrome völlig aussteigt und nur das Anlegen eines völlig neuen Profils das beheben konnte.
Für das eigene Hosting des Git-Repositiory nutze ich den hübschen kleinen Git-Server gitea, der beispielsweise auch wunderbar auf einem Raspberry Pi laufen kann. Dadurch weiß ich immer, wo meine Passwörter liegen, ich kann sie aber jederzeit (auch parallel) an völlig anderen Orten “geklont” haben und aktuell halten. Da empfiehlt sich vielleicht jetzt nicht ein öffentliches Github-Repository, aber theoretisch ginge auch das.
Für pass gibt es dann wiederum eine Android-Implementierung, die sich das GPG-Featureset von OpenKeychain zu Nutze macht und das Synchronisieren des Git-Repositories übernimmt. Mit dem Yubikey ist das Entschlüsseln dann trotzem immer noch ausreichend bequem und fühlt sich dadurch sicherer an auf dem Smartphone, als alles andere.
Die Nutzung im Browser wird durch eine sehr schöne Browsererweiterung namens Browserpass mit einer kleinen Companion-Software, die in Go geschrieben ist, umgesetzt. Obwohl letzteres ein sehr neues Projekt ist, macht es einen hervorragenden, soliden Eindruck und ist der Grund, weshalb ich jetzt auch tatsächlich auf pass umgestiegen bin, da Browserpass die für mich fehlende Schnittstelle in den von mir hauptsächlich genutzten Chromium-Browser war. Da gab es zuvor keine allzu solide Lösung.
Dieses gesamte Setup bringt allerdings natürlich ein paar Nachteile mit sich neben der Komplexität, dem dadurch entstehenden zeitlichen Aufwand und dem Verständnis, das man sich schon auch erarbeiten muss (ich glaube aber, dass das auch nicht-IT-Menschen sich ganz gut aneignen können!):
Einmal wäre das die Sichtbarkeit von Meta-Daten. Dadurch, dass für jedes Passwort eine eigene Datei im Repository angelegt wird, ist Ordnerstruktur und in meiner Struktur auch Benutzernamen (entspricht dem Dateinamen) völlig offen lesbar. Ich kann damit sehr gut leben, weil ich ansonsten der GPG-Verschlüsselung vertraue und natürlich meine Repositories privat halte (soll heißen: auf Geräten mit Full Disk Encryption). Man sollte sich dessen nur bewusst sein. KeePass verschlüsselt natürlich nur eine große Datei und dessen Inhalt ist komplett verborgen.
Der zweite Nachteil, der für viele andere sicherlich Relevanz hat: pass ist ein Unix-Werkzeug. Natürlich gibt es aufgrund seiner inzwischen vielen Fans auch verschiedene Implementierungen, die eine Nutzung unter Windows ermöglichen, den gleichen Workflow wird man dort jedoch wahrscheinlich nicht so ohne weiteres realisieren können, dafür lebt das zu sehr vom Zusammenspiel vieler Standard-Werkzeuge auf unixoiden Systemen. Menschen, die sich mit Dingen wie der UNIX-Umgebung für Windows Cygwin herumschlagen wird das sicherlich nicht abhalten, aber die wissen ja auch, was sie sich antun. Auf dem Mac wird es sicherlich aber gut funktionieren.
Das klingt jetzt alles schrecklich kompliziert und umfassend und ja, ich gebe zu, es hat mich auch zwei Tage gebraucht, das so aufzusetzen. Trotzdem fühlt es sich richtig an, da ich weiß, dass ich durch all diese offenen Standards jederzeit an jedes Passwort kommen werde und diese langfristig sicher sein werden. Kurz: für jeden Einzelaspekt des komplexen Problems “sichere Speicherung und Synchronisierung von Passwörtern über mehrere verteilte Endgeräte” wird das jeweils beste Werkzeug benutzt, das wir derzeit haben. Und jedes für sich wird in Zukunft weiter entwickelt werden. Dieses System ist mächtig, universell und funktional. Und besser bedienbar, als ich zunächst erwartet hätte.