Menü
Avatar von Valentin Hilbig
  • Valentin Hilbig

mehr als 1000 Beiträge seit 08.01.2000

Der Typ hat Recht, nur leider nicht in seinem konkreten Fall ;)

Habe mal auf seine Seite gesehen, und das mit dem "wir haben unser eigenes Sicherheitssystem" ist in diesem Fall quatsch.

Allerdings hat der Typ trotzdem Recht!

Jedem muss seit dem Cloudflare-Problem inzwischen bekannt sein, dass es ein gravierender Fehler ist, wenn man das Passwort im Klartext an einen Server übermittelt. Welche Transportverschlüsselung dabei zum Einsatz kommt ist vollkommen unerheblich! Tatsache ist, dass Server das Passwort im Klartext erhalten, und genau das muss aus dem Web verschwinden!

Anders gesagt: https ist zwar besser als nichts, bietet aber nur einen sehr marginal höheren Schutz. Es hilft bei so Dingen wie öffentlichem unverschlüsseltem wLAN. Es mag auch gegen unbeholfene MitM helfen. Aber bei mächtigen Angreifern - das weiß ja inzwischen eigentlich jeder - hilft das nichts - die besorgen sich einfach ein MitM-Zertifikat (beispiel: BlueCoat) und entschlüsseln alles einfach auf dem Transportweg. TLS hilft da nicht die Bohne.

Der einzig richtige Weg, den Nutzer wirklich besser zu schützen, wäre, wenn das Passwort den Browser überhaupt nie verlässt! Es gibt ausreichend Methoden, das zu gewährleisten, sie sind seit Jahrzehnten gut bekannt und werden auch hin und wieder eingesetzt, aber das Web ist diesbezüglich vollkommenes Brachland.

Gegen den Müll, der im Web veranstaltet wird, ist Kerberos Gold! Aber wir wissen, wie gefährlich auch Kerberos ist, wenn es unbedarft genutzt wird. Und lasse die Leute nur machen, irgendwer schafft es, einen Bock zu schießen, der dann zahlreich kopiert und verbreitet wird, und danach haben wir den Salat.

Das muss aufhören. Was wir brauchen ist ein Umdenken in Sachen Sicherheit. Der Browser muss den Nutzer schützen, auch dann, wenn der Server Mist baut. Außerdem brauchen wir mehr als nur Sicherheit auf dem Transportweg:

Wir brauchen Authentizität. Es ist klar bekannt, dass TLS genau das nicht leistet! TLS authentifiziert die Quelle (sofern die CAs vertrauenswürdig sind), aber eben nicht den Inhalt. Es gibt bekannte und im Feld eingesetzte Verfahren, die genau das tun, nämlich den Inhalt gegen Veränderung zu schützen. Diese funktionieren aber auch ohne TLS. Wir wissen: Viele Firmen leben davon, Inhalte, die per TLS gesichert übertragen werden, on the fly zu verändern (z. B. um Werbung einzublenden)! Eine Firma, die das professionell macht, heißt BlueCoat. Das ist keine Fiktion! Das ist real! Es wird vielerorts eingesetzt! Und sehr viele, die davon betroffen sind, die wissen das gar nicht!

Wir brauchen Passwortsicherheit. Passworte sind zwar eine schlechte Form der Security by Obscurity, aber wenn man sie richtig einsetzt - und das zu tun wäre leicht, hätten die Browser das nur eingebaut - dann ist sie aufgrund der Einfachheit nicht zu schlagen. Es ist bekannt, dass alle Verfahren, die zu komplex sind, auf Dauer keine Sicherheit bieten, weil der Mensch aufhört, sie zu nutzen. Das gilt auch für 2nd Factor, außer diese wird so einfach, dass sie nur wenig besser ist als gut gemacht Passworte, aber auch einen höheren Schaden verursachen kann (der bekannte Einlullungs-Effekt). Das Idiom Username+Passwort ist gut bekannt, allgemein akzeptiert und kann gelebt werden. Also sorgen wir doch bitte endlich dafür, dass es auch sicher ist! Die Verantwortung dazu liegt im Browser. Nein, nicht auf der Webseite. Die kann gehackt sein. (Der Browser auch, aber dann betrifft das nur diesen einen Nutzer, und nicht gleich uferlos viele!)

Wir brauchen Vertraulichkeit. Wir brauchen auch hin und wieder die Möglichkeit, Dinge so zu übertragen, dass niemand mitlauschen kann. In diesem Fall wollen wir aber sicher sein, dass die Übertragung frei von MitM ist. Es ist inzwischen allgemein bekannt und akzeptiert, dass TLS alleine das gar nicht leisten kann! Warum gibt es sonst so gefährliche Erweiterungen wie Certificate-Pinning?

Das Interessante dabei ist:

SSL/TLS/https oder wie man es nennen soll, löst nur einen geringen Bruchteil dieser Probleme. Die Tatsache ist, eigentlich braucht man https gar nicht, um alles 3 zu erreichen, denn den wichtigsten Faktor, mit dem man alles 3 bekäme, kann https gar nicht leisten!

https ist wie der sprichwörtliche Hammer, mit dem jetzt auch inzwischen jede Schraube eingehämmert wird, statt dafür das richtige Tool zu nehmen.

Beispiel einer News-Seite:

Ich habe vielleicht überhaupt kein Interesse daran, die Inhalte zu verschlüsseln. Im Gegenteil, ich will, dass sie so viele Leute lesen können wie nur möglich. Also ist https kontraproduktiv. (Ja, es mag Leute geben, die wollen nicht, dass jemand mitliest, was sie lesen. Das ist in Ordnung. Für diese kann ich https anbieten. Aber warum muss ich das bei jedem tun? Warum lässt man den Nutzern nicht die Wahl? Warum gängelt man die Leute, die kein https haben wollen? Solche gibt es, ganz offensichtlich, denn worum geht der Artikel denn sonst eigentlich? Ist der ein Niemand? Sprechen wir ihm die Menschenrechte ab? Gilt seine Meinung plötzlich nicht? Gilt Meinung plötzlich nichts mehr, nur weil sie vielleicht falsch ist? Himmelhergott, das sind essentielle Fragen! Wenn wir hier schon bei den grundsätzlichsten aller Grundsätzlichkeiten ablosen, brauchen wir gar nicht weiter zu über Richtig und Falsch zu disktutieren!)

Ich will aber auch einen Login bieten. Mit einem Passwort. Das gegen Mitlesen geschützt ist. Der Login ist vielleicht nur dafür da, dass man die Gestaltung der Seite anpassen kann und dass der Lesestatus zwischen Devices synchronisiert sowie die Vorlieben besser erkannt werden können. Also voll freiwillig, alles nur zur besseren Usererfahrung und weit und breit keine Datenkrake.

Also mal die ketzerische Frage: Wozu brauche ich dafür bitteschön https? Ich will gar nicht, dass das Passwort bei mir gespeichert werden kann! Ich bin eine Newsseite, keine Passwortdatenbank! Ich will gar keine Passworte bei mir speichern müssen, die ich dann schützen muss! Weil ich mich um News kümmere, nicht um IT-Sicherheit!

Wie macht man das also?

Eigentlich würde ich von den Browsern erwarten, dass sie dieses Problem, das ja nur ein paar tausend Jahre älter ist als der Computer, schon lange bequem gelöst haben. Aber Pustekuchen! Nix dergleichen existiert! Nicht einmal im Ansatz!

Aber man kann es mit einem Shim ja selber nachrüsten. JavaScript to the rescue! Das Passwort zu sichern wird auf den Client verlagert. Ich bekomme nur die per PKI geschützte Übertragung. Ohne irgendwo ein Zertifikat beantragt haben zu müssen das dann auf einem unsicheren Webserver geladen sein muss. Das bedeutet, ich habe das Passwort niemals. Ich kann auch die Schlüsselrunden massiv anheben, da der Server das nicht mehr machen muss. Keine Angst vor eigen-dDoS weil ich die Passwortsicherheit evtl. zu hoch geschraubt habe.

Und nein, natürlich sperrt das niemanden aus. Das kann per Fallback sogar Lynx-kompatibel sein (wenn man denn nur will. Wird zu lang das hier zu erklären. Der Aufwand ist recht überschaubar, das Verfahren gibt es auch schon länger als das Web).

Fazit:

Es wäre leicht, alles 3 zu bieten! Passwortsicherheit, Vertraulichkeit und Authentizität. Und das alles ganz und gar ohne auch nur ein einziges Bit per https zu übertragen.

Das einzige, was etwas schwierig per Shim nachzurüsten ist, ist das mit der Authentizität. Mit der steht und fällt aber eigentlich alles. Denn habe ich einmal Authentizität, kann ich alles andere darauf aufbauen.

Wieso? Es reicht ein authentischer JavaScript-Shim! Mit ihm kann ich dann alles weitere implementieren. Wissen wir aber nicht, ob das JavaScript authentisch ist, steht alles auf tönernen Füßen.

Wäre das Authentikationsproblem also gelöst, wären alle anderen Probleme automatisch gelöst!

Aber genau dort, klafft eine endlose Lücke in den heutigen Browsern. Warum?

Deshalb müssen wir genau dort ansetzen: Wir brauchen ein authentisches und kein verschlüsseltes Web. Im Gegenteil, ich bin der Meinung, https zerstört nachweislich einen großen Anteil vom Web! (und zwar 50%, denn https-only zerstört effektiv die Nutzung von Port 80. Port 80 ist nuneinmal die Hälfte des Web, die andere Hälfte ist Port 443.)

Es ist höchste Eisenbahn dass das Umdenken einsetzt!

Anders gesagt:

Der Typ hat letztendlich Recht. In seinem eigenen Fall zwar nicht, aber im allgemeinen sehr wohl! Es ist vollkommen lächerlich aus dem Nicht-Vorhandensein von https auf die Unsicherheit einer Passwortübertragung zu schließen.

Wenn ich jetzt in meine Webseite ein besseres Verfahren implementiere, das keinerlei https erfordert, warum soll ich bitte https nutzen, nur damit der Browser nicht warnt? Da haben die Browser-Götter ein Dekret erlassen, nutzlos CPU-Leistung zu opfern und unsinnig mehr Komplexität zu erschaffen und evtl. ein Gesamtsystem sogar unsicherer macht (es gab bereits mehrfach Lücken, die nur durch Löcher in den Kryptobibliotheken entstanden. Es ist also immer sinnvoll, wegzulassen, was man im konkreten Fall nicht braucht! Aber klar doch: Bei Virenscannern ist DAS ein gewichtiges Argument. Bei Cryptobibliotheken aber darf man das natürlich nicht sagen! Denn Virenscanner sind bekanntlich Snakeoil, Crypto hingegen ist gut, selbst wenn es vollkommen sinnfrei eingesetzt wird. Leute, so zu denken ist Dogma und nicht Wissenschaft)!

In der letzten Zeit häufen sich die lächerlichen Aktionen, die Einzug in den Browser halten. Erst Public-Key-Pinning, das gefährlicher ist als es nutzt, und jetzt solche Trollaktionen.

Leute, das muss nicht nur aufhören! Dieses ganze nutzlose Bramborium (nicht TLS, das ist immerhin zu etwas nutze. Ich meine PKP und diese oft hirntoten unausweichlichen Crypto-Warnungen im Browser, die eh mehr schaden als nutzen) muss aus den Browsern raus. Das Stichwort heißt, drastische Reduktion der Komplexität! Macht die Teile einfacher statt immer mehr Unsinn dranzuflanschen!

Naja, immerhin erhält das aber die Gültigkeit des 2. Fundamentalsatzes der Thermodynamik, der da lautet: Lasset die Entropie steigen, auf Teufel komm raus!

-Tino
Edit: Tippsfehler korrigiert

Das Posting wurde vom Benutzer editiert (21.03.2017 14:23).

Bewerten
- +
Anzeige