Gespeicherte Passwörter im Browser: Speichert Ihr noch oder verliert Ihr schon?

Aktuell wird Firefox durch den Fleischwolf gedreht. Kurz gesagt, der „Safe“ der Passwörter wird mit dem als gebrochen geltendem SHA-1-Algorithmus abgesichert, aber darauf will ich nicht eingehen. Auch der potenzieller Angriffsvektor auf die Passwortdatenbank ist nicht Bestandteil dieses Artikels.

Eher will ich mal das grundsätzliche Problem ansprechen, das Passwörter zwar mit ordentlich Crypto im besten Fall verschlüsselt werden, aber dann (mehr oder minder) ungeschützt in die Seite eingebunden werden. Und das ist ein generelles Browserproblem.

Das ist ein Kommentar. Der Text könnte eine gewisse Note Sarkasmus enthalten.

Zunächst einmal sei der Prozess erklärt, der im Browser vorgeht, um ein gespeichertes Passwort darzustellen.

Grob gesagt legt der Browser das Passwort (hier „meinpasswort“) unter zuhilfename eines Cryptographischen Algorithmus (z. B. SHA256) in Form eines Hashs (im Beispiel z. B. $1ab414, stark stilisiert) ab.

Wird nun eine Seite besucht, zu der ein gespeichertes Passwort (ggf. in Kombination mit Benutzernamen in Formularen) vor, wird es aus dem „Safe“ herausgeholt und als „*****“ dargestellt.

Ab dem Punkt, bei dem das Passwort in der Webseite dargestellt wird, sehe ich aber das eigentliche Problem.

Warum das so ist, möchte ich nun erläutern.

Alle Elemente einer HTML-Seite liegen in einem so genannten Document Object Model, kurz DOM. Der DOM ist grob gesagt ein Baum, in dem alle Elemente eingeordnet sind. Auch Passwortfelder.

Passwortfelder sind in HTML nichts weiter als Eingabefelder vom Typ Passwort, sprich ein Textfeld mit maskiertem Inhalt. Problem daran: Die Sicherheit des gespeicherten Passworts ist nun nicht mehr in der Hand des Browsers, sondern in der des Webseitebetreibers. Hat nun diese Seite Sicherheitsprobleme (Stichwort XSS) können die Passwörter abgefischt werden, noch bevor der Benutzer das Formular überhaupt abschickt.

Bevor man mich jetzt falsch versteht: Ich weiß, dass das Problem an dieser Sache ist, dass man darauf angewiesen ist, dass das so „plain“ dort liegt. Es wird ja auch beim Abschicken so an den Server verschickt, und der brauch das Passwort ja auch in Klartext (ich spreche hier im Sinne der Übertragung z. B. auf HTTP-POST-Ebene und nicht auf Verbindungsebene!). Und auch bei JavaScript-basierenden Anwendungen, die das Ganze als XHR-Requests an eine API schicken, ist es ähnlich.

Daher ist es umso wichtiger, das auch zusätzliche Schutzmechanismen des Browsers, z. B. CSP) eingesetzt werden. Zumal ich mit diesem Artikel eher auf diese Diskrepanz zwischen der Verschlüsselung auf dem Passwortsafe und der de facto nicht vorhandenen Kryptographie bei der Darstellung hinweisen will. Und eigentlich müsste man an dieser Stelle einen geeigneten Lösungsweg finden, aber der Ball liegt eher bei den Browserherstellern als bei den Seitenentwicklern. Und bis dahin sollte man sich eher zwei mal überlegen, ob man seine Passwörter im Browser speichert. So, jetzt hab ich aber genügend Konjunktionen für Satzanfänge verwendet :).


Schlüsselicon: https://commons.wikimedia.org/wiki/Category:Yellow_key_icons#/media/File:Icons8_flat_key.svg, MIT

Bild: https://stocksnap.io/photo/D6BZSQ2NM2

Christoph

Programmierer. Linuxuser. Blogger. Macher vom Distrochooser. Auch unter me@0fury.de erreichbar (PGP).

Das könnte Dich auch interessieren...

4 Antworten

  1. Julius sagt:

    Und bis dahin sollte man sich eher zwei mal überlegen, ob man seine Passwörter im Browser speichert.

    Um das Problem zumindest etwas abzumildern, kann man Firefox anweisen, die Login-Daten nicht automatisch einzutragen. Das würde gegen versteckte Eingabefelder helfen, mit denen versucht wird, Passwörter abzugreifen. Voraussetzung ist natürlich, dass das Login-Formular bzw. die Seite, auf der es sich befindet, nicht kompromittiert ist…

    • Christoph sagt:

      Die Passwörter werden dann nachträglich in das Formular eingebunden. Problem an der Sache: Wartet man gezielt auf das Ereignis, dass beim Ausfüllen ausgelöst wird, so kommt man immer noch an das Passwort ran.

      Aber wie du schon korrekt angemerkt hast, wenn die Seite kompromittiert ist, bringt das auch noch kaum was. Alles insgesamt eher unbefriedigend.

  2. Moritz sagt:

    Vielleicht kann man irgendwann dank Web Crypto API ja endlich komplett auf per JavaScript und HTTP(S) übermittelte Passwörter verzichten, vorausgesetzt natürlich es gibt eine sinnvolle Backup-Strategie und gute UX dafür.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.