nicht angemeldet
Moin!
Wenn die Sicherheit es erfordert, muß man eben Cookies zur Pflicht machen.
OK, also cookies, aber nicht für die SesionID sondern vielleicht microtime() oder so ja? Auch hier wieder, sollteman das noch verschlüsseln?
Cookies _auch_ für die Session-ID, aber eben nicht nur.
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.
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.
Wenn dann auch noch dieser Zeitstempel verschlüsselt wird, dann weiß man garnicht mehr, daß es ein Zeitstempel ist, und muß so richtig 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.
Und so sehen wir: Es ist vollkommen unmöglich, eine Session gegen Raten 100% abzusichern, man kann nur versuchen, den Rateaufwand hinreichend groß zu machen. Wenn man 1024 Zeichen raten muß, wird jeder Angreifer schlicht aufgeben. Sind bei 26 Buchstaben ja auch "nur" etwa 8,5*10^1448 verschiedene Möglichkeiten, also für jeden der ungefähr 6 Milliarden Erdenbürger exakt 1,4274374009915182902106399964072*10^1439 mögliche Sessions, wenn alle Menschen der Welt gleichzeitig angemeldet sind. Sollte grob gesagt ausreichen. ;)
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.
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.
Und was ich dann noch weniger verstehe, wenn ich vergleiche:
if($crypt_pw==crypt(klartext_pw)
Du mußt eben dafür sorgen, daß das Salz identisch ist, indem du einfach das verschlüsselte Paßwort als Salzwert an crypt() mit übergibst. Crypt wird die ersten beiden Zeichen als Salz verwenden.
Aber was mache ich bei der ursprünglichen Verschlüsselung? Ich könnte mir das nur mit dem Klartext Passort vorstellen, das habe ich sowohl wenn ich das erste mal verschlüsele und das speicher, und jedesmal wenn ich prüfe. Aber das als Parameter eine Funktion, die mir erstmalig ein Passwort verschlüsseln soll das eigentlichen Ergebnis anzugeben geht IMHO nicht, oder? Wie hattest Du das gemeint?
Bei der ersten Verschlüsselung denkst du dir ein Salz aus. Oder nimmst einen festen oder zufälligen Wert. Ist vollkommen egal für die Verschlüsselung.
- Sven Rautenberg