Hallo Gunnar, dass ein Programm Daten im Klartext im Speicher hält, kommt oft vor. Natürlich kann man die Daten des Passwortmanagers verschlüsselt im Speicher halten, aber irgendwann muss man Farbe bekennen und das Ding entschlüsseln. Spätestens dann, wenn das Passwort an den damit geschützten Dienst übermittelt werden muss. Ein treusorgender Browser sorgt sofort nach Übermittlung dafür, dass der entschlüsselte Speicherbereich überschrieben wird, so dass der Klartext nur wenige Mikrosekunden im Browserspeicher vorliegt. Aber er liegt auch im Netzwerkstack vor. Okay. base64-codiert, aber er liegt vor. D.h. der Angriffsvektor ist nicht weg, sondern etwas kleiner, und zeigt woanders hin. Hinzu kommt, dass man den Speicher eines Prozesses auslesen muss, um an die Daten heranzukommen. Das benötigt meines Wissens Code in diesem Prozess, oder erhöhte Admin-Rechte. Aber ich lasse mich gerne eines Schlimmeren belehren. Allerdings: - Mit JavaScript geht das nicht, es sei denn, man findet einen Pufferüberlauftrick - Einen Taskmanager-Dump als Sicherheitslücke zu beschreiben ist in etwa so schlau wie einen Hauseinbruch zu demonstrieren, indem man vorher den Schlüssel unter die Fußmatte legt. - Ob Browser-Extensions, die in C++ oder anderem geschrieben sind, auf diesen Speicher zugreifen können, wäre erstmal zu beweisen. Edge, Chrome und Konsorten teilen sich nicht ohne Grund auf mehrere **Prozesse**, nicht Threads, auf. Mit anderen Worten: das ist Heise-typisches Microsoft-Bashing. Und alle Kommentare bashen stumpf mit. Ich weiß, warum ich mein c't Abo storniert habe. Ein kritischer Angriffsvektor liegt mMn vor, wenn ein fremdes Programm – und zwar NICHT der Taskmanager, denn den hat der Benutzer ja selbst aufgerufen und der kann den PW-Manager eh direkt aufrufen – den Speicher von Edge auslesen kann und darin die Passwörter findet. Dazu muss es aber erstmal wissen, wo es suchen muss. Dass ich ein Passwort finde, wenn ich es kenne, ist keine Kunst. Ich muss es finden, ohne es zu kennen. **Dies hätte das Video vorführen müssen.** Nur - wie macht man es besser? Man müsste die Daten verschlüsselt speichern, aber man muss sie auch entschlüsseln können. D.h. der Code zum Entschlüsseln muss im Browser vorliegen. Wenn man weiß, wie der Passwortmanager programmiert ist und hinreichend schlau ist (ok, ich nicht), sollte es möglich sein, so die nötigen Infos im Dump zu finden. Die einzige sichere Methode wäre ein geschützter Windows-Prozess, der die Passworthaltung übernimmt und der im Namen des Browsers den Authenticate-Header in den betreffenden Request einsteuert. Dieser muss dann auch noch die Passwort-DB so speichern, dass man sie bei einem Boot von USB-Stick nicht einfach knacken kann. Das heißt dann aber auch, dass dieser Prozess zwischen Klartext und HTTPS-Datenstrom sitzen müsste, denn die HTTPS-Verschlüsselung macht der Browser, nicht der Netzwerkstack. Und damit findet sich der Authenticate-Header wieder irgendwo im RAM. Um das zu lösen, müsste jede Menge Netzwerk-Code vom Browser ins OS verschoben werden, um sicherer zu werden. Macht das irgendwer? Linux? Mac? _Rolf_ -- sumpsi - posui - obstruxi

Hallo Gunnar, dass ein Programm Daten im Klartext im Speicher hält, kommt oft vor. Natürlich kann man die Daten des Passwortmanagers verschlüsselt im Speicher halten, aber irgendwann muss man Farbe bekennen und das Ding entschlüsseln. Spätestens dann, wenn das Passwort an den damit geschützten Dienst übermittelt werden muss. Ein treusorgender Browser sorgt sofort nach Übermittlung dafür, dass der entschlüsselte Speicherbereich überschrieben wird, so dass der Klartext nur wenige Mikrosekunden im Browserspeicher vorliegt. Aber er liegt auch im Netzwerkstack vor. Okay. base64-codiert, aber er liegt vor. D.h. der Angriffsvektor ist nicht weg, sondern etwas kleiner, und zeigt woanders hin. Hinzu kommt, dass man den Speicher eines Prozesses auslesen muss, um an die Daten heranzukommen. Das benötigt meines Wissens Code in diesem Prozess, oder erhöhte Admin-Rechte. Aber ich lasse mich gerne eines Schlimmeren belehren. Allerdings: - Mit JavaScript geht das nicht, es sei denn, man findet einen Pufferüberlauftrick - Einen Taskmanager-Dump als Sicherheitslücke zu beschreiben ist in etwa so schlau wie einen Hauseinbruch zu demonstrieren, indem man vorher den Schlüssel unter die Fußmatte legt. - Ob Browser-Extensions, die in C++ oder anderem geschrieben sind, auf diesen Speicher zugreifen können, wäre erstmal zu beweisen. Edge, Chrome und Konsorten teilen sich nicht ohne Grund auf mehrere **Prozesse**, nicht Threads, auf. Mit anderen Worten: das ist Heise-typisches Microsoft-Bashing. Und alle Kommentare bashen stumpf mit. Ich weiß, warum ich mein c't Abo storniert habe. Ein kritischer Angriffsvektor liegt mMn vor, wenn ein fremdes Programm – und zwar NICHT der Taskmanager, denn den hat der Benutzer ja selbst aufgerufen und der kann den PW-Manager eh direkt aufrufen – den Speicher von Edge auslesen kann und darin die Passwörter findet. Dazu muss es aber erstmal wissen, wo es suchen muss. Dass ich ein Passwort finde, wenn ich es kenne, ist keine Kunst. Ich muss es finden, ohne es zu kennen. **Dies hätte das Video vorführen müssen.** Nur - wie macht man es besser? Man müsste die Daten verschlüsselt speichern, aber man muss sie auch entschlüsseln können. D.h. der Code zum Entschlüsseln muss im Browser vorliegen. Wenn man weiß, wie der Passwortmanager programmiert ist und hinreichend schlau ist (ok, ich nicht), sollte es möglich sein, so die nötigen Infos im Dump zu finden. Die einzige sichere Methode wäre ein geschützter Windows-Prozess, der die Passworthaltung übernimmt und der im Namen des Browsers den Authenticate-Header in den betreffenden Request einsteuert. Dieser muss dann auch noch die Passwort-DB so speichern, dass man sie bei einem Boot von USB-Stick nicht einfach knacken kann. Das heißt dann aber auch, dass dieser Prozess zwischen Klartext und HTTPS-Datenstrom sitzen müsste, denn die HTTPS-Verschlüsselung macht der Browser, nicht der Netzwerkstack. Und damit findet sich der Authenticate-Header wieder irgendwo im RAM. Um das zu lösen, müsste jede Menge Netzwerk-Code vom Browser ins OS verschoben werden, um sicherer zu werden. Macht das irgendwer? Linux? Mac? _Rolf_ -- sumpsi - posui - obstruxi