nicht angemeldet
Moin!
Es freut mich, einen kritischen Ansprechpartner zu haben. Aber ...
Warum? Benutzername und Passwort sind auch statisch - wer das kennt, kommt rein
Da ist klar. Ich gehe mal davon aus, dass Benutzer ihre Passwörter nicht mit einem PostIt am Bildschirm hinterlassen. Mir geht es eher um alle anderen Fälle.
Dass der Benutzer diese Angaben auch "abgreifbar" für Menschen notieren könnte, das ist in meiner Betrachtung irrelevant.
Dein Server muß, damit es überhaupt zu einer gültigen Session (ob nun mit oder ohne wechselnde Session-ID) kommt, irgendwo und irgendwann diese zwei Informationen erhalten.
Ein Angreifer kann dorthin ebenfalls beliebig viele Usernamen und Passworte als Einbruchsversuch hinschicken. Weil diese Informationen statisch sind, erhält er mit Glück, oder nach genügend langer Zeit mit Rumprobieren, irgendwann korrekte Strings.
Das bedeutet: Du sorgst dich darum, dass jemand deine existierenden Sessions angreifen kann (dazu muß der Angreifer auch erstmal die Session-ID richtig raten!), sorgst dich aber nicht um Username und Passwort - wobei doch gerade Passworte, die der Benutzer selbst setzen kann, oft die größte Sicherheitslücke bilden.
Wenn man dem Server als Angreifer den richtigen String schickt, wird dieser Informationen rausrücken.
Darum gehts mir. Sitzt ein Böser zwischen Client und Server, kann er entweder die aktuelle verschlüsselte Session-Id abfangen und sogar an den Server weiterschicken. Er erhält dann auch eine Antwort - kann aber mit der neue Session-Id nix anfangen, da er ja nicht weiß, wie diese korrekt zu verschlüsseln wäre.
Wenn er wirklich zwischen Client und Server sitzt, dann liest er einfach nur mit. Die korrekten wechselnden Session-IDs werden vom Client produziert.
Alternativ bildet er gegenüber dem Client einen Server, und gegenüber deinem Server einen Client. Er reicht deine Serversession-ID zum Client durch, nimmt dessen Berechnung entgegen und gibt sie wieder deinem Server. Und alles wird funktionieren.
Das hilft dir alles nichts, wenn du unverschlüsselt arbeitest.
Das ist die leichteste Übung - ich brauch ja nur https zu verwenden. Ich möchte aber die ganze Logik möglichst sicher haben, bevor ich das ganze auch noch verschlüssle.
Aber die Frage mal andersrum: Kann ich mir den ganzen Schmarrn sparen, wenn ich NUR https verwende und einfach in jedem Request Benutzername und Passwort mitschicke?
Du kannst dir den ganzen Schmarrn sparen - so oder so. SSL bringt dir Verschlüsselung und damit Sicherheit gegen Abhören des Datentransfers.
Rechne doch mal selbst hoch, wie wahrscheinlich es ist, dass jemand die Standard-Session-ID mit 128 Bit "errät".
Angenommen, man könnte als Angreifer in jeder Sekunde eine Milliarde Session-IDs prüfen. Und angenommen, es würden zu diesem Zeitpunkt tatsächlich eine Milliarde Session-IDs von Nutzern aktiv sein.
Das bedeutet:
2^128 = 3.4e+38 mögliche IDs
1e+9 gleichzeitig aktive IDs
Statistisch ist also jede 3.4e+29ste Session-ID aktiv.
Um 3.4e+29 Session-IDs zu prüfen, mit 1e+9 IDs pro Sekunde, sind 3.4e+20 Sekunden notwendig oder 1.1e+13 Jahre. Durchschnittlich ist man nach der Hälfte der Zeit fertig: 5.5e+12 Jahre. Das ist immer noch hundertmal länger, als unser Universum alt ist (1.34e+10 Jahre).
Mit Pech (auf deiner Seite) dauert die Suche genau eine Sekunde, weil gleich die erste Session-ID gefunden wird. Dann ist aber wahrscheinlich, dass jemand die Kommunikation belauschen konnte. Deswegen ja SSL.
- Sven Rautenberg
"Love your nation - respect the others."