Menü
Avatar von Valentin Hilbig
  • Valentin Hilbig

mehr als 1000 Beiträge seit 08.01.2000

Das ist kein Fehler von Facebook. Der Skandal ist im Browser!

Frage: Wie ist Facebook überhaupt an diese Klartext-Passworte gekommen? Na? Liegt nicht da vielleicht viel eher der Hase im Pfeffer, dass Browser die Passworte frei-haus unverschlüsselt an Facebook aushändigt?

Bin ich tatsächlich der einzige, dem es regelrecht weh tut, dass wir schon 2019 schreiben, der Browser das Passwortfeld aber auch heute noch vollkommen unverschlüsselt an die Zielseite übermittelt?

Ist das nicht der wirkliche Skandal über den wir hier berichten müssten!?!

Wäre das nicht der Fall, dann würde Facebook keine Passworte im Klartext haben können. So einfach wäre das. Weil die Passworte eben nicht nur per TLS verschlüsselt übertragen werden, sondern den Browser gar nicht erst im Klartext verlassen könnten!

Kommt dann Facebook das Ergebnis aus, kann man damit zwar Facebook hacken, aber kommt so nicht in den Besitz des Passworts! Und genau so muss das auch sein, der Browser muss die Nutzer schützen, das kann man keinem obskuren Dritten (wie Facebook) überlassen!

Dass selbst Facebook schlampt, ist genau der Beweis dafür: Die Sicherheit des Passworts gehört in den Browser! Man kann nicht darauf vertrauen, dass andere mit Passworten ordentlich umgehen. (Aber oweh, da fallen ja die meisten Argumente für HTTPS-Zwang weg. Tja .. die Diskussion HTTPS-gut vs. HTTP-scheiße war schon immer eine Scheindiskussion die am eigentlichen Problem vollkommen vorbei geführt wurde. Wer das immer noch nicht sieht oder verstehen will, der darf gerne weiterpennen!)

Warum ist das verschlüsselte Übertragen von Passwortfeldern nicht schon lange der Standard (HTTPS ist eine Transportverschlüsselung, das Passwort kann auch mit HTTPS auf der anderen Seite entschlüsselt werden, genau das gilt es zu verhindern!)? Wen müssen wir dafür schlagen, dass das noch kein Standard ist? Wer hat da immer noch die Zeichen der Zeit (Stichwort Spectre und Co) verpennt? Na, wer? (Antwort auf die rhetorische Frage: Das W3C! Statt zu machen, was jedem out-of-the-box sofort nutzt, machen die sowas total überbordend kompliziertes wie WebAuthn, bei dem uns jeder normale Nutzer verlorengeht. Kotz! Doppelkotz! Dreifachkotz!)

Da liegt doch der Fehler überhaupt!

- Wieso überträgt der Browser Passworte unverschlüsselt an Facebook so dass die an unverschlüsselte Passworte kommen konnten!?!

- Wieso ist da nicht heute schon eine Einweg-Verschlüsselung (per IV) im Standard vorgesehen?

- Wie kann es sein, dass alles, was Du in ein Passwort-Feld tippst, zu 100% reproduzierbar bei irgendeinem Dritten (z. B. Facebook) landet?

- Warum erscheinen bei jedem Kleinscheiß inzwischen gigantische Warnunhinweise mit totaler Verunsicherung des Nutzers im Browser, aber bei den wirklich wichtigen Dingen passiert gar nichts, Business as usual, so wie im letzten Jahrtausend üblich?

Da sollten die Browser mal bitte ASAP nachrüsten!

----------------------------------

Und für alle, die nicht kapiert haben, wie einfach das wäre, hier ein Beispiel (ich sage nicht, dass das so gemacht werden muss. Ich sage nur, dass es so gemacht werden kann, unheimlich einfach ist, absolut backward-compatible wäre und deshalb eigentlich nur bei den Browserherstellern der Wille existieren muss, für etwas mehr Sicherheit zu sorgen):

Da muss ein "IV"-Attribut ins Passwortfeld, das Passwort verschlüsselt dann dieser "IV", und nur das verschlüsselte Ergebnis wird übermittelt (der IV ist für jeden Login gleich, er könnte sogar nutzerbezogen sein, wenn man den Nutzer vor dem Passwort abfragt).

Fehlt dieser "IV", ist nicht ausreichend lang (160 Bit) oder wird mehrfach (auf einer anderen Seite) verwendet, dann sollte der Browser entsprechend vollautomatisch warnen! Und zwar so richtig, mit dem Hinweis an den Nutzer, dass das Passwort kompromittiert ist (weil es den Browser verlassen hat) und er es bitte umgehend wechseln muss (und bei jedem weiteren Mal muss man es einmal mehr abnicken)!

Damit käme bei der anderen Seite nicht das an, was man eintippt, sondern nur etwas, das man zwar auch zum Login auf der Seite verwenden kann, aber das eingegebene Passwort ist weiterhin sicher, da es den Browser nicht verlässt (ja, man kann es mit Brute-Force ermitteln, aber bei einem geeigneten Verfahren ist das relativ unwahrscheinlich)!

Und die Transition ist auch ultraeinfach, ergibt sich quasi vollkommen von selbst!

Die andere Seite (der Server) weiß ja, dass es noch Altaccounts mit altem Klartext-übermitteltem PW gibt. Bei diesen, und nur bei diesen, wird dann, nach dem fehlerhaften Login, das Passwort ohne IV nochmals angefordert. Dann bekommt der Nutzer die Warnung, dass das unverschlüsselt über die Leitung geht und das Passwort deshalb als kompromittiert anzusehen ist, und er es doch bitte verbrennen und wechseln soll! (Macht der Browser!)

(Die Seite sollte dann sofort den Passwortwechsel ermöglichen, aber das muss nicht sein, der Browser warnt ja jedes Mal!)

Nach dem nächsten Wechsel ist das PW dann IV-gesichert und damit alles gut.

Warum gibt es dafür noch keinen Standard? Wir haben 2019!

Und nein, JavaScript bietet eben keine Lösung, sondern ist sogar ein Hauptproblem das man dabei ebenso lösen muss!

Ich erwarte, dass jede Seite, die ein Passwort-Feld hat, frei von irgendwelcher JavaScript-Grütze sein muss! Und dass die Browser das erzwingen und den Nutzer ansonsten ebenso großflächig warnen! Sprich, der Browser zickt dann mindestens so schlimm rum wie bei einem self-signed-Certificate und erklärt, dass das Passwort bereits abgefangen worden sein könnte bevor es überhaupt die Seite erreicht!

Sprich: Sobald ich den Cursor in ein Passwort-Feld navigiere, stoppt jegliche JS-Verarbeitung im Browser. Punkt, aus und Ende! Alles andere wäre Wahnsinn! Nur gehen dann 99% der Webseiten nimmer, also muss man JS per-Default anlassen.

(Lösung dieses Dilemmas könnte z. B. ein Attribut stopjs="true" im Passwortfeld sein. Wenn das gesetzt ist, dann stoppt die JS-Verarbeitung browserweit wenn sich der Fokus im Passwortfeld befindet. Gleichzeitig bekommt JS - und damit meine ich auch Greasmonkey - keinerlei lesenden Zugriff mehr auf das PW-Feld, das Feld wird ein write-only DOM-Knoten - so dass man Passworte eintragen aber nimmer lesen kann.
Fehlt dieses Attribut, bekommt man eine plakative gigantische Warnung, und zwar mindestens so schlimm wie bei self-signed-cert. So werden die Webseiten gezwungen, sich anzupassen. Andere Werte wie z. B. stopjs="false" sind dann offen für Ideen, beispielsweise wird der DOM-Knoten dann ein Proxy, der nur auf das verschlüsselte Resultat Zugriff erlaubt - wichtig z. B. wenn ich Worker habe die das Passwort übermitteln müssen. Einfach nur kurz drüber nachdenken, es ist alles wirklich nicht kompliziert. Das Attribut muss ja nicht "stopjs" heißen. Nennt es meinetwegen "security" oder was auch immer sinnvoll erscheint.)

Spätestens seit Spectre wissen wirklich alle, dass nichts mehr ausgeschlossen werden darf, sobald JavaScript läuft. Aber JavaScript bei Bedarf abschalten, das kann wirklich jeder Browser!

Ich halte das für absolut notwendig. Nicht erst seit heute. Bin ich wirklich der einzige, der da heute "Kassandra Kassandra" ruft?

---------------------------

Und ja, diese Änderung, die ich oben als Beispiel beschrieben habe, ist vollkommen rückwärtskompatibel zu Browsern, die das nicht können! Das kommt man selbst mit chimera von 1996 noch klar oder Lynx (obwohl der die Neuerung vermutlich als einer der ersten drinnen hätte).

Warum? Einfach nur kurz drüber nachdenken! Der IV enthält dann sinnvollerweise den Algorithmus, den man verwendet, also "ALG:IV" (z. B. iv="HMAC-SHA256:12345"). Aus dem eingegebenen PW wird dann der KEY zu "SEC:=ALG(KEY, IV)" berechnet und als "ALG:IV:SEC" übermittelt.

Wenn der Browser das neue Verfahren nicht versteht, übermittelt er das PW im Klartext. Die andere Seite sieht das, weil kein "ALG:IV:"-Prefix da ist. Ergo weiß sie, dass da etwas schief gegangen ist, berechnet selbst "ALG:IV:SEC" und prüft das.

Wenn das stimmt, weiß sie, dass es ein alter Browser ist und kann den Nutzer entsprechend darauf hinweisen, dass das Passwort dadurch verbrannt wurde (und es entsprechend im Account als Klartextpasswort markieren).

Aber die Seite kann noch etwas tun: Sie kann das berechnete "ALG:IV:SEC" anzeigen! Der Nutzer kann sich das dann abschreiben und in Zukunft direkt mit alten Browsern verwenden. Dann geht das PW nur einmal im Klartext über die Leitung.

Und clevere Leute werden das PW dann auch so abrufen.

Ach ja: Der Browser selbst kann dann im Passwort-Safe dann "ALG:IV:SEC" abspeichern. Keinerlei Notwendigkeit, das im Klartext zu tun!

Sprich, auch das unbequeme Master-Passwort (das deshalb kein einziger Nutzer nutzt den ich kenne, sie werden eher grantig wenn man sie darauf hinweist, dass sie ja ein Master-PW verwenden könnten - und sie haben Recht mit dieser Reaktion, denn das ist Menschenunwürdig was der Browser von Menschen verlangt) für den in den Browser eingebauten Passwort-Safe brauchen wir dann überhaupt nimmer.

Oh, ja, die Welt könnte sehr einfach sein. Einfach, unkompliziert, funktional, sicher.

Aber nö, stattdessen heißt es: Idiocracy for President!

-Tino
PS: Und wer meinen Text aus formalen Gründen ablehnt weil er nicht ins eigene Fressschema passt (zu lang, muss man anders schreiben, ist nicht politically correct genug, Tippsfehler, Mozilla-Fanboy, usw.), dem sage ich: Ja genau! Genau so macht man das! Willkommen im Chauvinismus der Political Correctness, willkommen im Land der AFD!

Bewerten
- +
Anzeige