Warum AES-256-GCM bei gespeicherten Browser-Passwörtern nicht bedeutet, dass ein Programm auf diesem Rechner sie nicht lesen kann

Was die Suche eigentlich fragt

Wer „sind gespeicherte Chrome-Passwörter verschlüsselt, sodass Malware sie nicht sieht“ sucht, fragt meist eine Sache: Nachdem ich auf Speichern geklickt habe, kann ein anderes Programm auf diesem Rechner den Klartext noch wiederherstellen? Der Algorithmusname entscheidet das nicht. Im Google-Sicherheitsblog beschreibt Will Harris vom Chrome-Sicherheitsteam die ältere Windows-Grenze in klaren Sätzen. Chrome schützt vertrauliche Daten wie Cookies und Passwörter mit der stärksten Einrichtung, die das Betriebssystem anbietet. Unter Windows ist das die Data Protection API (DPAPI). Sie schützt Daten im Ruhezustand vor anderen Benutzern auf dem System und vor Kaltstart-Angriffen. Eine schädliche Anwendung, die unter dem angemeldeten Benutzer läuft, fällt nicht unter diesen Schutz. Genau diese Lücke nutzen Infostealer.

Diese Notiz ist für zwei Leser. Der eine ist Entwickler oder Betreiber und prüft einen Satz wie „der Browser verschlüsselt gespeicherte Passwörter schon, also müssen wir Passwörter auf der Platte nicht mehr bedenken“. Der andere hat diese Woche einen Sicherheitsbericht gelesen und will wissen, was das Wort „verschlüsselt“ auf einer Einstellungsseite tatsächlich belegt. Die Notiz erklärt nicht, wie man den Passwortspeicher einer anderen Person auspackt, und sie ersetzt nicht die Seite des Passwort-Generators. Mitnehmen sollten Sie drei Fakten, die sich trennen lassen: was Chiffretext belegt, was die Schlüsselverpackung belegt, und was der Bericht vom 25. September 2026 nicht belegt.

AES-256-GCM zeigt nur, dass das Feld kein Klartext ist

Chromium-Browser halten gespeicherte Anmeldungen im lokalen Profil. In neueren Versionen ist das Passwortfeld mit AES-256-GCM versiegelt. Öffnen Sie diesen Speicher in einem Texteditor, sehen Sie das Website-Passwort nicht im Klartext. Dieser Teil stimmt. GCM heißt außerdem: Ein verändertes Byte besteht die Integritätsprüfung nicht. Der Chiffretext ist keine Klartextzeile, die sich still an Ort und Stelle umschreiben lässt.

Der Browser muss das Passwort beim nächsten Login-Formular trotzdem wieder einsetzen. Der Schlüssel kann deshalb nicht nur in einer Passphrase leben, die allein Sie im Kopf haben. Nach dem Entsperren der Sitzung muss der Browser auf diesem Rechner ihn benutzen können. Die nützliche Frage wandert deshalb von „ist der Algorithmus stark?“ zu „wer darf das System nach diesem Schlüssel fragen?“. Ein starker Algorithmus verschiebt die Tür nicht. Liegt das Recht zum Auspacken bei „dem Windows-Benutzer, der schon angemeldet ist“, steht ein Programm, das als dieser Benutzer gestartet wurde, auf derselben Seite der Tür wie der Browser.

Deshalb ist derselbe Algorithmusname ein anderer Satz als „lokale Verschlüsselung unter einer Passphrase, die Sie eintippen“. Verschlüsseln Sie eine Datei im Browser mit AES-256-GCM und einer Passphrase, die Sie halten, haben ein anderes Programm und ein Cloud-Laufwerk diese Passphrase standardmäßig nicht. Sie können die Datei nicht öffnen. Ein Browser-Passwortspeicher ist für das automatische Ausfüllen gebaut. Das Recht, den Schlüssel zu benutzen, muss beim Browser auf diesem Rechner bleiben. AES-256-GCM an beiden Stellen macht aus zwei Schlüssel-Zuordnungen nicht dieselbe Zuordnung.

Die Grenze, die Google schon aufgeschrieben hat

Dieselbe Notiz vom 30. Juli 2024 schreibt die Aufteilung nach Betriebssystem aus. macOS nutzt die Schlüsselbund-Dienste. Linux nutzt eine System-Wallet wie kwallet oder gnome-libsecret. Windows nutzt DPAPI. Der Satz über „ein Programm, das als angemeldeter Benutzer läuft“ ist Googles Beschreibung der Windows-DPAPI. Übertragen Sie ihn nicht auf jeden Mac. Der Schlüsselbund kann eine Systembestätigung einblenden. Diese Interaktion ist eine andere Tür als „jeder Prozess dieses Benutzers packt das Geheimnis ohne Rückfrage aus“.

Unter Windows bindet DPAPI den Schutz an die Anmeldung dieses Benutzers. Die Fälle, die Google nennt, sind andere Benutzer auf dem System und Kaltstart-Angriffe. Das ist die Hälfte von „es ist verschlüsselt“, die in einer Produktprüfung standhält. Die andere Hälfte schreibt Google direkt: DPAPI schützt nicht vor einer schädlichen Anwendung, die unter dem angemeldeten Benutzer läuft. Dieses Programm kann das Betriebssystem über dieselbe Art von Schnittstelle fragen, die der Browser nutzt. Der Algorithmus ist nicht gebrochen. Die Tür war um andere Benutzer und Kaltstart-Angriffe gezogen, nicht um andere Prozesse dieses Benutzers.

Wenn eine Prüfung sagt „der Passwortspeicher nutzt AES-256-GCM, also kann lokale Schadsoftware ihn nicht lesen“, teilen Sie den Satz. Die erste Hälfte lässt sich stützen, indem Sie den Speicher öffnen und sehen, dass das Passwortfeld kein Klartext ist. In der DPAPI-Generation widerspricht die zweite Hälfte Googles öffentlicher Notiz. Der Beleg, den Sie noch brauchen, ist, ob dieser Browser diese Klasse von Geheimnissen zur nächsten Tür verschoben hat. Der Algorithmusname ist dieser Beleg nicht.

Chrome 127 schiebt die Tür vom Benutzer zur App

Dieselbe Notiz geht weiter: Chrome 127 führt unter Windows App-Bound Encryption ein, die anwendungsgebundene Verschlüsselung. Die Daten stehen nicht mehr jeder App zur Verfügung, die als angemeldeter Benutzer läuft. Chrome verschlüsselt sie gebunden an die Identität der Anwendung, und eine Komponente auf Systemseite prüft, dass der Aufrufer ein vertrauenswürdiger Browser ist, bevor sie den Schlüssel herausgibt. Die Migrationsreihenfolge von Google ist ausdrücklich. Zuerst wandern Cookies, in Chrome 127. Passwörter, Zahlungsdaten und andere dauerhafte Anmeldetoken sind Geheimnisse, auf die das Team in späteren Versionen ausweiten wollte. Sie waren am Tag, an dem 127 erschien, nicht als vollständig umgezogen beschrieben.

Anfang 2026 ziehen öffentliche forensische Beschreibungen dieselbe Linie. Die Notiz von ElcomSoft vom Januar 2026 sagt, App-Bound Encryption habe bei Cookies begonnen, mit einer Architektur, die auf Passwörter und Zahlungsdaten erweitert werden soll, und Microsoft Edge sei gefolgt, weil es den Chromium-Kern teilt. In Profilen, in denen die neue Verpackung wirklich in Gebrauch ist, scheitert ein fremdes Programm, das als der Benutzer läuft, wenn es das Betriebssystem auf die alte Weise fragt: Der Aufrufer ist nicht das geprüfte Browser-Programm. Diese Tür hält einen gewöhnlichen Prozess auf, der außerhalb des Browsers steht. Sie hält das Innere des Browser-Prozesses nicht auf. Eine schädliche Erweiterung, oder anderer Code, der in diesem Prozess schon läuft, steht weiter innen. App-Bound Encryption ändert, wer aufrufen darf. Sie heißt nicht: Sobald das Feld AES-256-GCM ist, kann die Ausfülllogik im Speicher das Passwort nicht sehen.

Zwei Sätze werden ständig vertauscht, und sie beantworten verschiedene Fragen. „Mein Chrome ist neuer als 127, also ist jedes gespeicherte Passwort umgezogen“ behandelt eine Versionsnummer als Migrationsbeleg. Im Juli 2024 hat Google Passwörter als spätere Ausweitung geführt. Eine Build-Nummer 130, 140 oder höher zeigt nur, dass der Browser hinter dem Startpunkt für Cookies liegt. „Jemand kann Passwörter noch mit dem alten Benutzer-Auspacken lesen, also tut App-Bound Encryption nichts“ ist die andere Übertreibung. Diese Beobachtung zeigt, dass manche Profile oder manche Zeilen noch an der älteren Tür stehen, oder dass die Beschreibung die ältere Tür meint. Sie zeigt nicht, dass die neue Tür öffentlich als gescheitert abgeschrieben wurde.

Was der Bericht vom 25. September tragen kann

Am 25. September 2026 hat Deepa B bei K7 Labs eine Analyse eines Windows-Programms veröffentlicht, das aus einem Python-Baukasten für Malware-as-a-Service gebaut wird. Sicherheitsberichte haben sie in den folgenden Tagen wiederholt. Die Nutzlast sucht Benutzerdatenordner von 17 Chromium-Browsern und liest gespeicherte Passwörter, Zahlungskarten, Browserverlauf und Sitzungs-Cookies. Sie liest außerdem Verlauf und Cookies von Firefox. Der Satz über AES-256-GCM bei Chromium beschreibt deshalb nicht jeden Browser auf dem Rechner. Für Chromium-Anmeldungen sagt K7, neuere Passwortfelder würden mit AES-256-GCM gespeichert, und der Schlüssel werde über den benutzerbezogenen Datenschutz von Windows geholt, mit einem Rückfall auf die ältere Schutzmethode. K7 stellt klar, dass das Labor nicht ermittelt hat, wie weit der Baukasten verbreitet war oder wie viele Rechner infiziert waren.

Diese Beschreibung liegt auf der älteren Tür aus dem vorigen Abschnitt. Das Recht zum Auspacken sitzt beim aktuellen Benutzer, also kann ein Programm in derselben Anmeldung innerhalb der Tür stehen, und AES-256-GCM hält das Feld nur davon ab, Klartext zu sein. Der Bericht ist nicht so geschrieben, als habe dieses Programm die Prüfung der App-Identität von Chrome bestanden, und er liefert keine Opferzahl, aus der sich „Ihr Chrome ist schon betroffen“ machen ließe. Den Algorithmusnamen in der Schlagzeile als „die Verschlüsselung ist gescheitert“ zu lesen, oder als „also ist mein Passwortspeicher sicher“, geht in beiden Fällen einen Schritt, den der Bericht nicht geht.

Dieselbe Klasse von Berichten mischt außerdem zwei Materialien, die sich leicht als eines behandeln lassen. Eine gestohlene Sitzung lässt jemanden eine Anmeldung benutzen, die Sie schon abgeschlossen haben, solange diese Sitzung gültig bleibt. Das Passwort auf der ursprünglichen Website zu ändern, setzt die nächste Passwort-Anmeldung außer Kraft. Es setzt von sich aus keine Sitzungen außer Kraft, die schon ausgegeben wurden. Die fallen, wenn Sie andere Sitzungen in der Geräteliste des Kontos abmelden, oder wenn die Website sie widerruft. Diese Arbeit ist getrennt davon, wie stark der Algorithmus des Passwortspeichers ist. Eine frühere Prüfung von „ein Passwortwechsel entfernt keine Sitzung, die schon eingetragen ist“ steht in der Passkey-Notiz unten. Das sind zwei verschiedene Schalter.

Die Speicherliste prüfen, nicht die Datenbank

Ein Slogan und eine Schlagzeile beschreiben den Browser vor Ihnen nicht. Ein Wegwerfkonto auf einer Testseite reicht. Die vier Schritte unten bleiben im aktuellen Browser. Sie kopieren den Profilordner dafür nicht heraus.

1. Öffnen Sie den eigenen Passwort-Manager des Browsers (Einstellungen, unter Passwörter oder automatischem Ausfüllen, oder die Passwortseite des Browsers aus der Adresszeile). Lesen Sie nur die Websiteliste: Hat E-Mail, Bank, eine Cloud-Konsole oder ein Code-Host jeweils eine Zeile? Zeigen Sie keinen Klartext an, und exportieren Sie nicht.
2. Suchen Sie „Passwörter speichern anbieten“, oder den Schalter mit derselben Aufgabe. Er entscheidet, ob die nächste Anmeldung gespeichert werden kann. Ihn auszuschalten löscht Zeilen nicht, die schon da sind. Entfernen geht zeilenweise in der Liste, oder über die Browserfunktion zum Löschen gespeicherter Passwörter.
3. Öffnen Sie „Über“ und bestätigen Sie, dass der Browser noch offizielle Updates erhält. Notieren Sie die Version. Die Version belegt nicht, dass Passwortfelder zu App-Bound Encryption umgezogen sind. Die Einstellungsseite druckt die Wörter DPAPI oder App-Bound nicht. Gehen Sie dafür nicht Schlüsselkennungen im Profilordner durch.
4. Wenn Sie schon vermuten, dass auf diesem Rechner ein Programm läuft, das Sie nicht installiert haben: Klicken Sie auf diesem Rechner nicht auf „Passwort anzeigen“. Auf einem Gerät, dem Sie noch vertrauen, melden Sie andere Sitzungen an den wichtigen Websites ab und ersetzen Sie diese Passwörter. Verwenden Sie ein Passwort nicht über mehrere Websites hinweg. Dieser Schritt begrenzt den Schaden. Er ist keine Einladung, den Speicher auf dem verdächtigen Rechner auszupacken, „um zu sehen, ob ein Lesen möglich ist“.

Eine Versionsnummer benennt die Schlüsselgeneration nicht

Chrome 127 ist die Version, in der App-Bound Encryption angefangen hat, Cookies abzudecken. Es ist nicht die Version, in der jedes gespeicherte Passwort an diesem Tag die Verpackung gewechselt hat. 130, 140 oder eine spätere Hauptversion zu sehen, zeigt nur, dass der Browser hinter diesem Startpunkt liegt. Ob Passwortfelder den Umzug abgeschlossen haben, hat die Notiz vom Juli 2024 späteren Versionen überlassen, und die Oberfläche zeigt keine Verpackungsgeneration an. Steht die Version in einem Prüfblatt, sollte die nächste Zelle „das belegt nicht, dass der Passwortspeicher anwendungsgebunden ist“ sagen, und kein Häkchen.

Die Speicherabfrage ist der Schalter, der eine Zeile anlegt

Viele Passwörter kommen in den Speicher, weil der Browser nach einer erfolgreichen Anmeldung gefragt hat und eine Person auf Speichern geklickt hat, nicht weil eine Verschlüsselungsseite sie hochgeladen hat. Von da an sitzt diese Zeile hinter der Tür, die oben beschrieben ist. Erzeugen Sie ein Passwort, das nur auf diesem Gerät existiert, und lehnen Sie die Abfrage ab, wird es keine Zeile im Passwort-Manager. Die Abfrage abzulehnen belegt nicht, dass ein Seitenskript das Passwort nie gesendet hat. Diese Frage gehört in das Network-Panel. Sie belegt nur, dass Sie die Zeichenfolge nicht an die Speicherliste des Browsers gegeben haben.

Vier Arten, „verschlüsselt“ zu weit zu lesen

Die erste Überdehnung liest AES-256-GCM als „Schadsoftware kann das nicht lesen“. Der Algorithmus zeigt, dass das Feld kein Klartext ist, und er zeigt, dass sich Chiffretext ohne den Schlüssel nicht ändern lässt und danach noch prüft. Ist dieser Schlüssel mit DPAPI für den aktuellen Benutzer verpackt, hat Google schon geschrieben, dass ein Programm unter diesem Benutzer von diesem Schutz nicht erfasst wird. Der Algorithmusname und die Position der Tür sind zwei Zeilen, und sie müssen in einer Prüfung zwei Zeilen bleiben.

Die zweite Überdehnung liest „ich habe ein Windows-Anmeldepasswort“ als „der Passwortspeicher ist gegen Schadsoftware immun“. Das Anmeldepasswort ist das, was andere Konten und einen Kaltstart-Angriff davon abhält, DPAPI auszupacken. Ein Programm, das schon läuft, nachdem Sie sich angemeldet haben, benutzt diese entsperrte Benutzerumgebung. Ein Anmeldepasswort sollten Sie trotzdem setzen. Es beantwortet eine andere Tür.

Die dritte Überdehnung liest „Version über 127“ als „gespeicherte Passwörter und Cookies sind beide anwendungsgebunden, und Code im Prozess kann sie auch nicht sehen“. Googles Startpunkt waren Cookies. Passwörter waren die Ausweitung. App-Bound Encryption blockiert das ältere Auspacken von außerhalb des Browsers. Eine Erweiterung, oder anderer Code, der im Browser-Prozess schon läuft, wird nicht blind, weil diese Tür existiert.

Die vierte Überdehnung liest „jede Website hat ein anderes Passwort“ als „es ist in Ordnung, wenn der ganze Speicher gelesen wird“. Einzigartige Passwörter halten einen Einbruch bei einer Website davon ab, bei Ihrer E-Mail und Ihrer Cloud-Konsole wiederholt zu werden. Sie halten ein Programm nicht auf, das jede gespeicherte Zeile in einem Durchgang liest. Beide Kontrollen lohnen sich. Sie decken verschiedene Fehlschläge ab.

Häufige Fragen

Wenn der Passwort-Manager „verschlüsselt“ anzeigt, können andere Programme auf diesem Rechner das Passwort dann nicht lesen?

Verschlüsselt heißt: Das Passwortfeld auf der Platte ist kein Klartext. In der Windows-DPAPI-Generation schreibt Google, der Schutz gelte anderen Benutzern und Kaltstart-Angriffen, und er gelte einem Programm nicht, das als angemeldeter Benutzer läuft. App-Bound Encryption ab Chrome 127 beginnt bei Cookies: Das ältere Auspacken von außen scheitert an Daten, die schon umgezogen sind, während das Innere des Browser-Prozesses weiter lesen kann. Das Wort „verschlüsselt“ auf dem Bildschirm sagt nicht, in welcher Generation die Passwortfelder dieses Rechners stehen.

Heißt App-Bound Encryption in Chrome 127, dass Schadsoftware gespeicherte Passwörter nicht mehr entschlüsseln kann?

Nein. Die Notiz vom 30. Juli 2024 führt Passwörter und Zahlungsdaten als Punkte, die spätere Versionen abdecken sollen. App-Bound Encryption engt das Recht zum Auspacken ein: vom aktuellen Benutzer auf einen Browser, den die Systemkomponente akzeptiert. Deshalb scheitert ein Programm außerhalb des Browsers, das nur den älteren Benutzer-Weg nutzt, an Daten, die schon umgezogen sind. Code im Prozess bleibt auf der Innenseite dieser Tür, und die Versionsnummer zeigt nicht, dass jedes gespeicherte Passwort in Ihrem Browser den Umzug abgeschlossen hat.

Heißt der Bericht vom 25. September, dass jedes Programm meine Chrome-Passwörter schon lesen kann?

Dieser Schluss geht zu weit. Der Bericht beschreibt ein Windows-Programm, das gespeicherte Passwörter, Zahlungskarten, Verlauf und Sitzungen aus 17 Chromium-Browsern liest, dazu Firefox-Verlauf und -Cookies, und er sagt, Passwortfelder nutzten AES-256-GCM, der Schlüssel werde über den benutzerbezogenen Datenschutz ausgepackt. K7 hat keine Opferzahl veröffentlicht und das Programm nicht so dargestellt, als habe es die Prüfung der App-Identität bestanden. In welcher Generation Ihr Browser steht, hängt an der Speicherliste und daran, ob Updates noch ankommen, nicht am Algorithmusnamen in einer Schlagzeile.

Hören gespeicherte Sitzungen auf, sobald ich das Passwort einer Website ändere?

Nicht immer. Ein Passwortwechsel setzt die nächste Anmeldung mit dieser Zeichenfolge außer Kraft. Schon ausgegebene Sitzungen bleiben oft, bis Sie andere Sitzungen in der Geräteliste des Kontos abmelden oder die Website sie widerruft. Dieselbe Klasse von Programmen nimmt Sitzungen und gespeicherte Passwörter zusammen mit. Wer ein Passwort ändert und andere Sitzungen angemeldet lässt, bearbeitet das Passwort, nicht die Sitzung.

Schreibt FastPwd ein erzeugtes Passwort in die Speicherliste des Browsers?

FastPwd schreibt diese Liste nicht, und die Website hat keinen eigenen Passwort-Tresor. Eine Zeile entsteht nur, wenn Sie die Speicherabfrage des Browsers annehmen. Der Zufallsmodus nutzt crypto.getRandomValues, erlaubt 6–128 Zeichen und steht standardmäßig auf 16. Das Ergebnis wird nicht hochgeladen. Sofort nutzbar, ohne Konto. Kann ein Programm auf diesem Rechner den aktuellen Tab oder die Zwischenablage schon lesen, sieht es Klartext auf der Seite. Die Grenze „wird nicht hochgeladen“ ersetzt diese Grenze nicht.

„Nicht gespeichert“ an einem Generator sehen, den Sie jetzt öffnen können

Wenn der Unterschied zwischen „ein Passwort ist erschienen“ und „ein Passwort ist in den Speicher des Browsers gekommen“ sichtbar werden soll, öffnen Sie den Passwort-Generator von FastPwd. Keine Registrierung. Lassen Sie im Zufallsmodus die Vorgabe von 16 Zeichen stehen und erzeugen Sie ein Wegwerfpasswort. Bietet der Browser das Speichern an, lehnen Sie ab. Gehen Sie zurück zum Passwort-Manager: Die Testseite sollte keine neue Zeile bekommen haben. FastPwd führt keinen Passwort-Tresor, und es schreibt die Speicherliste des Browsers nicht für Sie.

Die Erzeugung nutzt crypto.getRandomValues. Die Länge läuft von 6 bis 128 Zeichen, mit 16 als Vorgabe. Kürzer als 8 wird als schwächer gekennzeichnet. Das Ergebnis wird nicht hochgeladen. Öffnen Sie die DevTools, wählen Sie Network, schalten Sie „Protokoll beibehalten“ ein und suchen Sie in Anfragezeilen und Nachrichtentexten nach der ganzen Zeichenfolge. Sie sollte in den Anfragen der Seite nicht erscheinen. Diese Suche zeigt, dass dieser Lauf den Tab nicht als HTTP-Body verlassen hat. Sie zeigt nicht, dass ein lokales Programm die Seite oder die Zwischenablage nicht lesen kann. Ist dieser Rechner schon nicht vertrauenswürdig, erzeugen Sie das Passwort und melden Sie sich auf einem anderen Gerät an.

Wenn Sie zusätzlich sehen wollen, ob eine Zeichenfolge wie ein öffentlich häufiges schwaches Passwort aussieht, nehmen Sie ein anderes Wegwerfpasswort mit in Passwortstärke prüfen. Das Passwort, das Sie prüfen, wird nicht hochgeladen. Ein Fehltreffer belegt nicht, dass die Zeichenfolge im Netz nie vorgekommen ist. Ein Treffer heißt nur, dass sie zu häufig ist. Fügen Sie nicht das echte Passwort ein, das Sie gleich einsetzen wollen, und exportieren Sie den Browser-Passwortspeicher nicht, um den Export zu prüfen.

Muss diese Zeichenfolge ein einziges Mal eine andere Person erreichen, lassen Sie sie aus einem Ticket-Text, der in Server-Logs landet. Nutzen Sie stattdessen Burn-Link: Der Server speichert nur Chiffretext, der Schlüssel sitzt hinter # im Link, und Erstellen wie Lesen brauchen kein Konto. Dieser Kanal beantwortet „wie übergebe ich das einmal“. Er macht ein altes Passwort, das im Browser schon gespeichert ist, nicht sicher. Löschen Sie diese ältere Zeile im Passwort-Manager, und ersetzen Sie sie von einem Gerät, dem Sie vertrauen.

Weiterlesen

Eine Behauptung „lokal, nicht hochgeladen“ prüfen Sie, indem Sie in Network nach einem Canary suchen, in So prüfen Sie, dass browserlokale Verschlüsselung keinen Klartext sendet. Ein Passwortwechsel setzt eine Sitzung nicht außer Kraft, die schon ausgegeben wurde: siehe Warum ein Anruf zum Passkey-Update die Sitzung stiehlt – und nicht den Passkey. Eine lokale Liste schwacher Passwörter fängt häufige schwache Passwörter und ist kein netzweiter Abgleich geleakter Datenbanken: siehe Was eine lokale Liste geleakter Passwörter beweisen kann – und warum das kein netzweiter Abgleich ist.