nicht angemeldet
Nochmal Moin!
Wie meine nachfolgenden Überlegungen ergeben haben, ist es vollkommener Quatsch, einen Zeitstempel oder irgendwelche sonstigen Zusätze zu benutzen: Das verlängert im Endeffekt nur die Session-ID, man hat also mehr Variantionen und entsprechend mehr Zeitaufwand beim Raten.
Nein, das sehe ich absolut anders! Du mußt nicht immer von irgendwelchen Profi-Crackern ausgehen(die würden die Versuche hier eh nur belächeln :-)), aber es gibt ja zig Schattierungen, und je mehr Features man da einbaut desto kleiner wird der Kreis der Leute, die tatsächlich noch Schaden anrichten können!
Wenn man ein sicheres System basteln will, muß man von Profi-Crackern ausgehen. Und ich würde nicht behaupten, daß die hierüber lächeln würden. Im Zweifel würden die andere Angriffspunkte finden, aber eher nicht die Session selbst angreifen.
Und nicht nur das: der Angreifer weiß ja nicht, was man da noch verwendet - die SessionID sieht er sofort und kommt da recht problemlos dran, z.B. über irgendwelche referer-Logs. aber da stehe ja garantiert keine Cookie-Daten drin, also um an die Cookiedaten zu kommen, müßte er entweder auf den Clientrechner, was wir hier ja ausklammern wollen, oder die Verbindung irgendwo belauschen, und das ist nicht so einfach denke ich.
Die Session-ID ist dann im Referrer, wenn kein Cookie verwendet wurde. Entweder - oder.
Sieh es doch einfach mal aus Angreifersicht:
Der Angreifer sieht folgenden Referrer-Bestandteil:
?SESSID=lkgsedfzuiz2978swefhiase67aw4a8wrhiuaw4zp98zhuiaw4z879paw4
Frage: Welcher Teil dieses Strings ist die eigentliche Session-ID, welcher Teil ist der Timestamp, und welcher Teil ist der User-Agent? Oder welche anderen Teile sind dort verwurstelt?
Die Antworten auf die Frage ist total egal. Wenn man den Referrer im Browser aufruft, dann führt diese Session-ID dazu, daß der Server eine Seite ausliefert.
Warum? Weil in der URL alle Informationen codiert sind, die auch der reguläre Browser mitsenden würde. Es ist vollkommen uninteressant, ob der Server die ID zerlegt, einen Zeitstempel prüft, oder sonstwas an den Browsereigenschaften (wobei die ja alle nicht zuverlässig genug sind, weil entweder zu veränderlich, wie die IP oder der User-Agent, oder zu wenig verschieden, wie die Liste der akzeptierten MIME-Typen): Diese komplette ID (sei sie nun komplett oder bereits vorzerlegt) erlaubt den Zugriff auf den Server - der reguläre Benutzer kriegt ihn ja schließlich.
Das einzig interessante ist: Wieviele verschiedene Möglichkeiten hat die Session-ID insgesamt, und wieviele Sessions sind zeitgleich in Betrieb - also: wie erfolgreich ist man beim Raten.
Eine gewöhnliche PHP-Session-ID besteht aus 32 hexadezimalen Zeichen, also 32 * 16 Zeichen. Das ergibt 16^32 verschiedene Session-IDs, also genau 3,4028236692093846346337460743177e+38. Wieviele Sessions laufen parallel? Nehmen wir mal grob eine Million (also 1e+6). Folglich ist die Chance, eine aktive Session zu raten, 1:3,4e+32.
6 richtige im Lotto kriegt man mit der Chance 1:13.983.816 - ich würde dann lieber Lottospielen, als Sessions zu raten.
Aber: Lottospielen kostet Geld, und die Ziehung ist nur einmal die Woche - der Server ist immer ansprechbar.
Rechnen wir mal weiter: Wieviele verschiedene Sessions kann man pro Sekunde prüfen? Wenn der Server nicht total überlastet werden soll, nehmen wir doch mal einfach als Hausnummer 10.000 Sessions pro Sekunde.
Dann braucht man immer noch durchschnittlich 3,4e+28 Sekunden, um die erste Session zu raten. Oder 10^21 Jahre. Das sind 1 Trilliarden Jahre. Das dauert doch eine Weile.
Du siehst also: Sessions raten dürfte reichlich unmöglich sein - da kriegt man Zufallstreffer, und auch die nur sehr selten - wenn der Rest der Serverimplementation ordentlich arbeitet.
Wenn zusätzlich noch SSL zum Zuge kommt, dann ist anhand der übermittelten Verbindungsdaten annähernd ausgeschlossen, daß jemand die belauscht und deshalb ebenfalls Zugriff erlangt.
SSL darf als sicher betrachtet werden - solange man die stärkste Verschlüsselungsstufe mit 128 Bit verwendet. 40 Bit Schlüssellänge sind nicht mehr ausreichend. Ich weiß nicht, wie lange man zur Überwindung solch eines Schlüssels benötigt, aber wahrscheinlich länger, als eine Session andauert.
Auf den Rest gehe ich jetzt einfach nicht mehr weiter ein, denn ich würde die Diskussion einfach einem Ende zuführen. :)
- Sven Rautenberg