Privater Passwortmanager für Admins – was man beachten sollte

Wie bei allen anderen Themen gilt auch beim Thema Passwortmanager: Jeder hat die Weisheit mit dem Löffel gefressen und weiss es besser. Daher versuche ich mit diesem Blog Artikel „nur“ ein paar Denkanstösse für die freie eigene Wahl mitzugeben.

Im Ernst, das Problem fängt schon bei dem Namen „Passwortmanager“ an. Grundsätzlich sind die gängigsten Lösungen nur ein Passwortspeicher. Diese sind nicht fähig, die Passwörter zu verwalten. Bedeutet, die Passwörter können nach Benutzung nicht automatisch rotiert (geändert) werden. Daher ist der Name Passwortmanager grundsätzlich irreführend. Ich nenn‘ ein Beispiel: Beim eigenen File-(Cloud-)Speicher, kann man wie beim Passwortspeicher auch Freigaben erstellen. Aber deswegen nennt sich der File-(Cloud-)Speicher ja auch nicht File-(Cloud-)Manager…

Eine pfannenfertige Cloud-Lösung ist immer attraktiv. Oft kann man sie nach wenigen Minuten Einrichtungszeit von überall nutzen. Eine solche Cloud-Lösung ist natürlich auch für Bad Actors 24/7 erreichbar. Im Falle vom letzten LastPass Hack wurden unter anderem die Kunden Tresore, also die verschlüsselten Container, welche die Secrets beinhalten, entwendet. Zwar seien die Tresore sicher mit dem Masterpasswort der jeweiligen Kunden verschlüsselt, aber die Angreifer können nun offline in aller Ruhe die Tresore mit Brut Force oder anderen Attacken (versuchen zu) knacken. Dies ist nur eine Frage des Geldes oder der Zeit.

Die Secrets gehören zu unseren schützenswertesten Informationen, die wir im digitalen Bereich besitzen. Aus diesem Grund kann es sinnvoll sein, auf eine Lösung zu setzen, die nicht 24/7 für alle erreichbar ist. Wer Kryptowährungen besitzt, der setzt genau aus diesem Grund auf sogenannte Cold Wallets, die sogar bis zu 100% von der digitalen Welt abgetrennt sind.

Es gibt Passwortspeicher-Lösungen, die ihre Secrets in einem verschlüsselten Container File abspeichern. Wenn man dieses File bei OneDrive oder co. speichert, kann man somit geräteübergreifend auf die eigenen Secrets zugreifen. Dadurch kreiert man die Gefahr, dass durch die gleichzeitige Nutzung eines Container Files ein Replikationsproblem entstehen kann. Im Schlimmsten Fall wird das Container File irreparabel.

Eine Alternative dazu bieten Passwortserver Lösungen an. Die Apps der Passwortserver-Lösungen greifen nicht direkt auf das Container File zu. Diese nutzen eine definierte Schnittstelle zum Passwortserver. Der Server wiederum ist die alleinige Instanz, welche die Secrets sicher im Container oder in der Datenbank ablegt.

Wer einen On-Premise Passwortserver nutzt und unterwegs auf die gespeicherten Secrets zugreifen möchte, kann sich per VPN oder mit einer Offline-Kopie aushelfen. Bei letzterer Variante speichert beispielsweise die Smartphone App eine Offline-Kopie des Tresors auf dem Gerät ab. Hier ein paar Gedanken zu den beiden Varianten:

VPN

• • Setze auf eine physische Firewall, keine softwarebasierte Lösung
  • Achte auf sichere Algorithmen
  • VPN nur mit 2FA

Offline-Kopie

• • Oft hat man offline nur Leserechte. Es können keine Anpassungen oder neue Einträge erstellt werden.
  • Meines Wissens wird die Offline-Kopie nur softwarebasiert auf dem Gerät geschützt.
  • Die Offline-Kopien haben aus Security Gründen oft eine maximale Lebensdauer.

Passwortmanager können oft auch den Seed des OTPs speichern. Somit kann der erste Faktor (Benutzername und Passwort) sowie auch der zweite Faktor (Seed des OTPs) gespeichert werden. Bei Bedarf füllen die Passwortmanager oft beide Faktoren bei der Web Anmeldung automatisch ein. Wie praktisch…

Nur, dass dies ursprünglich nicht so gedacht war. Es gibt drei Arten von Faktoren:

• • Wissen (Benutzername und Passwort)
  • Haben (Smart Card oder Seed des OTPs)
  • Sein (Fingerabdruck, FaceID)

Man spricht von Two Factor Authentication (2FA) oder von Multifactor Authentication (MFA), wenn zwei oder mehrere unterschiedliche Faktoren für eine Anmeldung benutzt werden. Die Faktoren sollten auch voneinander getrennt sein. Smart Card Anmeldung ist an dieser Stelle ein gutes Beispiel. Ich besitze die Smart Card (Haben) und kenne den PIN (Wissen). Wenn man beim eigenen Passwortmanager Benutzername und Passwort sowie den Seed des OTPs gespeichert hat, dann ist dies für mich beides «Haben». Ich kenne die Passwörter in meinem Passwortmanager nicht mehr. Ich habe beide Faktoren in meinem Passwortmanager. Zudem habe ich die Trennung von den beiden Faktoren nicht mehr. Wenn meine Smart Card gestohlen wird, dann hat der „neue Besitzer“ zwar meine Smart Card, aber er kennt den dazugehörigen PIN nicht. Wenn hingegen ein Angreifer Zugang zu meinem Passwortmanager hat, dann ist er im Besitz (Haben) von beiden Faktoren. Ergo, der zweite Faktor sollte getrennt aufbewahrt werden.

Kommen wir nun zum Lieblingsthema. *sarkasm off*
Auch wenn es kein sexy Thema ist und oft vernachlässigt wird. (Ich spreche von Erfahrung.) Sollte bei jeder On-Premise Lösung wie auch bei der besten super-duper Cloud Lösung an eine eigene On-Premise Recovery Strategie gedacht werden. Das Backup sollte im besten Fall so erstellt werden, dass die Secrets auch bei einer anderen Lösung importiert werden können.

Nun zu meiner knallharten Meinung:
Bei kommerziellen Passwordspeicher-Lösungen kann man entscheiden, ob man mit Geld oder mit seinen Daten bezahlen möchte. Bei Lastpass konnte man in der Vergangenheit sogar mit beidem kombiniert bezahlen. Siehe hier (LastPass kommt in diesem Artikel irgendwie nicht gut weg. Sorry LastPass.) Dieses Beispiel zeigt mir, dass Closed Codes auch bei Passwordspeicher-Lösungen keine gute Idee sind. Bei Open-Source-Lösungen gibt’s immerhin die Chance, dass die Community den Code validieren kann. Bedeutet nicht, dass jeder Open Source Code gut ist. Aber es besteht die Chance einer externen Kontrolle. Cloud ist nicht per se böse, aber meine Secrets möchte ich nicht 24/7 zum Angriff zur Verfügung stellen. Daher gilt für mich, On-Premise, nicht vom Internet (direkt) erreichbar und Open Source.