Login mit Session - Tutorial gesucht

[Sven Rautenberg]

Moin!

Das soll heißen, dass man gerade aktive Session-Schlüssel erraten kann.

Das bezweifle ich doch extrem! Zumindest was den Standardmechanismus für PHP angeht.

Das erstaunt mich nun wiederum!
Du weißt doch schließlich um die Fachausdrücke, oder?
Hier liegt "Erratbarkeit" vor.

Wenn die Aufgabe lautet "Wie lautet meine Zahl zwischen 1 und 50?", und als einzige Antwort kommt "falsch" oder "richtig", dann wird der Gefragte nicht drum herum kommen, alle Zahlen durchzuprobieren. Er kann das in beliebigen Mustern tun, aber er wird statistisch durchschnittlich 25 Versuche benötigen. Das nennt man dann "Brute Force".

Ein Ratespiel mit besseren Erfolgsaussichten wird daraus erst, wenn der Gefragte bessere Hinweise erhält, die ihn bei der Lösung der Aufgabe unterstützen. Beispielsweise durch "Meine Zahl ist kleiner/größer als dein Tipp."

Übersetzt auf Session-IDs bedeutet das: Der Gefragte müßte aufgrund von Meßergebnissen, die er selbst auf reguläre Weise machen kann, beispielsweise die ihm zugeteilten Session-IDs, Rückschlüsse auf andere existierende Session-IDs oder zumindest den in der letzten Zeit benutzten Wertebereich von Session-IDs machen können, um eben gerade nicht den Gesamtbereich von 2^128 Werten testen zu müssen (ein Versuch, der eben aufgrund der schieren Zahl an Möglichkeiten scheitern wird).

Das bedeutet im Klartext, dass beim zufälligen oder absichtlichen Treffen eines Schlüssels durch einen Unbefugten keine weitere Erkennung vorliegt.

Die Aussage stimmt natürlich: Wenn eine Session existiert, kriegt jeder Request, auch der von unbefugten Dritten, die Antwort mit dem derzeitigen Session-Status. Ist die Session gerade auf "eingeloggt", wäre auch der Dritte eingeloggt.

Das Problem ist dabei eben "nur", so eine Session-ID zu raten.

Dein vermeintlicher Lösungsansatz ändert daran aber nichts. Weiterhin muß man einfach nur die richtigen Zeichen in der URL platzieren, um Zugriff zu erhalten. Das mögen ein paar Zeichen mehr sein, was den Aufwand multipliziert (von "komplett unmöglich in einem Menschenleben" hin zu "komplett unmöglich in einem Menschenleben" - es ändert sich also nichts), wenn man nur ohne Hilfestellung alles durchprobieren muß, aber es nützt absolut nichts, wenn man auf irgendeine Weise eine gültige Kombination erfährt.

Das geht besonders gut, wenn Schlüssel aufgrund der Vergabeverfahrens mit Hilfe der Zeitkomponente erteilt werden. Dann vermindert sich nämlich der verfügbare Schlüsselvorrat auf eine sehr überschaubare Zahl.

Die zeitliche Komponente sorgt aber, vor allem dann, wenn man sehr genau mißt, für eine gute Zufallskomponente, insbesondere wenn man danach Hashverfahren wie MD5 nachschaltet und noch ein paar weitere Daten mit einfließen läßt. Damit ist aus der selbst erhaltenen Session-ID keinerlei Rückschluß auf die dabei eingeflossene Zeit und auch nicht auf mögliche Nachbarsessions möglich.

Zusätzliche "Wiederverwirrspiele" können einen eingeschränkten Schlüselvorrat tatsächlich fast auf ihren eigenen vollen Umfang (also den Schlüsselvorrat des Verwirrspiels) abbilden, aber nicht wieder auf den ursprünglichen spreizen. Außerdem ist das Verfahren bekannt und damit von dem ursprünglichen eigeschränkten Vorrat jederzeit replizierbar nachvollziehbar.

Bitte denke nochmals nach. Das ist einfachste Mengenlehre.

Hast du dir jemals den Code in PHP, der zur Erzeugung einer Session-ID benutzt wird, angesehen? Wenn ja, würdest du nicht behaupten, dass dessen Resultat "einfach angreifbar" wäre.

In dem MD5-Hash fließt ein:
1. Die "REMOTE_ADDR" des Requests, wenn vorhanden.
2. Die aktuellen Sekunden
3. Die aktuellen Mikrosekunden
4. Ein Zufallswert

Wenn gewünscht und konfiguriert, werden noch weitere Bytes aus einem Entropiefile hinzugefügt. Das Manual spricht von /dev/random oder /dev/urandom als typischer Quelle.

Das Ergebnis würde ich als ziemlich zufällig und nicht erratbar bezeichnen. Ebenso sind die MD5-Hashes dieser Zufallswerte dann nicht vorhersagbar. Und wem das nicht reicht, weil MD5 zuwenig mögliche Werte erzeugt, der kann seit PHP 5.0.0 auch SHA1 als Algorithmus wählen, und somit die Wertemenge von 2^128 auf 2^160 erhöhen, die man bearbeiten muß.

Ansonsten darfst du gerne einen Beispielangriff demonstrieren.
Das ist doch eher rhetorisch von Dir und damit äußerst unfair, da Du doch weißt, dass ich sowas niemals demonstrieren würde

Nein, das ist nicht rhetorisch, das ist ernst gemeint. Hast du schon einen entsprechenden Angriff praktisch konstruiert, oder hast du ihn dir bislang nur theoretisch ausgedacht?

Wenn du schon einen praktischen Angriff auf die Session-Generierung von PHP entwickelt hast, solltest du schleunigst die Entwickler von PHP kontakten und ihnen deine Erkenntnisse mitteilen. Erratbare Session-IDs sind in der Tat böse.

Allerdings bezweifle ich, dass du den praktischen Beweis deiner Theorie bringen kannst und Session-IDs gefährdeter sind, als durch Durchprobieren aller Möglichkeiten.

Daher sollte man für ein vernünftiges Session-Management immer ZWEI Schlüssel erteilen, die beide vorhanden sein müssen. Damit reduziert sich die Trefferwahrscheinlichkeit erheblich.

Jetzt kommt dieser Unsinn wieder.

Ich werde Dir anstelle eines Beispielangriffes lieber ein paasr etablierte Mathematiker liefern, die Dir meine Überlegungen bestätigen werden. So langsam reichts mir nämlich mit Dir ;-))
Also werde ich's jetzt langsam mal in Angriff nehmen und die Unis beballern...

Wie erwähnt: Ich bestreite nicht, dass "Size matters". Je mehr mögliche Werte die Session-ID hat, desto schwieriger wird man sie erraten können.

Ich bestreite nur, dass es irgendeinen Unterschied macht, eine längere Session-ID auf zwei oder mehr Teile aufzuteilen.

Oder willst du etwas anderes tun?

Du hast hier einige Mechanismen und die Logik dahinter scheinbar noch nicht verstanden.

Dann hast du es noch nicht gut genug erklärt.

Wir haben oft genug darüber diskutiert. Ein Sessionverfahren ohne Prüfverfahren ist (zumindest theoretisch) ein offenes Scheunentor.

Das bestreite ich. Ein Sessionverfahren beruht darauf, dass die Zahl aktiver Sessions deutlich kleiner ist als die Zahl möglicher Session-IDs, dass man die Session-IDs nicht vorhersagen kann (Zufallseinfluß), und dass ein Durchprobieren aller Werte so zeitaufwendig ist, dass es nicht in angemessener Zeit zum Erfolg führen kann.

Es mag zutreffen, dass ich auf meinem 486/DX266 in angemessener Zeit mit einem guten Assemblerprogramm keinen vernünftigen Schlüssel finden werde, also einen, der passt, aber wer hat denn heute noch solche Geräte im Einsatz?

Deine Argumentation ist fehlerhaft. Ich gehe nicht von irgendwelchen real existierenden Maschinen aus.

Denk dir einen Computer aus, den du für topaktuell hälst. Gib ihm eine Leistungsfähigkeit der Form "Geprüfte Session-IDs pro Sekunde". Multipliziere diesen Rechner mit einem Faktor "gleichzeitig eingesetzte Maschinen". Vergleiche mit 2^128 möglichen MD5-Werten. Errechne die Zeitdauer, um den gesamten Wertebereich einmal durchzuprüfen.

Vorlage:
Nehmen wir 10 GHz als Taktfrequenz und setzen 1 Takt = 1 Prüfung. Nehmen wir außerdem 6 Milliarden Rechner (jeder Mensch hat einen).

Diese Werte sind sicherlich etwas übertrieben für die heutige Zeit, aber nicht unrealistisch.

Damit ergibt sich: 10000000000 (1e+10) Prüfungen pro Maschine mit 6000000000 (6e+9) Maschinen ergibt 6e+19 Prüfungen pro Sekunde.

Dann dauert die Prüfung von 2^128 Werten gerundet 5,6713727820156410577229101238628e+18 Sekunden. Oder auch 1,7983805118010023648284215258317e+11 Jahre.

Wie schon mal erwähnt: Das Universum ist 13,5 Milliarden Jahre alt, oder auch 1,35e+10. Wir brauchen also schon mehr als 10 Universumsleben, um all die Werte durchzuprüfen - geschweige denn dass wir in die Nähe eines Menschenleben kommen.

Von der notwendigen Bandbreite, die man für diese Prüfung benötigen würde, mal ganz abgesehen.

Gewiß, mit steigender Rechnerleistung wird MD5 als Session-ID-Algorithmus nicht mehr so angenehm sein, aber SHA1 steht bei PHP schon in den Startlöchern (würde 7,9192547798915793095202439697572e+20 Jahre brauchen), die nächsten Generationen von SHA (256, 512 etc.) sind ebenfalls verfügbar.

Der Einzige Schutz, der hier besteht, ist die eingeschränkte Response-Time (also die relativ lange) gepaart mit der verfügbaren Bandbreite der Netze, die heute existieren.

Die Bandbreite ist ein zusätzlicher, limitierender Faktor, der praktische Angriffe unmöglicher macht. Aber wenn selbst ein theoretischer Angriff mit leicht unrealistischer Hardware und großen Zahlen an Parallelität nicht in einem Universumsleben zum Ziel kommt, dann halte ich ein Verfahren, dass diesem Angriff standhält, für ausreichend sicher.

Zumindest sollte man sich dann viel eher fragen, wie sicher denn eigentlich Usernamen und Passworte sind, und ob die einem Brute Force genauso gut standhalten würden.

- Sven Rautenberg