Sicherheit
Beweisen Sie, dass Ihr Browser kein Tresor ist.
Chrome und Firefox speichern Ihre Passwörter und übergeben sie dann an jedes Programm, das als Sie ausgeführt wird. Das ist kein Fehler. Das ist das Design. Hier ist der Beweis: einmal in einfacher Sprache, einmal im Code.
Die Version in einfacher Sprache
Der "Passwort-Manager" Ihres Browsers wird durch genau ein Schloss geschützt: Ihre Computeranmeldung. Sobald Sie sich bei Ihrem Laptop angemeldet haben, kann der Browser sofort jedes gespeicherte Passwort lesen – und damit auch alles andere, was auf Ihrem Konto läuft.
Ein schlechter Download. Ein zwielichtiges Browser-Spiel. Ein vergiftetes Paket in einem Projekt, das Sie geklont haben. In dem Moment, in dem es ausgeführt wird – während Sie angemeldet sind, wie Sie es immer sind – liest es jedes Passwort, das Ihr Browser gespeichert hat, in der Zeit, die zum Öffnen einer Datei benötigt wird. Es gibt kein Master-Passwort zu knacken, weil nichts zu knacken da ist: Der Browser wurde entwickelt, um sich automatisch für Sie zu entsperren, und die Malware bittet einfach nett als "Sie".
Das ist nicht theoretisch. Es ist die häufigste Methode, mit der normale Menschen ihre Konten verlieren. Die Malware hat sogar einen langweiligen Branchennamen – "Info-Diebe" – weil sie so routinemäßig ist. Ihre Passwörter, Ihre gespeicherten Karten, Ihre Sitzungscookies: kopiert und weg, bevor Sie es bemerken.
Die Lösung ist einfach zu formulieren: Ihre Passwörter sollten mit etwas gesperrt werden, das der Rest Ihres Computers nicht hat – und sie sollten überhaupt nicht auf dem Rechner liegen.
Die Version mit Belegen
Glauben Sie uns nicht einfach. Chromium und Firefox sind Open Source, und der Lesepfad ist dokumentiert, Standard und kurz. Hier erfahren Sie genau, wo sich die Passwörter befinden und wie sie abgerufen werden.
Chrome (und jeder Chromium-Browser)
Chrome speichert Anmeldungen in einer SQLite-Datenbank – Login Data, Tabelle logins, Spalte password_value – verschlüsselt mit AES-256-GCM. Der AES-Schlüssel befindet sich in Local State und wird vom Betriebssystem "geschützt": DPAPI unter Windows, der Anmeldeschlüsselbund (Keychain) unter macOS, gnome-keyring/kwallet (oder Klartext) unter Linux.
Lesen Sie es selbst – der Code ist offen. Suchen Sie in Chromium nach der Konstante, die den verschlüsselten Schlüssel kennzeichnet: kDPAPIKeyPrefix in os_crypt. Der Schlüssel ist DPAPI-verschlüsselt, gekennzeichnet und gespeichert – und wird dann mit einem einzigen Aufruf entschlüsselt, der nichts vor Ihnen schützt:
const char kDPAPIKeyPrefix[] = "DPAPI";
CryptUnprotectData(&intermediate, /*ppszDataDescr=*/nullptr,
/*pOptionalEntropy=*/nullptr, nullptr, nullptr, 0, &output);Kein zweites Geheimnis, kein Passwort, keine Aufforderung. CryptUnprotectData gibt den Schlüssel an jeden Prozess zurück, der in Ihrer Sitzung läuft – was genau dem Bedrohungsmodell entspricht, das DPAPI dokumentiert: Wenn es als Sie läuft, sind Sie es. Die gesamte Aufgabe des Angreifers besteht aus drei Zeilen: Lesen Sie den Schlüssel aus Local State, entschlüsseln Sie ihn, entschlüsseln Sie jede Zeile in Login Data mit AES-GCM. Info-Diebstahl-Malware tut dies seit Jahren genau so.
"On-Device-Verschlüsselung" rettet Sie auch nicht
Googles Antwort ist eine 6-stellige PIN, die Ihren synchronisierten Tresor verschlüsselt. Im Mai 2026 zeigten Forscher von Phishu, wie dünn das ist. Eine überzeugende gefälschte Google-Anmeldung – ein Adversary-in-the-Middle-Phishing – erfasst die Sitzung und diese PIN, und die PIN ist der Masterschlüssel zu jedem Passwort und jedem Passkey im synchronisierten Konto. Damit kann ein Angreifer sein eigenes Gerät zu Ihrer Google "Sicherheitsdomäne" hinzufügen, und der gesamte Tresor wird direkt zu ihm synchronisiert – vollständige Übernahme in einem Schritt.
Der Designfehler: Google erlaubt einem Gerät, sich allein mit der 6-stelligen PIN anzumelden, ohne Zustimmung eines Geräts, das Sie bereits besitzen.
Firefox
Firefox speichert Anmeldungen in logins.json und den Schlüssel in key4.db, entschlüsselt durch den "Secret Decoder Ring" von NSS – ebenfalls Open Source: security/nss/lib/pk11wrap/pk11sdr.c. Wenn Sie ein Primary Password festlegen, wird der Schlüssel damit versiegelt.
Standardmäßig haben Sie das nicht getan – daher ist der Schlüssel mit dem leeren String versiegelt, und ein gespeicherter "password-check"-Wert bestätigt, dass das leere Passwort ihn entschlüsselt. Kopieren Sie zwei Dateien aus Ihrem Profil (key4.db + logins.json), richten Sie NSS oder das Open-Source-Tool firepwd.py darauf aus, und sie werden entschlüsselt. Ein Schloss, dessen Schlüssel an der Tür klebt, ist kein Schloss.
Jeder Browser-Passwortspeicher hat die gleiche Struktur: Das Geheimnis lebt dort, wo Sie arbeiten, entsperrt durch die Sitzung, in der Sie sich bereits befinden. Eine Verschlüsselung, die der Rest Ihres eigenen Computers rückgängig machen kann, schützt Sie nicht vor der Bedrohung, die tatsächlich Konten leert – Code, der als Sie ausgeführt wird.
Warum Clavitor auf diese Weise nicht gelesen werden kann
Clavitor speichert Ihren Tresor nicht auf dem Rechner. Es gibt keine Login Data, keine key4.db, keinen Schlüssel in Local State – nichts auf der Festplatte, das ein Prozess, der als Sie ausgeführt wird, auslesen könnte.
Der Entschlüsselungsschlüssel ist nicht mit Ihrer OS-Anmeldung versiegelt. Er wird aus einem Hardware-Tap abgeleitet – Touch ID, Face oder ein YubiKey – im Browser berechnet, für eine einzelne Anfrage verwendet und dann verworfen. Anmeldedaten werden über eine bereichsbeschränkte API abgerufen, genau dann, wenn Sie sie anfordern, und niemals zwischengespeichert. Malware, die als Sie ausgeführt wird, findet einen leeren Schrank vor.
Das ist der Unterschied zwischen "auf Ihrem Gerät verschlüsselt" und "überhaupt nicht auf Ihrem Gerät".
Hören Sie auf, dem Browser Ihre Passwörter anzuvertrauen.
Die Clavitor-Erweiterung füllt wie Ihr Browser aus – und bewahrt den Tresor an einem Ort auf, den Ihr Laptop nicht lesen kann.