Passwort auf Webseite anzeigen via Element untersuchen

Das ist allerdings ein schwerer Fehler.
Ich habe auf Bugzilla noch keinen Eintrag über diesen Fehler gefunden!
In der Zwischenzeit kann man sich mit diesem Addon behelfen: https://addons.mozilla.org/de/firefox/addon/master-password/

Da kann man einstellen, dass nach x Sekunden bei einem Passwortfeld wieder das Masterpasswort abgefragt wird, und nicht nur einmal pro Session.

Und wo ist da nun bitte der vermeintlich schwere Fehler? Wenn man den Input-Type von einem Passwort- in ein Textfeld ändert, wird genau das erwartet, dass da Klartext steht. Firefox verhält sich hier also absolut korrekt, so funktioniert HTML nun einmal. Nicht anders verhalten sich Chrome, Opera und Safari.

Um explizit auf die Ausgangsfrage zu antworten: Ja, das ist im Sinne des Erfinders. Wenn man sich das Benutzerkonto mit anderen teilt, darf man halt keine Passwörter im Browser speichern, wenn man diesbezügliche Bedenken hat. Nutzt man sein Benutzerkonto alleine, ist das sowieso kein Thema, kommt man ja nur selbst ran.

ich kann das Verhalten reproduzieren. Das macht die ganze Funktion "gespeicherte Passwörter zeigen" sinnlos. Dazu braucht es ja das Masterpasswort. Dieses kann man aber umgehen mit o.g. Prozedur.

[Blockierte Grafik: http://i.imgur.com/2Q3jiM6s.png]

Stimmt, besonders da das automatische Eintragen der Login-Daten standardmäßig aktiviert ist (signon.autofillForms).

Leider scheint Mozilla kein Interesse an einer Beseitigung zu haben: https://bugzilla.mozilla.org/show_bug.cgi?id=352761

Man braucht nur mal kurz einen Laptop irgendwo unversperrt stehen lassen, ein geübter Mensch liest dir die Logindaten von einer Seite sicher in unter 30 Sekunden aus, und da kannst du drölf Master-Passwörter haben.

Wie gesagt, wo kein Fehler ist, dort gibt es nichts, was Mozilla beseitigen könnte. Firefox hält sich - genauso wie jeder andere Browser - an die Spezifikation von HTML, wo definiert ist, wie sich Input-Felder verhalten. HTML kann Firefox sehr gut. Die Verantwortung liegt nun einmal bei einem selbst, wen man an seinen Computer lässt.

mag ja sein dass sich Firefox dran hält und sie es nicht ändern können. Dann sollten sie aber auch die Funktion erneut ein Masterpasswort eingeben zu müssen wenn man die PW sehen will heraus nehmen. Ansonsten sehe ich darin nichts weiter als User in falscher Sicherheit zu wiegen.

Zitat von FireFocker

"Element untersuchen (Q)"

Das kannst du ausblenden.

about:config in die Adresszeile eingeben - enter.

Einen neuen Boolean-Wert anlegen - rechte Maustaste ins freie Feld klicken
Einstellungsname: devtools.inspector.enabled 
Wert: false

[Blockierte Grafik: http://i.imgur.com/oHbHaIi.jpg]

Ich verstehe das Problem nicht. Beim ersten Zugriff der Browsersitzung auf die Passwort-Datenbank muss das Master-Passwort eingegeben werden. Solange dies nicht der Fall ist, wird auch kein Feld vorausgefüllt und der "Trick" funktioniert nicht. Das trifft erst zu, nachdem das Master-Passwort bereits eingegeben wurde. Gerade mit einem frischen Profil unter Firefox 24 verifiziert. Das heißt, der Nutzer hat sich an dieser Stelle bereits als Eigentümer ausgewiesen. Verlässt er daraufhin seinen Computer und lässt einen anderen den Computer nutzen, dann ist das pure Fahrlässigkeit

Hier sind wir wieder bei dem Punkt: Wie erreicht man bestmögliche Sicherheit? Viele denken durch Sicherheitsfragen an jeder möglichen Stelle. Genau das ist es aber nicht. Man könnte natürlich bei jeder Passwort-Eingabe wieder den Nutzer fragen, das würde dem Nutzer aber sehr schnell auf die Nerven gehen und er würde die Funktion einfach deaktivieren, was wieder zu niedrigerer Sicherheit führt. Sicherheit und Nutzerinteraktion ist ein komplexes und schwieriges Thema. Man möchte den Nutzer bestmöglich schützen, aber findet man hier nicht die richtige Balance, dann verbessert man nicht die Sicherheit, sondern verschlechtert sie.

Bitte keine Fullquote mehr!

Zitat von FireFocker

Jemand der den HTML Trick kennt, der wird sich auch davon nicht abhalten lassen, die Option "Element untersuchen" wieder innerhalb von wenigen Sekunden anzeigen zu lassen.

Man kann nicht alle Eventualitäten ausschließen. Firefox mit seiner Umgebung ist nicht Fort Knox.

Zudem gibt es Tools, mit denen sich PW leicht in Klartext anzeigen lassen. Wer darauf aus ist, muss nicht diesen von dir beschriebenen umständlichen Weg wählen.

Zumindest die Methode über den Inspector könnte man recht einfach unbrauchbar machen, indem man Felder, deren type von password auf was anderes gesetzt werden, bereinigt oder maskiert oder sonst was.
Welchen Anwendungsfall im Webdesign oder der Fehlersuche gibt es denn, in dem man das echte Password in Klartext sehen muss?

Die Bookmarklet-Methode ist da schon schwieriger zu entschärfen, nehme ich an.

Zitat von hurda

Welchen Anwendungsfall im Webdesign oder der Fehlersuche gibt es denn, in dem man das echte Password in Klartext sehen muss?

Es geht nicht darum, dass ein Webdesigner (-entwickler) unbedingt ein Passwort sehen muss. Aber der Inhalt von Feldern muss ganz generell selbstverständlich lesbar sein. HTML muss sich korrekt verhalten und wenn ein Input-Feld den Typen Text hat, dann muss der Inhalt als Text angezeigt werden, da gibt es keine Alternative zu. Und wo du selbst schon von Fehlersuche sprichst, stell dir ein Formular vor, wo der Inhalt der Felder wichtig ist. Und nun stelle dir vor, das Ding funktioniert nicht. Wie möchtest du das Problem nun debuggen, wenn du nicht an den Inhalt kommst?

Zitat von hurda

Die Bookmarklet-Methode ist da schon schwieriger zu entschärfen, nehme ich an.

Ob über den Inspector von Firefox, die Konsole von Firefox, das Scratchpad von Firefox oder ein Bookmarket in Firefox, es ist immer dasselbe Prinzip - der Inhalt ist vorhanden und kann selbstverständlich gelesen werden. Da ist ja nichts verschlüsselt oder so, das ist immer Klartext, auch wenn da vielleicht nur Punkte dargestellt werden. Die Information selbst ist unverschlüsselt vorhanden. Ansonsten würden Passwort-Felder gar nicht funktionieren. Die Übertragung sollte dann verschlüsselt stattfinden. Mittlerweile warnt Firefox darum sogar in der Konsole bei Passwortfeldern in Formularen auf unverschlüsselten Webseiten, da steht dann: "Password fields present in a form with an insecure (http://) form action. This is a security risk that allows user login credentials to be stolen."

Aber wie ich schon sagte, beim ersten Zugriff auf die Passwort-Datenbank muss ja das Master-Passwort eingegeben werden, vorher wird auch nichts durch den Passwort-Manager vorausgefüllt. Insofern sehe ich das Problem auch gar nicht. Firefox sollte nicht davon ausgehen müssen, dass wenn du dein Master-Passwort eingibst, kurze Zeit später eine andere Person an deinem Computer sitzt, um dich in irgendeiner Form zu bestehlen. Das ist dann wirklich einfach der Bereich, wo man in der eigenen Verantwortung ist, der Schutz durch den Browser hört irgendwo auf. Ich find es persönlich generell kritisch, Passwörter direkt im Browser zu speichern. Insbesondere da auch der Passwort-Manager von Firefox die Passwörter unverschlüsselt speichert, nur das Master-Passwort wird verschlüsselt.

Zitat von Sören Hentzschel

Und wo du selbst schon von Fehlersuche sprichst, stell dir ein Formular vor, wo der Inhalt der Felder wichtig ist. Und nun stelle dir vor, das Ding funktioniert nicht. Wie möchtest du das Problem nun debuggen, wenn du nicht an den Inhalt kommst?

Es hat niemand von den normalen Klartext-Feldern gesprochen, sondern dezidiert von type=password.
Welchen Fehler kann man mit dem Ändern von type=password in type=4711 im Inspector schon diagnostizieren? Entweder der Browser füllt das Feld richtig aus oder nicht, das merkt man aber sowieso.

Zitat von Sören Hentzschel

Insbesondere da auch der Passwort-Manager von Firefox die Passwörter unverschlüsselt speichert, nur das Master-Passwort wird verschlüsselt.

Bitte was? Selbst wenn man ein MP gesetzt hat, sind die normalen PWs mit einschlägigen Tools aus der signons.sqlite/key3.db auslesbar, obwohl man das MP nicht kennt?

Zitat von hurda

Es hat niemand von den normalen Klartext-Feldern gesprochen, sondern dezidiert von type=password.
Welchen Fehler kann man mit dem Ändern von type=password in type=4711 im Inspector schon diagnostizieren? Entweder der Browser füllt das Feld richtig aus oder nicht, das merkt man aber sowieso.

Input-Felder sind am Ende immer Ableitungen einfacher Textfelder, auch Password-Felder. Die Zeichen können maskiert dargestellt werden, das ändert nichts daran, dass der Inhalt vorhanden und Klartext ist. Das auszulesen ist kein Problem und kann auch gar nicht verhindert werden, anders würden Passwort-Felder gar nicht funktionieren. Die Verschlüsselung muss auf Protokollebene stattfinden, sprich HTTPS, und auf dem Server müssen Passwörter natürlich verschlüsselt gespeichert werden. Aber in deinem Browser liegen Webseiten grundsätzlich unverschlüsselt vor, der Inhalt von Passwort-Feldern ist einfacher Text, HTML kennt keine Verschlüsselung, HTML ist eine reine Auszeichnungssprache, nicht mehr. Und wenn du eine Webseite ansiehst, dann ist das nicht mehr als die Darstellung von etwas in HTML.

Bei dem Beispiel weiß ich ehrlich nicht, wie ich es noch einfacher erklären soll... mit Webseitenerstellung hast du nicht viel am Hut, oder? Wenn etwas nicht geht, dann merkt man das in der Regel, ja. Und weiter? Du hast ja von Fehlersuche gesprochen, nur darum kam mein Beispiel. Fehlersuche heißt ja wohl nicht festzustellen, dass es einen Fehler gibt, sondern herauszufinden, wo der Fehler liegt. In meinem Beispiel war der Inhalt des Feldes wichtig. Und in diesem Beispiel funktioniert das Formular nicht. Um dem Problem auf den Grund zu gehen, musst du den Inhalt des Feldes lesen können, das wäre sehr hilfreich.

Zitat von hurda

Bitte was? Selbst wenn man ein MP gesetzt hat, sind die normalen PWs mit einschlägigen Tools aus der signons.sqlite/key3.db auslesbar, obwohl man das MP nicht kennt?

Lass mich meine Aussage um ein Wort korrigieren: ausreichend. Die Passwörter sind nicht ausreichend verschlüsselt. Nicht verschlüsselt war sicher nicht einwandfrei formuliert, aber halt das, worauf es hinausläuft. Wer Zugang zum Computer hat, hat normalerweise schnell Zugang zum Profil. Und das reicht bereits zum Entschlüsseln der Passwörter, du brauchst nur die Dateien key3.db und signons.sqlite und kommst damit an alle gespeicherten Passwörter im Klartext. Von ausreichendem Schutz kann ohne Master-Passwort nicht die Rede sein.