Thomas Schmieder: HTTP Auth (wieder mal...)

Beitrag lesen

Hallo zusammen,

...einen _Schlüssel_ auf den Auth-Datensatz in der DB parken, am besten mit einer zweiten _eindeutig_ erzeugten ID, aber mehr sollte man das ganze nicht verzahnen. Und: Es muss immer sichergestellt sein, dass bei Zweifeln eher abgebrochen wird, als auf Verdacht weiter zu machen.

das trifft so ungefähr die Problematik. Eine Sessionnummer gibt nur eine Positivaussage, wenn sie passt. Leider ist diese Aussage nicht umkehrbar, da HTTP kein verbindungsorientiertes Protokoll ist. Wenn die Sessionnummer die einzige Größe ist, über die ein User erkannt werden kann, dann stellt sie kaum einen Schutz dar. Der User könnte ja theoretisch beliebig oft wiederkommen und damit gültige Sessionnummern erraten. Da es keine Möglichkeit gibt, festzustellen, ob es der selbe User ist (wie gesagt, alles Theorie), aknn man ihn auch nicht aussperren. Da aufgrund der Positiverkennung auch nicht festgestellt werden kann, welche Sessionnummer attakiert wird, kan man diese auch nicht schützen.

Das ganze ändert sich, wenn man eine Authentifizierung mittels Datenbank und einem Schlüsselpaar (Loginname und Passwort sind da üblich) vorschaltet und dan auf ein anderes Schlüsselpaar (Sessionummer und SessionPIN, beides Cookies) umschaltet. Nun ist es plötzlich nicht mehr möglich, eine "erratene" Sessionnummer einfach zu benutzen, da auch der Key dazu passen muss. Dem Server ist jetzt in der Lage, die attakierte (zufällig erratene) Session sofort zu sperren (also nicht unbedingt zu vernichten). Leider verliert dann zwar auch der rechtmäßige Besitzer die Verbindung zu seinen Daten, aber der kann sich ja neu anmelden und die abgebrochene Session wiederaufnehmen. Das ist allemal billiger, als ein Loch auf dem Konto oder die Blamage, wenn die Liebesbriefe plötzlich veröffentlicht werden *gg*.

Ich hoffe, ich konnte die Problmatik nun noch mal etwas deutlicher machen.

Übrigens braucht man beim AUTH-Verfahren keinen zusätzlichen Cookie, da ja bereits ein Schlüsselpaar vorhanden ist, das jedes Mal geprüft werden kann (eigentlich muss!). Die Session besteht dann darin, aus einer Datei die daten wiederherszustellen und mit register_shutdown_function() beim Scriptstart ein shutdown_script anzumelden, dass am Ende oder bei Abbruch des Scriptes die Sessiondaten wieder in diese Datei hineinschreibt.

So einfach ist das.

Liebe Grüße aus http://www.braunschweig.de

Tom

--
Intelligenz ist die Fähigkeit, aus Fehlern Anderer zu lernen und Mut die, eigene zu machen.