mcb hat´s schon gepostet. War ursprünglich von
verlinkt, was ich in meiner Reaktion auf @hikaru nicht nocheimal zitiert hatte. Asche auf mein Haupt.
Chrome speichert Passwörter im Speicher im Klartext ...
- Ersteller mcb
- Erstellt am
Überall hin? Zumindest gelangt(e?) der Code so zu Debian. [1]
Ich habe das seitdem nicht mehr geprüft. Es mag jetzt also anders sein. Allerdings hat Chromium in der Zwischenzeit den Status als offiziell mit Sicherheitspatches versorgter Browser bei Debian verloren, weshalb er für mich ohnehin nicht mehr zur Diskussion steht. Und auch schon weit vorher habe ich Erfahrungen mit den Maintainern gemacht, die mich vermuten lassen,, das es mit der Wartung von Chromium bei Debian nie weit her war.
[1] https://debianforum.de/forum/viewtopic.php?t=164083
Hätte ich ihn Beitrag #8 verlinkt im Wort "Problem", aber das sowas ein Link ist ist nur schwer erkennbar.
Achso da gehts um Javascript, dachte der ganze Quellcode wäre so.
Zuletzt bearbeitet:
Natürlich kann proprietäre Sicherheit sicher sein. Auch vor Basel III hat der Großteil der Banken es geschafft, mein Geld sicher zu verwahren.Kann proprietäre (=nicht nachvollziehbare) "Sicherheit" überhaupt sicher sein?
"Überweise mir all dein Geld! Ich bewahre es sicher für dich auf. Versprochen! - Wie, Nachweis? Nö, mach ich nicht."
Security by Obscurity funktioniert nicht, das ist kein großes Geheimnis. Aber ordentlich implementierte Algorithmen und Methoden gibt es genau wie das Gegenteil hüben wie drüben.
Ich bevorzuge grundsätzlich selbst FLOSS - aber seien wir nicht päpstlicher als der Papst - es gibt auch hier hinreichend viele Sicherheitslücken, die Jahrzehntelang nicht auffallen oder nicht interessieren (eine der unrühmlichsten wird wohl der IP6-Bug im networkmanager gewesen sein...).
Du bist nicht der erste mit so einer Idee
OScar – Wikipedia
de.wikipedia.org
TABBY EVO – OsVehicle
www.osvehicle.com
Würde man die Kfz-Entwicklung gesetzlich OS machen, was würde dann passieren? Wäre das Autofahren für uns alle sicherer oder die Gewinnmarge für die OEMs höher? Würden die Zulieferer die Offenheit nutzen, sicherste Lösungen zu finden oder billigste Lösungen, die noch gesetzeskonform sind (ok... wird eh gemacht, aber jeder hat seine Methoden, die man sicher auch kombinieren könnte)?
Ich bin Software-Entwickler. In unserer Software werden auch Algorithmen verwendet, die du nicht kennst, da sie zum Großteil geschlossen ist. Ich vertraue unserer Software mein Leben an (da wären wir dann wieder bei den Bremsen... oder Lenkungen... oder Flugsteuerungssystemen - wo es kritisch wird werden Soft- und Hardware halt redundant ausgelegt... wird sie dadurch vertrauenswürdiger oder eher das Gegenteil?).
Es geht mir aber gar nicht um mich persönlich. Es geht mir um das Gros der Benutzer. Und da sind wir wieder im Kreis: Sollte nicht auch die Mozilla-Foundation in Erwägung ziehen, dem Benutzer anzubieten, ein vorhandenes TPM zu nutzen, statt die Passwörter im Klartext in den RAM zu legen und den "Bug" als "wontfix" abzustempeln - für Chromium sollte das dann erst recht gelten, da man sich eh nicht der FLOSS-Philosophie unterwirft.
Im Endeffekt geht es um das Kosten-Nutzen-Verhältnis.
Benutzt man einen zusätzlichen Passwort-Safe (der vielleicht wirklich das Passwort im Klartext nur in die Register schreibt?), dann geht Usability flöten. Dafür kann ich den Passwort-Safe sehr gut nach außen abschotten und vor äußeren Zugriffen schützen, indem ich ihn z.B. in einer Sandbox nutze und keine Verbindung ins Netzwerk zulasse.
Nutze ich einen Browser, so kann ich darin komfortabler die Passwörter speichern, abrufen und systemübergreifend synchronisieren, als in einem Passwort-Safe, schmeiße aber einer zusätzlichen Instanz, die vom Internet aus kompromittierbar ist, Informationen (es sind ja nicht nur Daten, da es strukturiert und geordnet ist) in den Hals. Ob das jetzt Firefox oder Chrome oder Chromium oder Opera oder Safari oder Brave ist ist meines Erachtens vergleichsweise unwichtig.
Interessant werden die Browser alle für Angreifer sein und ich habe jetzt noch von keinem im Kopf, dass da Mal Passwörter wirkungsvoll ausgespäht worden wären oder die Sicherheit der Passwort-Safes ernsthaft gebrochen gewesen wäre (auf einem bereits kompromittierten System hat man andere Probleme und wenn ein Angreifer physikalischen Zugriff auf das System hat für gewöhnlich auch).
Trotz aller zu Recht (z.B. von @hikaru) vorgebrachten Einwände gegen TPM gibt es durchaus nachdenkenswerte Einsatzszenarien für TPMs (die Rede ist im folgenden von TPM 2.0).
Einer der großen Vorteile einer solchen Security-Enklave ist, dass in ihr Inhalte gespeichert werden können, die man so nicht wieder auslesen kann.
Ein solches Einsatzszenario möchte ich im folgenden kurz beschreiben, weil es im Alltag wirklich einen signifikanten Sicherheitsgewinn bringen kann: Es geht um tpm2d ("daemon to physically bind keys to the local machine"), eingeführt von gnupg in Version 2.3 im April 2021 (https://lists.gnupg.org/pipermail/gnupg-announce/2021q2/000458.html).
Ein großes Problem beim Einsatz von GPG war (und ist): wohin mit den privaten Schlüsseln? Selbst wenn diese in einem kryptographisch gut abgesicherten Container auf der Festplatte liegen: unter ungünstigen Bedingungen können sie von einem Angreifer kopiert werden, und damit ist die eigene GPG-Infrastruktur "verbrannt". Wenn man, unwahrscheinlich genug, einen solchen Abgriff unmittelbar bemerkt – der Schaden ist da, und es ist stets mit großem Aufwand und einigem Ärger verbunden, GPG-Schlüssel zurückzuziehen und neue auszurollen.
Glücklicherweise gibt es sogenannte SmartCards (breiter bekannt sind z.B. Yubikey oder Nitrokey), auf denen man private Schlüssel so speichern kann, dass man zwar mit ihnen die gewünschten kryptographischen Operationen durchführen kann – der private Schlüssel aber NIE wieder von niemandem, auch von mir selbst nicht, wieder ausgelesen werden kann (weswegen es ratsam ist, eine offline-Sicherungskopie irgendwo an einem sicheren Ort abzulegen).
Der große Vorteil von SmartCards (vor allem jener mit USB-Schnittstelle) ist, dass man sie überallhin mitnehmen kann. Der große Nachteil von SmartCards ist, dass man sie überall leicht verlieren kann. Und: man kann nur eine sehr begrenzte Anzahl von GPG-Schlüsseln darauf speichern, in der Regel nur einen Hauptschlüssel und mehrere Unterschlüssel.
Mit dem tpm2d-Daemon lassen sich private GPG-Schlüssel nun auf einem vergleichbaren Sicherheitsniveau wie bei SmartCards auf jenem Rechner speichern, der das TPM auf dem Mainboard hat (und die Schlüssel selbst sind, wie bei SmartCards, auch hier nie wieder auslesbar – also auch hier ist eine offline-Sicherungskopie keine schlechte Idee ...).
Vorteil gegenüber SmartCards: Es können prinzipiell unbegrenzt viele Schlüssel auf dem TPM abgelegt werden (weil die Derivate der privaten Schlüssel während des Konvertierungsprozesses nicht im TPM, sondern auf dem Rechner abgelegt werden). Nachteil: die Schlüssel sind an exakt diesen einen Rechner gebunden und müssen auf jedem anderen Rechner (mit einem anderen TPM) neu erzeugt werden.
Wenn der Rechner weg ist, sind natürlich auch die privaten Schlüssel weg (wenngleich nicht auslesbar). Natürlich sind bei einem defekten Mainboard die Schlüssel dann ebenfalls weg. Ob das jetzt ein Vorteil ist gegenüber den USB-SmartCards (die kleiner und leichter verlierbar sind, aber eben auch nicht physikalisch an einen Rechner gebunden): das muss jeder/jede für sich entscheiden.
Schön dokumentiert ist das Ganze in folgendem Artikel: https://gnupg.org/blog/20210315-using-tpm-with-gnupg-2.3.html
Dort wird auch ohne Umschweife angesprochen, was ein uneingeschränktes Vertrauen in TPMs noch schwierig macht:
"[…] that’s when we ask it for its public key and trust the result. This transaction could be made secure if we used the Manufacturer certificate to certify the public key, but such a transaction requires infrastructure that currently doesn’t exist in the average Linux distribution."
Und: "The TPM isn’t secure against every attack: in particular it’s not certified against physical intrusion meaning someone can theoretically slice the chip apart and extract the secret wrapping keys from the internal NVRam."
Aber wenn ich damit rechnen müsste, dass jemand den Aufwand betreibt, den TPM-Chip meines Rechners abzuschleifen, um an dessen kryptographisch gesicherte Inhalte zu kommen: dann müsste ich ohnehin darüber nachdenken, welche anderen organisatorischen Maßnahmen für mich vielleicht sinnvoller sind, als meine privaten GPG-Schlüssel in ein TPM zu hacken ...
Einer der großen Vorteile einer solchen Security-Enklave ist, dass in ihr Inhalte gespeichert werden können, die man so nicht wieder auslesen kann.
Ein solches Einsatzszenario möchte ich im folgenden kurz beschreiben, weil es im Alltag wirklich einen signifikanten Sicherheitsgewinn bringen kann: Es geht um tpm2d ("daemon to physically bind keys to the local machine"), eingeführt von gnupg in Version 2.3 im April 2021 (https://lists.gnupg.org/pipermail/gnupg-announce/2021q2/000458.html).
Ein großes Problem beim Einsatz von GPG war (und ist): wohin mit den privaten Schlüsseln? Selbst wenn diese in einem kryptographisch gut abgesicherten Container auf der Festplatte liegen: unter ungünstigen Bedingungen können sie von einem Angreifer kopiert werden, und damit ist die eigene GPG-Infrastruktur "verbrannt". Wenn man, unwahrscheinlich genug, einen solchen Abgriff unmittelbar bemerkt – der Schaden ist da, und es ist stets mit großem Aufwand und einigem Ärger verbunden, GPG-Schlüssel zurückzuziehen und neue auszurollen.
Glücklicherweise gibt es sogenannte SmartCards (breiter bekannt sind z.B. Yubikey oder Nitrokey), auf denen man private Schlüssel so speichern kann, dass man zwar mit ihnen die gewünschten kryptographischen Operationen durchführen kann – der private Schlüssel aber NIE wieder von niemandem, auch von mir selbst nicht, wieder ausgelesen werden kann (weswegen es ratsam ist, eine offline-Sicherungskopie irgendwo an einem sicheren Ort abzulegen).
Der große Vorteil von SmartCards (vor allem jener mit USB-Schnittstelle) ist, dass man sie überallhin mitnehmen kann. Der große Nachteil von SmartCards ist, dass man sie überall leicht verlieren kann. Und: man kann nur eine sehr begrenzte Anzahl von GPG-Schlüsseln darauf speichern, in der Regel nur einen Hauptschlüssel und mehrere Unterschlüssel.
Mit dem tpm2d-Daemon lassen sich private GPG-Schlüssel nun auf einem vergleichbaren Sicherheitsniveau wie bei SmartCards auf jenem Rechner speichern, der das TPM auf dem Mainboard hat (und die Schlüssel selbst sind, wie bei SmartCards, auch hier nie wieder auslesbar – also auch hier ist eine offline-Sicherungskopie keine schlechte Idee ...).
Vorteil gegenüber SmartCards: Es können prinzipiell unbegrenzt viele Schlüssel auf dem TPM abgelegt werden (weil die Derivate der privaten Schlüssel während des Konvertierungsprozesses nicht im TPM, sondern auf dem Rechner abgelegt werden). Nachteil: die Schlüssel sind an exakt diesen einen Rechner gebunden und müssen auf jedem anderen Rechner (mit einem anderen TPM) neu erzeugt werden.
Wenn der Rechner weg ist, sind natürlich auch die privaten Schlüssel weg (wenngleich nicht auslesbar). Natürlich sind bei einem defekten Mainboard die Schlüssel dann ebenfalls weg. Ob das jetzt ein Vorteil ist gegenüber den USB-SmartCards (die kleiner und leichter verlierbar sind, aber eben auch nicht physikalisch an einen Rechner gebunden): das muss jeder/jede für sich entscheiden.
Schön dokumentiert ist das Ganze in folgendem Artikel: https://gnupg.org/blog/20210315-using-tpm-with-gnupg-2.3.html
Dort wird auch ohne Umschweife angesprochen, was ein uneingeschränktes Vertrauen in TPMs noch schwierig macht:
"[…] that’s when we ask it for its public key and trust the result. This transaction could be made secure if we used the Manufacturer certificate to certify the public key, but such a transaction requires infrastructure that currently doesn’t exist in the average Linux distribution."
Und: "The TPM isn’t secure against every attack: in particular it’s not certified against physical intrusion meaning someone can theoretically slice the chip apart and extract the secret wrapping keys from the internal NVRam."
Aber wenn ich damit rechnen müsste, dass jemand den Aufwand betreibt, den TPM-Chip meines Rechners abzuschleifen, um an dessen kryptographisch gesicherte Inhalte zu kommen: dann müsste ich ohnehin darüber nachdenken, welche anderen organisatorischen Maßnahmen für mich vielleicht sinnvoller sind, als meine privaten GPG-Schlüssel in ein TPM zu hacken ...
@mcb Danke, der Text beruhigt etwas, nachdem ich einziger user bin und nach bestem Gewissen weitere Logins nicht zulasse. Zur XP-Zeit war ich nur mit OS/2 im Netz (nach außen besser abgesichert), XP im LAN ohne externen Netzzugriff für einzelne Win-Anwendungen, aber auch dort einziger user. Diagnosedaten lasse ich auch nicht durch (hoffe ich), aber ..... werde da mal wieder nachprüfen, bei den vielen "Service-"Updates.
Gruß Peter
PS auch @schoerg Danke, hatte nicht besonders darauf geachtet und den Kursor nicht drauf gesetzt. Nächstesmal besser .....
Gruß Peter
PS auch @schoerg Danke, hatte nicht besonders darauf geachtet und den Kursor nicht drauf gesetzt. Nächstesmal besser .....
Zuletzt bearbeitet:
Aber du kannst nicht unabhängig verifizieren, dass sie es ist. Also musst du davon ausgehen, dass sie es nicht ist.
Und dann ist diese proprietäre Sicherheit wertlos, selbst wenn sie faktisch besteht, denn du kannst das Faktum nicht als solches erkennen.
Das ist unbenommen. Aber um die Qualität (Sicherheit, Stabilität, etc.) einer Software beurteilen zu können, muss ich überhaupt die Möglichkeit haben, sie unabhängig überprüfen zu können. Genau diese Möglichkeit habe ich bei proprietärer Software nicht, bei FLOSS schon.
Dass die Möglichkeit allein nicht ausreicht, sondern ich mich dann auch wirklich auf den Hosenboden setzen muss, um die Software zu überprüfen, oder zumindest jemanden meiner freien Wahl damit beauftragen muss, ändert daran nichts.
Zoro1234
New member
- Registriert
- 7 Feb. 2022
- Beiträge
- 22
Nutze das Keepass Addin für Chrome und habe damit gute Erfahrungen gemacht. https://chrome.google.com/webstore/...rd-acc/fmhmiaejopepamlcjkncpgpdjichnecm?hl=de
- Registriert
- 20 Apr. 2007
- Beiträge
- 71.948
Das nützt Dir gar nichts, da Chrome die Passwörter aus dem KeyPass-Addin kopiert dennoch in Klartext im Arbeitsspeicher hält:
1. Absatz
Chrome speichert Passwörter im Speicher im Klartext
[English]Das ist ist schon ein dickes Ei, auf das Sicherheitsforscher der CyberArk Labs beim Google Chrome-Browser gestoßen sind. Dieser speichert Passwörter und Cookies im Klartext im Arbeitsspeicher des eigenen Prozesses. Das bedeutet, ein entsprechendes Tool könnte diese Klartext-Passwörter...
www.borncity.com
zwieblum
Well-known member
- Registriert
- 3 Mai 2009
- Beiträge
- 1.425
Früher oder später werden die Passwörter immer im Klartext vorliegen. Selbst wenn das nur "kurz" am Stack passiert wird der Speicher ja nicht unbedingt nach Gebrauch genullt, geschweige denn dass alle Buffer gelöscht werden. Und wenn dann ein toller GC mitspielt ... tja.
netghost78
Active member
- Registriert
- 25 Jan. 2011
- Beiträge
- 1.399
Aber wenn man die Eingabemethode vom KeePass nutzt, liegen sie nur im Prozeß ebendieses Programms vor und nicht im Bereich des Browsers.
- Registriert
- 20 Apr. 2007
- Beiträge
- 71.948
Hast Du den Satz mit den Cookies gelesen? Die halten das Passwort offenbar über den Eingabezeitpunkt hinaus im Arbeitsspeicher, also wohl auch wenn das KeyPass-Addin schon geschlossen ist.
