Ein wiederkehrendes Muster
Anfang Mai 2026 sorgte ein Befund von Sicherheitsforscher Tom Jøran Sønstebyseter Rønning für Aufsehen: Microsoft Edge legt gespeicherte Passwörter im Klartext im Arbeitsspeicher ab — auch dann, wenn der Browser frisch gestartet und keine Webseite mit den Zugangsdaten aufgerufen wurde. Ein simpler Speicher-Dump über den Task-Manager und ein Hex-Editor reichten, um das Test-Passwort wiederzufinden. Microsoft bestätigte, dass es sich um eine bewusste Designentscheidung handle. Eine Behebung ist nicht geplant.
Die Schlagzeile ist neu, das Muster nicht. Wer sich die Sicherheitsmodelle der gängigen Browser-Passwortmanager genauer ansieht, erkennt schnell: Edge ist kein Ausreißer, sondern ein besonders prominentes Beispiel für ein strukturelles Problem. Chrome, Edge und Firefox speichern Zugangsdaten lokal in einer Form, die gegen Angriffe aus dem gleichen Benutzerkontext kaum geschützt ist. Genau das ist aber das realistische Bedrohungsszenario, sobald Malware auf einem Endgerät läuft.
In diesem Artikel ordnen wir die aktuelle Edge-Schwachstelle ein, schauen uns die Schwächen der anderen Browser an und erklären, warum dedizierte Passwortmanager wie Bitwarden auf einem grundsätzlich anderen Sicherheitsmodell aufbauen.
Was bei Edge wirklich passiert ist
Der Forscher legte einen Test-Account mit dem Passwort Klartext-PW-Test im Edge-Passwortspeicher ab, schloss den Browser, startete ihn neu und besuchte keine Seite, die das Passwort verwendet hätte. Anschließend erstellte er über den Windows-Task-Manager einen Speicherabzug des msedge.exe-Prozesses — rund 670 MB groß. Mit einem Hex-Editor war das Passwort innerhalb von Sekunden auffindbar.
Aus Sicht moderner Krypto-Hygiene ist das ein klarer Bruch mit etablierten Praktiken. Sensible Daten sollten nur dann unverschlüsselt im Speicher liegen, wenn sie aktiv verwendet werden, und unmittelbar danach mit SecureZeroMemory oder vergleichbaren Mechanismen überschrieben werden. Edge hält die Klartext-Passwörter dauerhaft im Prozessspeicher vor — auch ohne Anlass. Die zusätzliche Authentifizierung über Windows Hello beim Anzeigen der Passwörter in der Oberfläche täuscht dabei einen Schutz vor, der auf Speicherebene nicht existiert.
Die Schwachstelle wurde von Microsoft offiziell als CWE-316 (Cleartext Storage of Sensitive Information in Memory) klassifiziert — und zugleich als „by design" akzeptiert. Das Bedrohungsmodell des Edge-Teams berücksichtigt lokale Speicherzugriffe schlicht nicht.
Das eigentliche Problem: das Bedrohungsmodell stimmt nicht
Browser-Passwortmanager basieren auf einer Annahme, die in Unternehmensumgebungen seit Jahren nicht mehr trägt: dass kein Angreifer denselben Benutzerkontext kontrolliert wie der Browser. Genau dieses Szenario ist aber der Standardfall bei Infostealer-Malware. Wenn ein Mitarbeiter eine manipulierte Software installiert, einen schädlichen Office-Anhang öffnet oder über einen Drive-by-Download infiziert wird, läuft der Schadcode mit denselben Rechten wie der Browser. Damit fallen die meisten lokalen Schutzmechanismen weg.
Laut Flashpoint Global Threat Intelligence Report 2025 ist die Aktivität von Infostealern im ersten Halbjahr 2025 um über 800 Prozent gestiegen. Familien wie Lumma, RedLine, Vidar, StealC und Remus sind als Malware-as-a-Service verfügbar und werden auf Untergrundmärkten ab wenigen hundert Dollar pro Monat vermietet. Ihr primäres Ziel: Browser-Datenbanken mit gespeicherten Zugangsdaten, Session-Cookies, Autofill-Daten und Kryptowallet-Schlüsseln.
Chrome: DPAPI als Achillesferse
Google Chrome — und alle Chromium-Derivate, also auch Edge, Brave und Vivaldi — speichert Anmeldedaten in einer SQLite-Datenbank namens Login Data. Die Passwortfelder sind verschlüsselt, der Schlüssel liegt jedoch in der Datei Local State im selben Profilverzeichnis. Dieser Schlüssel ist mit der Windows Data Protection API (DPAPI) gesichert, die Verschlüsselung an den angemeldeten Windows-Nutzer bindet.
Die Schwäche dieses Modells ist seit Jahren bekannt: DPAPI wurde nie entworfen, um Angriffe aus dem gleichen Benutzerkontext abzuwehren. Ein Prozess, der als der angemeldete Nutzer läuft, kann CryptUnprotectData aufrufen und erhält den Klartext-Schlüssel zurück — ohne weitere Hürde. Ein Infostealer kopiert die SQLite-Datei, entschlüsselt den Master Key per DPAPI und liest sämtliche gespeicherten Passwörter im Klartext aus.
Google hat im Sommer 2024 mit Chrome 127 ein zusätzliches Verfahren eingeführt: App-Bound Encryption. Dabei wird ein zusätzlicher Schlüssel erzeugt, der nur dem Chrome-Prozess selbst zugänglich ist. Die Idee ist gut, die Wirkung jedoch begrenzt. Bereits Wochen nach der Einführung dokumentierte das CyberArk-Forschungsteam Umgehungen — etwa durch Code-Injection in den Chrome-Prozess. Im Frühjahr 2026 berichtete cyberpress.org über den „C4 Bomb"-Exploit, der App-Bound Encryption für Cookies in der Praxis aushebelt.
Firefox: Primary Password ist optional und schwach
Mozilla geht einen anderen Weg, hat aber eigene Probleme. Firefox kennt das Konzept des „Primary Password" (früher Master Password), mit dem der lokale Passwort-Tresor zusätzlich abgesichert werden kann. In der Standardkonfiguration ist das Primary Password jedoch deaktiviert — der Tresor wird also unter dem Profilpfad lediglich mit lokal vorhandenen Schlüsseln verschlüsselt. Auch hier reicht ein Infostealer im Benutzerkontext, um an die Klartext-Passwörter zu gelangen.
Selbst wenn ein Primary Password gesetzt ist, bleibt die Schutzwirkung begrenzt. Mozilla nutzt für die Schlüsselableitung eine veraltete Iteration von SHA-1, was Bruteforce-Angriffe auf den Tresor mit moderner Hardware deutlich erleichtert. Im Bug-Tracker der Foundation existiert seit 2014 ein offenes Ticket (Bug 973759) mit der Forderung, auf moderne Verfahren wie scrypt oder Argon2 umzustellen. Die zuverlässigste Mitigation in Firefox ist heute weiterhin: Passwortspeicher gar nicht erst nutzen.
Was Browser und dedizierte Passwortmanager unterscheidet
Damit der Vergleich greifbar wird, hier eine Übersicht der zentralen Unterschiede zwischen Browser-Passwortmanagern und dedizierten Lösungen wie Bitwarden, 1Password oder KeePassXC.
| Aspekt | Browser-Passwortmanager | Dedizierter Passwortmanager |
|---|---|---|
| Verschlüsselung im Ruhezustand | An Benutzerkontext gebunden (DPAPI / Profil) | Zero-Knowledge mit Master-Passwort, PBKDF2/Argon2 |
| Schutz im RAM | Teils Klartext (Edge), teils ungeschützt | Tresor entschlüsselt nur bei aktiver Nutzung |
| Master-Passwort-Pflicht | Optional (Firefox) oder gar nicht vorhanden | Pflicht, mit hoher Iterationszahl |
| Session-Verhalten | Tresor bleibt offen, solange Browser läuft | Auto-Lock nach Inaktivität, getrenntes Auth-Modell |
| Audit-Logging | Nicht vorhanden | Zentralisiert, mit Zugriffsprotokollen |
| Richtlinien-Durchsetzung | Nicht möglich (Endgerät-individuell) | Zentral über Verwaltungskonsole |
| Trennung Identität/Tresor | Beides am gleichen Browser-Profil | Separate Auth, oft mit MFA und FIDO2 |
Der entscheidende Unterschied ist nicht ein einzelnes Feature, sondern das gesamte Bedrohungsmodell. Dedizierte Passwortmanager gehen davon aus, dass das Endgerät potenziell kompromittiert sein kann, und beschränken die Angriffsfläche dadurch deutlich: Der Tresor bleibt verschlüsselt, das Master-Passwort verlässt das Gerät nie, der Anbieter kann selbst bei Server-Kompromittierung keine Klartext-Daten herausgeben.
Warum Cookies oft das größere Problem sind
Wer über Browser-Passwortmanager spricht, sollte einen weiteren Aspekt nicht übersehen: In den allermeisten modernen Angriffen sind nicht die Passwörter selbst das Hauptziel, sondern Session-Cookies. Ein gestohlenes Session-Cookie erlaubt dem Angreifer, sich direkt in eine bestehende Sitzung einzuklinken — vorbei an MFA, vorbei an Conditional Access, vorbei an Login-Anomalie-Erkennung. Genau dieses Risiko adressiert Browser-seitig keine Passwort-Verwaltung, weil Cookies prozessintern in den gleichen Profildateien liegen wie die Login-Daten.
Eine wirksame Verteidigungslinie braucht daher mehrere Bausteine: einen separat gesicherten Passwort-Tresor, Token-Bindung über Conditional Access in Entra ID, kurze Session-Lebensdauern für sensitive Anwendungen und eine EDR-Lösung, die Infostealer-typische Verhaltensmuster erkennt — etwa Lesezugriffe auf Login Data, Local State oder Cookie-Datenbanken durch fremde Prozesse.
Was wir in der Praxis sehen
In unseren Identity & Access Hardening-Assessments stoßen wir regelmäßig auf Umgebungen, in denen Mitarbeitende über Jahre alle Zugangsdaten im Browser speichern — geschäftliche wie private, von SaaS-Anwendungen über VPN-Portale bis zu administrativen Webkonsolen. Wenn dann ein Endgerät kompromittiert wird, ist innerhalb weniger Minuten ein vollständiger Auszug der Zugangsdaten exfiltriert. Das anschließende Lateral Movement ist häufig nur noch eine Frage von Stunden.
Besonders kritisch wird es, wenn Administratoren ihre privilegierten Konten im gleichen Browser-Profil ablegen wie alltägliche Web-Logins. Diese Vermischung untergräbt das Tiering-Modell komplett: Eine einzige kompromittierte Workstation reicht aus, um Domain-Admin-Zugänge zu verlieren. Genau hier setzt unser Standard-Hardening an — mit einer klaren Trennung zwischen Endnutzer- und Admin-Identitäten und einem dedizierten Passwortmanager mit Rollenkonzept.
Bitwarden als Unternehmenslösung
Als offizieller Bitwarden-Partner unterstützen wir mittelständische Unternehmen bei der Ablösung von Browser-Passwortspeichern durch eine zentrale, auditierbare Lösung. Bitwarden bringt einige Eigenschaften mit, die in der Praxis besonders relevant sind:
- Zero-Knowledge-Architektur: Das Master-Passwort verlässt das Endgerät nie, der Anbieter kann den Tresor nicht entschlüsseln — auch nicht auf gerichtliche Anordnung.
- Self-Hosting-Option: Für Branchen mit hohen Compliance-Anforderungen oder Datensouveränitäts-Vorgaben lässt sich Bitwarden in der eigenen Infrastruktur betreiben.
- Directory-Anbindung: Synchronisation von Nutzern und Gruppen aus Active Directory, Entra ID oder LDAP, inklusive automatischem De-Provisioning beim Austritt.
- Richtliniendurchsetzung: Mindestlänge, Komplexität, MFA-Pflicht für den Tresor sowie Sperren bestimmter Aktionen wie Export oder Re-Use lassen sich zentral durchsetzen.
- Secrets Manager: Technische Geheimnisse wie API-Keys, Datenbank-Passwörter und Zertifikate bekommen einen verschlüsselten Speicher mit granularen Berechtigungen — passend zum Least-Privilege-Prinzip.
- Open Source und unabhängig auditiert: Der vollständige Quellcode ist öffentlich, regelmäßig finden externe Audits statt — Transparenz, die proprietäre Lösungen so nicht bieten können.
Eine ausführlichere Einordnung haben wir bei der Ankündigung der Bitwarden-Partnerschaft bereits beschrieben.
Konkrete Schritte für die Umstellung
Der Wechsel weg von Browser-Passwortmanagern muss kein Großprojekt sein, sollte aber bewusst geplant werden. In der Praxis bewährt sich ein Vorgehen in drei Phasen.
In der ersten Phase wird die zentrale Passwort-Lösung aufgesetzt, an das Verzeichnis angebunden und mit den Mindest-Richtlinien konfiguriert. Parallel dazu definieren wir eine Pilotgruppe — meist die IT-Abteilung selbst, weil sie die sensibelsten Zugänge verwaltet und Multiplikator für die Einführung im restlichen Unternehmen wird.
In der zweiten Phase werden bestehende Browser-Passwörter exportiert und in den Bitwarden-Tresor importiert. Wichtig ist, dass die Browser-Passwortspeicher anschließend per Gruppenrichtlinie oder MDM deaktiviert werden — sonst entstehen schnell wieder parallele Speicher. Für Microsoft Edge und Chrome gibt es ADMX-Templates, die das Speichern und automatische Ausfüllen über PasswordManagerEnabled = 0 unterbinden. Firefox bietet ähnliche Konfigurationen über policies.json. Die Systemhärtung im Rahmen unserer Hardening-Pakete deckt diese Konfiguration mit ab.
In der dritten Phase folgt der Roll-out auf alle Mitarbeitenden, begleitet von einem kurzen Workshop zur Browser-Extension, zum Auto-Fill, zur sicheren Freigabe und zur MFA-Einrichtung des Tresors. Erfahrungsgemäß steigt die Akzeptanz deutlich, wenn der Passwortmanager nicht als zusätzliche Hürde, sondern als Arbeitserleichterung positioniert wird.
Compliance-Sicht: NIS2 und ISO 27001
Auch aus regulatorischer Perspektive führt am zentralen Passwort-Management kaum ein Weg vorbei. Die NIS2-Richtlinie verlangt explizit angemessene Maßnahmen zum Schutz von Authentifizierungsinformationen. ISO 27001 in der Fassung von 2022 fordert in Control 5.17 (Authentication Information) die kontrollierte Vergabe, Speicherung und Verwaltung von Authentifizierungsdaten. Beide Anforderungen lassen sich mit Browser-Passwortspeichern schlicht nicht erfüllen — es gibt weder ein Audit-Log, noch eine Richtliniensteuerung, noch eine Trennung zwischen Identität und Tresor.
Ein zentral betriebener Passwortmanager mit Audit-Trail, MFA-Pflicht und Richtliniendurchsetzung adressiert diese Anforderungen direkt — und sorgt nebenbei dafür, dass auch im Audit-Fall belegbare Nachweise vorliegen.
Fazit
Der aktuelle Edge-Befund ist kein isolierter Bug, sondern ein Symptom: Browser-Passwortmanager sind für ein Bedrohungsmodell entworfen, das in heutigen Unternehmensumgebungen nicht mehr zutrifft. Edge legt Passwörter offen im RAM ab, Chromes DPAPI-Modell scheitert an Infostealern im gleichen Benutzerkontext, App-Bound Encryption wird in der Praxis umgangen, Firefox' Primary Password ist optional und kryptografisch veraltet. Wer Zugangsdaten im Unternehmen ernsthaft schützen will, kommt an einem dedizierten, zentral verwalteten Passwortmanager nicht vorbei.
Schluss mit Passwörtern in Browser-Tresoren. Wir analysieren Ihren aktuellen Umgang mit Zugangsdaten, deaktivieren Browser-Passwortspeicher per Gruppenrichtlinie und führen Bitwarden mit Directory-Anbindung, Richtliniendurchsetzung und MFA-Pflicht ein — vom Pilot bis zum unternehmensweiten Roll-out. Beratungsgespräch zu zentralem Passwort-Management vereinbaren.