nicht angemeldet
Moin!
Cookies _auch_ für die Session-ID, aber eben nicht nur.
Ich mache das dann mit Trans-SID, mit dem Fallback Mechanismus, falls Cookies nicht akzeptiert werden.
Das ist die übliche Vorgehensweise. Beachte, daß dann die Session-ID im Referrer drinstehen kann und auch an andere Server übertragen werden könnte. Deshalb nicht unbedingt wünschenswert.
Die bisherigen Überlegungen haben ja wohl ergeben, daß Cookies recht privat sind. Niemand sonst kriegt unbeabsichtigt Kenntnis. Also im Prinzip genau identisch, wie eine Benutzeranmeldung.
Das bezweifele ich aber! Ich hatte unbeabsichtigt innerhalb von 2-3 Wochen 3 Trojaner und 5 Würmer auf meinem Computer - ich denke das geht vielen Leuten nicht anders! Und ich bin der Überzeugung, das SEHR viel mehr Leute(Kinder) in der Lage sind private PCs auszuspionieren, als irgendwie den Traffic mitzulauschen, der bei mir SSL-verschlüsselt ist. Und ich denke, das es komplizierter ist, eine Variable aus dem http-Request des Browsers zu erfahren, als einen Cookie zu finden! Den/die kopiert auf den eigenen Rechner und schon geht alles wunderbar! Aber wie ich aus dem Browser die immer mitgeschickte SessionID bekommen sollte, wüßte ich nicht.
Wenn man bei dir unbemerkt Software installieren kann, dann kann man wahlweise am Datenverkehr deiner Netzwerkverbindung lauschen, oder am Tastaturport, wenn du die Paßwörter (dort noch unverschlüsselt) eingibst. Soll heißen: Wenn du deinem eigenen Rechner nicht vertraust, dann verschrotte ihn und geh' niemals mehr online! Denn dann ist ALLES unsicher, was du machst, egal ob dreifach verschlüsselte Paßwörter oder nur Session-ID via SSL übermittelt werden.
Aber was ist das für ein Unterschied ob in DB oder Session? Wenn man den cookie hat ist es jawohl total egal wo das gespeichert ist! Ob man jetzt auf dem Server die Variable aus den Sessendaten ausliest, oder aus der Datenbank ist doch NULL Unterschied, oder? Nur das ich dann mit der DB enweder eine Session-Tabelle bräuchte, oder immer in der Benutzertabelle immer einen Timestamp überschreiben müßte - wobei ich hier natürlich prima prüfen könnte, ob der user nur einmal angemeldet ist, obwohl, das bringt ja nix wenn ich den Echten und den Angreifer nicht unterscheiden kann...
Aber erkläre mir Dein Unbehagen - kann ich nicht nachvollziehen?
Bei Licht betrachtet ist es auch irrational - wenn die Session-ID der Zugangsschlüssel zum Anmeldezeitpunkt ist, den der Server gespeichert hat, ist egal, wo und wie das gespeichert ist.
Wenn dann auch noch dieser Zeitstempel verschlüsselt wird, dann weiß man garnicht mehr, daß es ein Zeitstempel ist, und muß so richtig raten.
Aber ich denke das ein Zeitstemptel sehr beliebt ist, daher bräuchte ich vielleicht noch etwas, eine Kombination aus Timestamp + User Agent, oder aus den get_browser() Sachen, oder? Das dann verschlüsselt sollte schwieriger nachvollziebar sein.
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.
Wenn man dann das ganze noch weiter ausarbeitet, dann hat man im Prinzip eine längere Zeichenkette: 32 Zeichen Session-ID, und beispielsweise weitere 32 Zeichen verschlüsselter Timestamp, also 64 Zeichen. Was unterscheidet diese Zeichenkette nun von einer gewöhnlichen Session-ID? Eigentlich nicht mehr viel. Man kann genausogut 64 Zeichen lange Session-IDs generieren, die ein Angreifer ebenfalls irgendwie raten könnte - er muß ja einfach nur 64 korrekte Zeichen raten.
Hat das denn Sinn das alles in eine Zeichenkette zu machen? Die SessionID muß ja auf ale Fälle im Klartext vorliegen, daher favorisiere ich zur Zeit die Variante mit einem Cookie für SessionID und einem eigenen für die Authentifiztierungs-Konrolle mit Timestamp..., dann halt z.B. md5() verschlüsselt.
Es ist vollkommen egal, ob du Session-ID und weiteres Merkmal separat hälst oder zusammenpackst:
SID = abcdefg
Time= 20020603
Mal ein ganz einfaches Beispiel: Wenn man durch raten in solch ein System eindringen will, muß man 7 Buchstaben und 8 Zahlen richtig raten.
SIDTime = abcdefg20020603
Und bei diesem System muß man 7 Buchstaben und 8 Zahlen richtig raten.
Wenn du den Zeitstempel unverschlüsselt auf dem Server abspeicherst und dann verschlüssel im Cookie beim Browser, änderst du im Prinzip nur den String, der zu erraten ist. Statt 20020603 erscheint dann z.B. 67895674 als verschlüsselter String - viel geändert hat das aber nicht, da man wieder nur 8 Zahlen raten muß, diesmal verschärft um die Aufgabe, daß man nicht mehr so einfach sieht, was da mitgeschickt wird - es ist nicht offensichtlich das Tagesdatum, sondern eine Zufallszahl.
Ich denke, die Diskussion über Session-IDs läßt sich schlicht so subsummieren: Unratbar, wenn sie hinreichend lang ist - sie sollte nur einfach niemandem bekannt gemacht werden. Das ist ein viel größeres Problem. Unverschlüsselte Kommunikation ist dann natürlich ziemlich schlecht - da muß man nicht raten, man lauscht einfach in die Kommunikation hinein und kriegt alles geliefert, was man benötigt. Da ist es dann auch relativ egal, ob Sessions oder Authentifizierung verwendet werden.
Ich würde das aber nicht auf SesionIDs begrenzen, sondern das ist ein grundsätzlicheres Problem, was genau so bei htaccess auftritt!!!
Hab ich doch genau so gesagt.
Wenn man eine unverschlüsselte htaccess-geschützte Verbindung abhört, ist es IMHO _SEHR_ viel einfacher, sich da einzuloggen, als wenn jemand einen md5() verschlüsselten String bekommt, denn bis der entschlüsselt ist ist die Session garantiert schon Monate lang abgelaufen.
Nein, Denkfehler! Die Informationen im Cookie sind ja nur deshalb mit MD5 verschlüsselt, damit die darin enthaltenen Daten nicht so offensichtlich sind. Entschlüsselt werden die auf dem Webserver natürlich auch nicht, weils garnicht geht. Der Webserver erkennt die Session-ID, erfährt so den Zeitstempel, verschlüsselt den nochmal mit MD5 und vergleicht mit den Daten des Cookies. Ist alles identisch, scheint die Session vom berechtigten Rechner fortgesetzt worden zu sein.
Nur leider muß man den ja nicht entschlüsseln, um sich in eine aktuelle Session einzuwählen... aber ist durch die zeitl. Begrenzung immer noch sicherer als htaccess, vor allem da das Passwort nicht erfährt!
Tja, und da kommt eben zum Tragen, daß unverschlüsselte Verbindungen grundsätzlich unsicher sind. AuthType Digest verschlüsselt das Paßwort durch ein Challenge-Response-Verfahren - so erfahren lauschende Angreifer nicht mehr den Zugangsschlüssel, um später nochmal wiederzukommen.
Auch wenn Sessions scheinbar hier einen Vorteil haben: Irgendwann müssen die ja auch mal begonnen haben - mit dem unverschlüsselten Übertragen von Paßwort und Username mittels eines Formulars. Und wer das belauscht...
Übrigens könnte man htaccess ja auch dadurch abbilden, indem man einfach das Passwort und den Benutzernamen in einem Cookie schreibt, und von mir aus verschlüsselt, dann hätte man doch etwa den gleichen Effekt(noch mit Verschlüsselung!), mit dem einen Unterschied, das man per Trojaner... sehr viel einfacher dran kommt. Gibt es def. keine Möglichkeit, auf einem PC die htaccess Zugangdaten irgendwie herauszubekommen? Das kann ich mir nicht vorstellen!
Ich denke schon, daß es irgendwie durch ein installiertes Programm möglich ist, auch im Browser rumzulauschen. Aber wie schon gesagt: Wenn du nicht mal mehr davon ausgehen kannst, daß das gewählte Endgerät sicher ist, dann hast du sowieso ein Problem und kannst sichere Kommunikation total vergessen.
Aber das muß er auch erstmal spitzkriegen, oder? Und kann man so einfach immer zu einem identischen Browser werden? Woher soll er denn die ganzen Einstellungen kennen? Außerem kann er dann nur einen dummen Browser verwenden, kein Tool welches ihm per Bute Force... die Arbeit erleichtern kann. Wenn man tatsächlich am Anfang durch ein Javascript prüft, ob der Browser Jacascript kann, dann scheiden solche Tools auf alle Fälle aus, oder?
Wie man zu einem identischen Browser werden kann, zeigt Michael Schröpls Skript zum Servercheck. Denk dir einfach ein Skript, welches als Proxy arbeitet, also den dahinterstehenden Browser total verdeckt und alle HTTP-Header durch die des zu imitierenden Opfers ersetzt - der Server wird den Unterschied nicht mehr feststellen können, allerhöchstens (und dagegen kann man durch Verwendung eines zumindest in die Serie passenden Browsers etwas unternehmen) wird ein IE niemals document.layers verstehen - das könnte ja irgendwie zum Server zurückübermittelt werden.
In diesem Zusammenhang: Die PHP-Funktion get_browser() ist ziemlich billig aufgebaut. Sie schaut in einer Textdatenbank nach, was der Browser im allgemeinen so kann, und zerpflückt ein wenig den User-Agent in seine Bestandteile. Eine Information über den real verwendeten Browser und seine Möglichkeiten ist das nicht.
Ich fasse nochmal zusammen: Der einzige Schutz der jetzt von uns diskutierten Methoden ist der, daß man davon ausgeht, daß ein Angreifer nicht exakt die gleichen Informationen senden kann wie ein ordentlicher Benutzer. Dies wird im Allgemeinen dadurch erreicht, daß ordentliche Benutzer keine Klartextinformationen vom Server erhalten, und daß die Vielfalt der Ratemöglichkeiten hinreichend groß ist.
Sessionbasierte Mechanismen haben den leichten Vorteil, daß im Prinzip nach erfolgter Authentifizierung, bei der einmal Username und Paßwort übermittelt wurden, ein Einmal-Zugangsschlüssel (nämlich die Session-ID, meinetwegen angereichert um gewisse Zusatzinformationen) erstellt wird, der irgendwann ungültig wird und dann keine weiteren Benutzungen mehr zuläßt. Diese Methode hilft bei zufällig nach außen gelangten Sessiondaten etwas, den Mißbrauch einzudämmen, ist aber trotzdem nur ein extremst schwacher Schutz. Viel wichtiger ist SSL.
Letztendlich ist alles nur eine Frage des Rateaufwandes. Man kann auch Benutzernamen und Paßwörter raten und bei Erfolg Zugang erhalten - egal welcher Mechanismus benutzt wird: Sessions, .htaccess, irgendwas mit SSL. Der Schwachpunkt hierbei ist, wie immer, der Mensch, der sich einfach keine ordentlichen Paßwörter merken kann, sondern den Vornamen der Frau plus das Alter der Kinder nimmt (wobei das Paßwort da ja immerhin noch jedes Jahr gewechselt wird <eg>).
- Sven Rautenberg