Apache2 Authentifizierung

[lordg2009]

Hallo allerseits,

Ich nutze apache 2 als Webserver und schütz einige Bereiche mit Passwort. Ich habe zu besseren Absicherung extra sha Passörter erstellt und vor allem ein automatischen IPBan nach 6 Versuchen eingestellt, um BruteForcing zu verhindern. Nun habe ich meinen eigenen Verkehr mittels Wireshark mitgeschnitten, um zu sehen, wie der Browser das Passwort an den Webserver übermittelt, ich habe

GET / HTTP/1.1
Host: ***************
Connection: keep-alive
Authorization: Basic XXXXXXXXXXXXXXXXX
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.110 Safari/537.36
Accept-Encoding: gzip,deflate,sdch
Accept-Language: de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4

Dort bei den ganzen X-Buchstaben ist ein längerer Zeichensalat, der nicht mit dem Passwort übereinstimmt, aber es steht kein Benutzername dabei. Ist das der Hash von Benutzernamen und Passwort in einem?

Vielen Dank

 

[jdcr]

Kein Hash, sondern Benutzername und Passwort (durch : getrennt) im Klartext, das ganze Base64-kodiert.

http://en.wikipedia.org/wiki/Basic_access_authentication

 

[lordg2009]

Ah danke, dass ist sehr interessant. Wird dieses Verfahren bei allen Websites verwendet, die eine Anmeldung benötigen? Könnte ich zum Beispiel mein fb-pw oder forums-pw mitschneiden? Ich denke mal, wenn man https nutzt, ist man aber sicher gegen man-in-the-middle angriffe, oder?

 

[jdcr]

Nee, die meisten Websites verwenden keine HTTP-Authentifizierung (zu erkennen daran, dass der Browser das Passwortfenster öffnet), sondern haben eine eigene Session-Verwaltung mit Anmeldung per HTML-Formular. Https kann als sicher gelten, wenn du aufpasst, dass du wirklich mit dem richtigen Server sprichst (d.h. Zertifikate passen).

HTTP-Auth. wird hauptsächlich von kleineren Seiten eingesetzt und hat den Vorteil, dass es für den Webseitenautor sehr einfach einzubauen ist; er muss nur ein .htaccess-File anlegen. Es überträgt (zumindest in der Basic-Variante) das Passwort aber praktisch im Klartext, denn Base64 hat keinerlei kryptographische Auswirkungen. Deshalb darf man das nur in Zusammenhang mit SSL benutzen. Wenn eine Seite das nicht tut, solltest du die Finger davon lassen.

Wenn eine Seite wie Facebook oder ein Forum die Passwort-Abfrage über ein Formular vornimmt, hängt die Sicherheit von der Implementierung ab. In der Regel wird hier ebenfalls SSL verwendet. Theoretisch käme auch ein Hashing auf Clientseite per Javascript in Frage.

 

[Daaron]

clientseitiges Hashing per JS bringt aber genau 0. Da der JS-Code im Klartext zur Verfügung steht könnte man aus der verwendeten Hash-Methode und dem übertragenen Hash mit nicht sonderlich großem Aufwand das Klartext-Passwort wieder herauslesen.

 

[jdcr]

Das ist so nicht ganz richtig. Tatsächlich ist die verwendete Hashing-Methode fast nie ein Geheimnis (und sollte es auch nicht sein, Stichwort "security by obscurity"). Der Witz an Hashing ist gerade, dass man aus dem Hash den Klartext eben nicht zurückbekommen kann (bzw. nur mit übergroßem Aufwand), auch wenn die Methode bekannt ist.

Richtig ist, dass man in solchen Situationen selten Javascript verwenden wird. Das hat aber vielmehr damit zu tun, dass es langsam ist und keine guten Kryptographie-Bibliotheken zur Verfügung stehen. Außerdem reichen die serverseitigen Techniken im Verbund mit SSL aus. Daher schrieb ich auch "Theoretisch käme [...] in Frage".

 

[Daaron]

Die meisten Hash-Verfahren (MD5, SHA,....) sind auf Geschwindigkeit optimiert. Die sollten normalerweise dazu dienen, Prüfsummen schnell zu generieren. Wenn ich weiß, dass ein Hash mit SHA1 erstellt wurde, und dazu noch den verwendeten Salt kenne, dann muss ich nur ein kleines hochparalleles Script schreiben und damit meine Grafikkarte füttern. Hash-Verfahren kosten keine Zeit und Mühe.

Wenn wir hier hingegen von Crypto-Verfahren reden, die auf möglichst langsame Arbeitsweise getrimmt wurden, liegst du hingegen richtig.

 

[jdcr]

Ich dachte, es müsste aus dem Zusammenhang klar sein, dass ich mit "Hash" einen "kryptographischen Hash" meine. Aber ganz ganz streng genommen hast du recht - also denkt euch bitte oben das Wort "kryptographisch" dazu.

MD5 und SHA sind übrigens durchaus kryptographische Hashfunktionen. Nur sind sie eben mittlerweile veraltet und (teilweise) gebrochen bzw. weisen Schwächen auf. Was übrigens trotzdem nicht heißt, dass man "mit nicht sonderlich großem Aufwand" den Klartext aus dem Hash zurück bekäme. Die bekannten Schwächen bei beiden Verfahren erlauben zunächst einmal nur, Kollisionen zu finden, also verschiedene Klartexte, die auf den gleichen Hash gehen.


Edit: Ich schiebe mal gleich hinterher, um weitere Missverständnisse zu vermeiden: Natürlich reicht es nicht, auf Clientseite das Passwort zu hashen und sonst gar nichts. Mindestens müsste man eine vom Server gesendete Zufallszahl mit hinein hashen. (Außerdem braucht man was gegen MitM, aber das ist bei einer verschlüsselten Leitung auch nicht anders.) Mit meiner Bemerkung oben, die ja ohnehin nur ein Nebensatz ohne jegliche Details war, wollte ich zum Ausdruck bringen, dass der Kanal nicht zwingend verschlüsselt sein muss, um eine Passwortanmeldung sicher durchzuführen. (Wie gesagt, nur akademisch; für die Praxis nicht relevant.)

Dein Vorschlag mit der Grafikkarte ist, wenn ich dich richtig verstehe, einfach eine Offline-Brute-Force-Attacke. Die nutzt aber weniger die Schwäche des Hash-Verfahrens, als vielmehr die des Passworts. Ist dieses genügend lang, hast du keine Chance. Ist es genügend kurz, kann es bei known ciphertext immer gebrochen werden. Die Komplexität der verwendeten Hashfunktion oder des Verschlüsselungsverfahrens geht dabei nur als konstanter Faktor in die Rechenzeit ein.

 

[Daaron]

Die Länge des Passworts spielt kaum eine Rolle, genauso wenig wie die Komplexität. Selbst etwas lausiges wie eine GTS 250 berechnet dir mit der richtigen Software >400 Mio MD5-Hashes pro Sekunde (und >100 Mio SHA1). Was eine Gamer-Grafikkarte mit solchen Hash-Verfahren anstellt muss ich dir also nicht erst erklären.

Selbst wenn durch Länge und Komplexität des Passworts also ein paar Milliarden Varianten möglich wären, einen MD5- oder SHA-Hash knackst du in wenigen Minuten mit ner 200€-GraKa.

Der einzig korrekte Weg um so etwas zu verhindern ist die Verwendung von mutwillig langsamen Hash-Verfahren wie sie z.B. bei der PHP-Funktion crypt() verwendet werden.

 

[jdcr]

Der Aufwand einer Brute-Force-Attacke wächst linear mit dem Verfahren und exponentiell mit der Länge des Passworts. Jetzt such dir aus, auf welchen der beiden Parameter du dich verlassen willst...

 

[lordg2009]

Naja, wenn ich ein Passwort mit klein, großbuchstaben, zahlen und sonderzeichen habe komme ich ganz schnell auf 80 zeichen.

Ist das Passwort nur 10 Zeichen lang:
80^10=10.737.418.240.000.000.000=10^19 Möglichkeiten
Bei einer Miliarde Hashs pro Sekunde:
10^19 / 10^9 / 60 / 60 / 24 / 365 = 317 (wenn ich mich nicht verechnet habe)
Also dauert es 317 Jahre, um alle Möglichkeiten durchzuprobieren.

Da kann deine Grafikkarte voll abschmatzen, wie auch jede HighEndGraKa, entschuldige die Wortwahl.
Wie jdcr richtig bemerkt hat erhöht sich die Anzahl der Möglichkeiten exponentiell. Wenn auch nur ein Zeichen dazu kommt ist die Anzahl der Möglichkeiten 80 mal so groß, also braucht auch jede Graka 80 mal so lange, um die Möglichkeiten durchzuprobieren. Somit spielt die Länge und auch komplexität des Passworts die entscheidende Rolle und ist ab einer bestimmten Länge nicht mehr zu knacken, außer natürlich über das auffinden von Kollisionen, welches die Anzahl der Möglichkeiten drastisch reduzieren kann.

Ich habe noch eine Frage zu der JavaScript-Hashfunktion. Ich hatte an diese Möglichkeit auch schon gedacht, sie aber wieder verworfen, aus folgedem Grund:
JavaScript wird komplett geladen und auf dem Rechner des Clienten ausgeführt. Somit wird der Hash auf der Seite des Client berechnet, zum Server geschickt und dort mit dem gespeicherten Hash verglichen. Meiner Vermutung geht dieses Procedere aber am Sinn der Hashfunktionen vorbei, da man in diesem Beispiel doch einfach den Hash mitschneiden könnte und im folgenden immer direkt den Hash übermitteln kann und das Passwort gar nicht mehr benötigt.
Wie schon erwähnt darf der Hash und auch die Hashfunktion durchaus bekannt sein, bloß muss die Berechnung des Hash auf dem Server erfolgen, auf den nur Root Zugriff hat, denn wenn der Server schon fertig berechnete Hashwerte vergleicht, ist das schließlich nichts anderes, als würde ich lange komplexe Passwörter einfach nur vergleichen: Ergibt doch kein Sinn.

Zum Schluss noch eine Frage zu der von dir genannten SSL Übermittelung. Wenn ich mich bei der Bank anmelde, erscheint das https und das Zertifikat im Browser, aber sonst trifft man es doch eher selten an. Hier im Forum existiert es doch auch nicht, oder doch?

 

[jdcr]

Ich habe noch eine Frage zu der JavaScript-Hashfunktion. Ich hatte an diese Möglichkeit auch schon gedacht, sie aber wieder verworfen, aus folgedem Grund:
JavaScript wird komplett geladen und auf dem Rechner des Clienten ausgeführt. Somit wird der Hash auf der Seite des Client berechnet, zum Server geschickt und dort mit dem gespeicherten Hash verglichen. Meiner Vermutung geht dieses Procedere aber am Sinn der Hashfunktionen vorbei, da man in diesem Beispiel doch einfach den Hash mitschneiden könnte und im folgenden immer direkt den Hash übermitteln kann und das Passwort gar nicht mehr benötigt.
Wie schon erwähnt darf der Hash und auch die Hashfunktion durchaus bekannt sein, bloß muss die Berechnung des Hash auf dem Server erfolgen, auf den nur Root Zugriff hat, denn wenn der Server schon fertig berechnete Hashwerte vergleicht, ist das schließlich nichts anderes, als würde ich lange komplexe Passwörter einfach nur vergleichen: Ergibt doch kein Sinn.

Stimmt. Wie gesagt, man braucht noch mehr. Ein erster Ansatz wäre, dass der Server eine Zufallszahl schickt und der Client diese an das Passwort anhängt, bevor er den Hash bildet. Allerdings gibt es mit diesem extrem simplen Protokoll noch weitere Probleme. Kryptographie ist leider oft kein einfaches Unterfangen.

Zum Schluss noch eine Frage zu der von dir genannten SSL Übermittelung. Wenn ich mich bei der Bank anmelde, erscheint das https und das Zertifikat im Browser, aber sonst trifft man es doch eher selten an. Hier im Forum existiert es doch auch nicht, oder doch?

Ganz so selten zum Glück nicht. Jeder ordentliche Online-Shop sollte SSL verwenden, zumindest sobald man aufgefordert wird, Adress- und/oder Bankdaten einzugeben. Die meisten tun das auch. In ein unverschlüsselt übertragenes Formular würde ich nie meine Kreditkartennummer eingeben.
Das Forum hier scheint tatsächlich kein SSL zu haben. Wird wohl nicht als kritisch genug angesehen. Man sollte aber aufpassen und z.B. für die Registrierung hier kein Passwort verwenden, das man auch für wichtigere Dinge benutzt.

 

[lordg2009]

Ich habe gerade mit Wireshark die Pakete beim Authetifizieren mitgeschnitten und tatsächlich, es sind einige TLS1.1 Pakete mit verschlüsseltem Inhalt dabei, obwohl es doch eigentlich eine normale http verbindung ist, jemand eine Idee, wie das funktioniert? Würde mich sehr interessieren, da ich selbst einen kleinen Webserver mit der .htaccess Methode betreibe, mein eigenes Passwort jedoch schon mitgeschnitten und von base64 dekodiert habe.

Bei den mitgeschnittenen Paketen enthält das erste sofort verschlüsselte daten, müsste nicht zuerst ein Schlüsselaustuasch stattfinden? Oder zumindest ein gemeinsames Geheimnis im Klartext berechnet und die dazu nötigen Daten im Klartext übermittelt werden?
Wie gesagt, ich habe angefangen die Pakete mitzuschneiden, kurz bevor ich auf einloggen geklickt habe. Somit war das einloggen die erste Handlung, aber auch sofort verschlüsselt.

 

[jdcr]

Hm, stimmt, ich sehe gerade - da ist doch SSL. Wie es genau gemacht wird, fragst du am besten einen Admin. Dürfte einfacher sein als reverse engineering...

 

[Daaron]

CB hat vor n paar Tagen auf HTTPS im Login umgestellt.