Die passwortbasierte Authentifizierung bleibt trotz ihrer gut dokumentierten Sicherheitsherausforderungen die vorherrschende Methode für die Web-Authentifizierung. Benutzer stehen vor kognitiven Belastungen bei der Verwaltung mehrerer starker Passwörter, was zu Passwortwiederverwendung und der Erstellung schwacher Passwörter führt. Passwortmanager versprechen, diese Probleme durch die Generierung, Speicherung und automatische Ausfüllung von Passwörtern zu lindern. Ihre Sicherheit wurde jedoch durch frühere Forschung in Frage gestellt. Dieses Papier präsentiert eine aktualisierte, umfassende Sicherheitsbewertung von dreizehn beliebten browserbasierten Passwortmanagern, die den gesamten Lebenszyklus untersucht: Generierung, Speicherung und automatisches Ausfüllen.
Wir bewerteten dreizehn Passwortmanager, darunter fünf Browser-Erweiterungen (z.B. LastPass, Dashlane), sechs browserintegrierte Manager (z.B. Chrome, Firefox) und zwei Desktop-Clients zum Vergleich. Der Bewertungsrahmen umfasste drei Kernphasen: Analyse der Zufälligkeit von 147 Millionen generierten Passwörtern, Bewertung der Speichersicherheit (Verschlüsselung, Metadatenbehandlung, Standardeinstellungen) und Testen von Autofill-Schwachstellen gegen Angriffe wie Clickjacking und XSS.
Dieser Abschnitt beschreibt die erste groß angelegte Analyse von Passwortgenerierungsalgorithmen in Passwortmanagern.
Wir setzten statistische Tests für Zufälligkeit ein, einschließlich Häufigkeitsanalyse, Entropieberechnung und Tests auf Gleichverteilung über die definierten Zeichensätze (Großbuchstaben, Kleinbuchstaben, Ziffern, Sonderzeichen).
Mehrere Manager wiesen nicht-zufällige Zeichenverteilungen auf. Beispielsweise zeigten einige eine Tendenz zu bestimmten Zeichenpositionen oder -sätzen, wodurch die effektive Entropie der generierten Passwörter unter die theoretischen Erwartungen sank.
Eine bedeutende Erkenntnis war, dass eine Teilmenge der generierten Passwörter – insbesondere solche mit weniger als 10 Zeichen – anfällig für Online-Brute-Force-Angriffe war. Passwörter mit weniger als 18 Zeichen erwiesen sich unter Annahme moderner Hardwarefähigkeiten als potenziell anfällig für Offline-Angriffe.
In Anlehnung und Erweiterung früherer Arbeiten von Li et al. bewerteten wir, wie Passwörter lokal und in der Cloud verschlüsselt und gespeichert werden.
Während die meisten Manager starke Verschlüsselung (z.B. AES-256) verwenden, variierten Schlüsselableitungsfunktionen und Schlüsselspeichermechanismen, wobei einige Implementierungen schwächer waren als andere.
Ein kritischer festgestellter Fehler war die Speicherung sensibler Metadaten (z.B. Website-URLs, Benutzernamen) im Klartext oder mit unzureichendem Schutz, was ein Datenschutzrisiko darstellt, selbst wenn das Passwort selbst verschlüsselt ist.
Mehrere Passwortmanager hatten unsichere Standardeinstellungen, wie das Aktivieren des automatischen Autofills oder das Nicht-Erfordern des Master-Passworts nach einem Browser-Neustart, was die Angriffsfläche vergrößert.
Autofill, obwohl bequem, führt signifikante Angriffsvektoren ein. Wir testeten gegen bekannte Angriffsklassen.
Wir fanden heraus, dass mehrere Manager anfällig für Clickjacking-Angriffe blieben, bei denen eine bösartige Site unsichtbare Elemente über legitime UI-Schaltflächen legt, um Benutzer dazu zu bringen, das automatische Ausfüllen in einem vom Angreifer kontrollierten Feld auszulösen.
Wenn eine Website eine XSS-Schwachstelle hat, könnte ein injiziertes Skript potenziell mit den DOM-Elementen des Passwortmanagers interagieren, um Anmeldedaten abzugreifen – ein Risiko, das bereits in früheren Arbeiten von Stock und Johns hervorgehoben wurde.
Manager, die mit Cloud-Diensten für Synchronisierung oder Funktionen kommunizieren, wurden auf Anfälligkeit für Man-in-the-Middle-Angriffe getestet, die bösartigen Code injizieren oder Authentifizierungstoken stehlen könnten.
Insgesamt hat sich die Sicherheit im Vergleich zu Bewertungen von vor fünf Jahren verbessert, aber erhebliche Probleme bestehen fort. Kein einzelner Manager war in allen drei Kategorien (Generierung, Speicherung, Autofill) fehlerfrei. Browserintegrierte Manager hatten oft eine einfachere, sicherere Autofill-Logik, aber schwächere Generierungsalgorithmen. Drittanbieter-Erweiterungen boten mehr Funktionen, führten aber zu größerer Komplexität und Angriffsfläche. Wir identifizieren spezifische Manager, die schlecht abschnitten und von sicherheitsbewussten Benutzern gemieden werden sollten.
13
147M+
4
Für Benutzer: Wählen Sie Manager mit einer starken Sicherheitsbilanz, aktivieren Sie alle verfügbaren Sicherheitsfunktionen (wie 2FA) und seien Sie vorsichtig mit Autofill. Für Entwickler: Implementieren Sie kryptografisch sichere Zufallszahlengeneratoren (CSPRNGs) für die Passwortgenerierung, verschlüsseln Sie alle Metadaten, übernehmen Sie sichere Standardeinstellungen (z.B. Master-Passwort immer erforderlich) und härten Sie Autofill gegen UI-Manipulation ab. Für Forscher: Untersuchen Sie den Usability-Security-Kompromiss von Autofill, entwickeln Sie standardisierte Sicherheitsbewertungsrahmen und erforschen Sie Post-Quanten-Kryptografie für Zukunftssicherheit.
Kernerkenntnis: Die Studie von Oesch und Ruoti liefert eine ernüchternde Realitätsprüfung: Die Werkzeuge, die entwickelt wurden, um die Passwortkrise zu lösen, sind selbst ein Flickenteppich von Schwachstellen. Der Fokus der Branche auf Bequemlichkeit und Funktionsüberfrachtung hat in mehreren Fällen die Kernversprechen in puncto Sicherheit direkt untergraben. Die Erkenntnis, dass generierte Passwörter schwach sein können, ist besonders vernichtend – sie trifft den Kern des Wertversprechens des Passwortmanagers.
Logischer Ablauf: Das Papier strukturiert seinen Angriff brillant entlang der Benutzerreise: Erstellung (Generierung), im Ruhezustand (Speicherung) und in Benutzung (Autofill). Dieser Lebenszyklus-Ansatz, der an Bedrohungsmodellierung in Frameworks wie Microsofts STRIDE erinnert, zeigt, dass Schwächen nicht isoliert, sondern systemisch sind. Ein Fehler in der Generierung reduziert die Wirksamkeit einer starken Speicherung; ein Fehler im Autofill macht beides zunichte. Diese Vernetzung wird bei punktuellen Audits oft übersehen.
Stärken & Schwächen: Die Stärke der Studie liegt in ihrer Umfassendheit und der Replikation früherer Arbeiten, was einen seltenen Längsschnittblick auf die Sicherheitsentwicklung bietet. Der massive Korpus von 147 Millionen generierten Passwörtern zur Analyse ist lobenswert. Die Analyse hat jedoch einen Fehler, der vielen Sicherheitsbewertungen gemein ist: Es handelt sich weitgehend um einen Black-Box-Funktionstest. Sie identifiziert, was kaputt ist, gibt aber weniger Einblick in das Warum aus einer Software-Engineering-Perspektive – waren diese Fehler auf übereilte Fristen, missverstandene Spezifikationen oder einen Mangel an Sicherheitsüberprüfung zurückzuführen? Darüber hinaus hätte, obwohl auf die NIST Digital Identity Guidelines verwiesen wird, ein tieferer Einblick, wie diese Manager mit Standards wie FIPS 140-3 oder den Sicherheitsanforderungen in den IETF-Password Authenticated Key Exchange (PAKE)-Vorschlägen übereinstimmen (oder nicht), erhebliches Gewicht hinzugefügt.
Umsetzbare Erkenntnisse: Für Enterprise-Sicherheitsteams ist dieses Papier ein Auftrag, genehmigte Passwortmanager rigoros zu prüfen. Sich auf den Markenruf zu verlassen, reicht nicht aus. Beschaffungs-Checklisten müssen spezifische Tests für Generierungszufälligkeit (z.B. mit standardisierten Testsuites wie Dieharder oder NISTs STS), Metadatenverschlüsselung und Autofill-Verhalten unter Angriffssimulationen enthalten. Für Entwickler lautet die Lehre, Einfachheit und sichere Standardeinstellungen zu priorisieren. Der sicherste Autofill-Mechanismus könnte der einfachste sein: ein manuelles „Klicken zum Ausfüllen“, das eine explizite, bewusste Benutzeraktion erfordert, wie von der University of California, Berkeley in der Forschung zu explicit consent interfaces vorgeschlagen. Die Zukunft liegt nicht darin, intelligentes, automatisches Ausfüllen perfekt sicher zu machen, sondern darin, minimal invasive, aber maximal explizite Benutzerinteraktionen zu gestalten, die den Menschen bei kritischen Sicherheitsentscheidungen im Prozess halten.
Die Bewertung der Zufälligkeit der Passwortgenerierung stützte sich auf die Berechnung der Shannon-Entropie $H$ der generierten Passwörter:
$H = -\sum_{i=1}^{n} P(x_i) \log_2 P(x_i)$
wobei $P(x_i)$ die Wahrscheinlichkeit ist, dass das Zeichen $x_i$ an einer gegebenen Position erscheint. Für eine wirklich zufällige Auswahl aus einem Satz von $C$ Zeichen ist die maximale Entropie pro Zeichen $\log_2(C)$. Für einen 72-Zeichen-Satz (26 Kleinbuchstaben + 26 Großbuchstaben + 10 Ziffern + 10 Sonderzeichen) ist max $H_{char} \approx 6,17$ Bits. Ein 10-stelliges Passwort hat somit ein theoretisches Maximum von ~61,7 Bits Entropie.
Die Studie ergab, dass Verzerrungen in den Algorithmen einiger Manager die effektive Entropie reduzierten. Die Anfälligkeit für Offline-Angriffe wurde unter Verwendung einer geschätzten Crack-Rate $R$ (Hashes pro Sekunde) und des Passwortraums $N$ bewertet:
$\text{Zeit zum Knacken} \approx \frac{N}{2 \times R}$
Unter der Annahme einer High-End-Rate von $10^{10}$ Hashes/Sekunde (im Bereich moderner GPU-Cluster) könnte ein Passwort mit weniger als ~65 Bits Entropie ($N = 2^{65}$) für einen motivierten Angreifer in einem machbaren Zeitrahmen geknackt werden.
Wichtige Grafik 1: Verzerrung der Zeichenverteilung. Ein Balkendiagramm, das die beobachtete vs. erwartete Häufigkeit von Zeichentypen (Großbuchstaben, Kleinbuchstaben, Ziffern, Sonderzeichen) über mehrere Passwortmanager vergleicht. Mehrere Manager zeigten eine statistisch signifikante Abweichung (p < 0,01) von der erwarteten Gleichverteilung, mit einer Überrepräsentation von Ziffern an bestimmten Positionen.
Wichtige Grafik 2: Entropie vs. Passwortlänge. Ein Streudiagramm, das die gemessene Entropie pro Manager für verschiedene konfigurierte Passwortlängen (8, 12, 16, 20 Zeichen) zeigt. Die Grafik würde zeigen, dass die meisten Manager sich für längere Passwörter der theoretischen Entropielinie annähern, mehrere jedoch für kürzere Längen (8-12 Zeichen) darunter bleiben, was auf eine schwächere Zufälligkeit hindeutet.
Wichtige Grafik 3: Autofill-Schwachstellen-Matrix. Eine Heatmap mit Managern auf der Y-Achse und Schwachstellenklassen (Clickjacking, XSS-Leakage, Netzwerkinjektion) auf der X-Achse. Zellen sind grün (nicht anfällig), gelb (teilweise/variabel anfällig) und rot (anfällig) eingefärbt. Diese Visualisierung zeigt klar, welche Manager über die Autofill-Angriffsfläche hinweg am riskantesten sind.
Fall: Bewertung der Autofill-Sicherheit von „Manager X“.
Schritt 1 - Feature-Mapping: Dokumentieren Sie, wie Manager X Autofill auslöst: Füllt er automatisch aus? Zeigt er ein Dropdown-Menü? Auf welche DOM-Attribute verlässt er sich (id, name, class, placeholder)?
Schritt 2 - Bedrohungsmodellierung: Wenden Sie das STRIDE-Modell an.
Schritt 3 - Testausführung: Erstellen Sie eine Test-Harness-Webseite, die systematisch jeden Bedrohungsvektor ausprobiert. Für Clickjacking erstellen Sie überlappende transparente Elemente. Für XSS simulieren Sie ein Skript, das die `value`-Eigenschaft ausgefüllter Felder ausliest.
Schritt 4 - Analyse & Bewertung: Bewerten Sie jede Schwachstelle basierend auf Wahrscheinlichkeit und Auswirkung (z.B. mit DREAD-Scoring). Der aggregierte Score bestimmt die Gesamt-Autofill-Sicherheitsbewertung für Manager X.
Dieser strukturierte Ansatz geht über Ad-hoc-Tests hinaus und gewährleistet eine umfassende Abdeckung.
1. Integration mit WebAuthn/Passkeys: Die Zukunft ist passwortlos. Die nächste Evolution für Passwortmanager besteht darin, primäre Broker für Passkeys (basierend auf der W3C Web Authentication API) zu werden. Forschung ist erforderlich zur sicheren Synchronisierung und Wiederherstellung von Passkey-Private Keys über Geräte hinweg – eine Herausforderung, die von der FIDO Alliance hervorgehoben wurde.
2. Kontextbewusstes, risikobasiertes Autofill: Anstelle einer binären Füllen/Nicht-Füllen-Logik könnten zukünftige Manager maschinelles Lernen nutzen, um die Legitimität einer Seite zu bewerten (Überprüfung von Domain-Alter, SSL-Zertifikat, Reputations-Scores) und den Benutzerkontext (typische Login-Zeit, Gerät), um das Autofill-Verhalten anzupassen und für Hochrisikoszenarien zusätzliche Authentifizierung zu verlangen.
3. Formale Verifikation & sichere Hardware: Kritische Komponenten, insbesondere der Zufallszahlengenerator und die Kern-Verschlüsselungs-/Entschlüsselungsroutinen, könnten mit Werkzeugen wie Coq oder Tamarin Prover formal verifiziert werden. Die Integration mit Trusted Platform Modules (TPMs) oder Secure Enclaves für die Schlüsselspeicherung könnte die Sicherheit für hochwertige Ziele erhöhen.
4. Dezentrale & benutzerzentrierte Architekturen: Der Weggang von zentralisierten Cloud-Tresoren hin zu dezentralen Protokollen (z.B. basierend auf Secure Multi-Party Computation oder persönlichen Servern) könnte die Risiken groß angelegter Anbieterverletzungen mindern. Dies steht im Einklang mit der breiteren „Solid“-Projektvision für persönliche Data Pods.