nicht angemeldet
Hi!
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.
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 die Session-ID raten kann und so angemeldeter Benutzer wird, ist das schlecht. Deshalb muß der Server etwas mehr prüfen. Wenn er als Cookieinhalt zusätzlich noch den Zeitpunkt der Anmeldung speichert, und dieses ebenfalls in der Benutzerdatenbank (vielleicht auch in den Sessiondaten - ich habe da aber ein ganz kleinwenig Unbehagen bei, weil im Cookie die Session-ID ist, die den gespeicherten Zeitstempel enthält) , dann muß man schon mal zusätzlich auch noch den Anmeldezeitpunkt raten.
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?
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.
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.
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!!! 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. 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!
Ü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 einfach er dran kommt. Gibt es def. keine Möglichkeit, auf einem PC die htaccess Zugangdaten irgendwie herauszubekommen? Das kann ich mir nicht vorstellen!
Das Problem besteht übrigens für jegliche Form der zusätzlichen Browsererkennung: Sie erhöht nur den Rateaufwand - wer erstmal spitzkriegt, daß er nur gewisse Bereiche des HTTP-Headers imitieren muß, wird defaultmäßig einfach zu einem identischen Browser, weil er alles kopiert, was der eigentliche Benutzer liefert. Hilft also nichts für die Sicherheit.
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 macht man das eigentlich sinnvolerweise? Wie kann man das überprüfen?
Viele Grüße
Andeas