Session Variante sicher?

[Sven Rautenberg]

Moin!

Also man hat ein Forumular.
Dort gibt man Username + PW an. Das wird dann überprüft

Das sind ZWEI Schlüssel.

Nun startet die Session und Du hast nur noch EINEN Schlüssel. Einen Schlüssel kann man aber raten, ohne dass das Programm das erkennen kann. Wie hoch die Wahrscheinlichkeit ist, dass dieser Schlüssel erraten wird, dafüber gibts hier dutzende Threads. Aber es ist zumindest theoretisch unsicher.

Einspruch. :)

Natürlich macht es _vielleicht_ Sinn, die Anzahl fehlerhafter Login-Versuche mitzuzählen. Die andere Seite der Medaillie ist dann aber, dass eine Sperrung sich wunderbar eignet, als Denial-of-Service ausgenutzt zu werden, damit eine fremde Person durch falsche Logins alle User aussperren kann. Das wäre blöd.

Wenn nun aber das Aussperren von Usern nicht geschehen darf, bleibt als Resultat für den Angriff nur die Notwendigkeit, eine gewisse Anzahl von Zeichen zu raten.

Es ist, ausgehend von diesem Standpunkt, egal, ob man nun "username+passwort" als Insgesamt-String richtig raten muß, oder ob es "sessionid" ist. Hauptsache, man hat viele Möglichkeiten, zu raten, damit es der Angreifer nicht zu leicht hat.

Die PHP-Sessions nutzen eine 128-Bit-Zahl (in hexadezimaler Darstellung) als ID. Also sind 2^128 verschiedene IDs möglich. Grob 3,4028236692093846346337460743177e+38 verschiedene Möglichkeiten.

Mal überschlagsmäßig gerechnet: Man kann nur aktive Sessions "übernehmen". Gehen wir mal von einer Milliarde aktiver Sessions aus (was immerhin ein sechstel oder siebtel der Weltbevölkerung ist, die _gleichzeitig_ auf dem Server rummachen würde). Dann hat man durchschnittlich schon nach 3,4e+29 Versuchen eine aktive Session-ID gefunden. Wie lange braucht man dafür? Wenn man pro Sekunde wiederum genau eine Milliarde Session-IDs prüfen könnte, würde man 3,4e+20 Sekunden brauchen, um durchschnittlich mit Sicherheit eine aktive ID zu finden, vielleicht auch nur die Hälfte der Zeit: 1,7e+20 Sekunden. Also grob 5e+12 Jahre (in Worten: 5 Billionen Jahre). Da ja mindestens 128 Bit = 32 Byte an Daten zur Übermittlung der Session-ID übertragen werden müßten, benötigte man dafür eine Datenrate von 3,2 Gigabyte pro Sekunde - das wäre immerhin schaffbar. Dummerweise ist ein HTTP-Request nicht so klein, alleine das würde also die Anzahl der Tests pro Sekunde beschränken.

Natürlich kann man auch durch dummen Zufall gleich beim ersten Versuch richtig raten und spart sich die restlichen 5 Billionen Jahre. Dann allerdings sollte man auch unbedingt Lotto spielen, da sind die Chancen, mal 6 Richtige mit Zusatzzahl zu kriegen, wahnsinnig viel höher.

Eine Session-ID hat außerdem den Vorteil, dass man sie nicht über social engineering rauskriegen kann, weil sie von einer Maschine generiert wird und hoffentlich ziemlich zufällig gewählt ist.

Damit keiner Schindluder treibt, sollte man auch Loginnamen wie Passwörter behandeln.

Das ist genau das Problem, bzw. Kern der Sache: Der Username ist wie ein Passwort zu behandeln, weil er Bestandteil des Passwortes ist, ihm sozusagen hinzugerechnet werden kann.

Ist das Sicher oder kann man das ganz einfach überbrücken?

Nein, das ist nicht sicher. Ja, das kann man überbrücken, indem man die richtige Sessionnummer errät oder einfach aus dem Script ausliest (bei TRANS_SID = 1).

Falsch. Die Frage ist, wie in der Session der Status "eingeloggt" gesetzt wird. Diese Überprüfung der Authentifizierungsdaten wäre angreifbar - ist hier aber nicht dargestellt.

"Sicher" ist nur ein Zweischlüsselverfahren, bei dem bei jedem Zugriff die Login-Rechte aufs Neue geprüft werden.

Das ist absolut falsch - sofern man sich keine dummen Fehler einbaut, die ausgenutzt werden könnten.

- Sven Rautenberg