Login-Script Sicherheit (PHP)

[_php_]

Hallo,
habe mich mal etwas durchs Weg gelesen und festgestellt das es ganz unterschiedliche LoginScript ansätze gibt...

Variante 1 prüft ob Username/Passwort stimmen und setzt dann einen Sessioncookie wie z.B. $_SESSION['login_erfolgreich']=1. Auf den geschützten Seiten wird dann nur gefragt ob login_erfolgreich==1 ist und dann wird der geschützte Content ausgegeben, ansonsten nicht.

Variante 2 speichert User und Pass beim einloggen neben dem login_erfolgreich in einem Sessioncookie und prüft dann im gegensatz zu variante 1 nicht nur beim einloggen in der DB auf korrektheit der daten, sondern dies wird obwohl login_erfolgreich==1 ist auf jeder geschützten seite nochmal durchgeführt. hierzu werden dann die im sessioncookie gespeicherten daten mit der in der DB vergleichen

Also meine Frage jetzt...wenn Sessions doch serverseitig gespeichert werden und vom Client da keine Manipulationsmöglichkeit besteht, warum verwenden dann viele Variante 2? Ein Check am anfang ob user/pass korrekt sind müsste doch reichen, die ändern sich doch nicht alle paar minuten?!?

Und wenn man Variante 2 benutzt, warum wird dann allgemein empfohlen die Passwörter verschlüsselt zu speichern...es heisst immer "klartextpasswörter in der session sind gefährlich..." aber warum wenn sie serverseitig liegt?

[ZapBee]

Wenn Du bei Variante 1 innerhalb des geschützten Bereichs auf einen externen Link klickst, wird die Session-ID mit übertragen und taucht im Log der Zielseite bei den Referrern auf. Damit könnte sich der Webmaster der Zielseite Zugang zu dem geschützten Bereich verschaffen, denn in der Session steht ja "login_erfolgreich=1". Das vermeidest Du mit Variante 2.
Zur zweiten Frage weiß ich nichts defintives, aber es besteht folgende Gefahr: wenn auf dem Webserver durch Wartungarbeiten o.ä. das PHP-Modul ausfällt, wird der PHP-Code vom Webserver nicht interpretiert, sondern ausgeliefert wie eine txt-Datei (und ist somit im Klartext lesbar). Wenn da das Paßwort drinsteht, hast Du verloren. Ich speichere die Userpaßwörter in einer DB, und zwar nur als MD5-Hash. Das DB-Paßwort habe ich in eine txt-Datei gespeichert, die außerhalb des Webservers liegt, also in einem Bereich, auf den der Webserver nicht per relativer URL zugreifen darf. Ein PHP-Skript liest die txt-Datei aus und macht so das Login. Selbst wenn das PHP-Modul ausfällt, ist User/ Paßwort nicht zu ermitteln.

Zap

[darph]

Ich weiß nicht, ob es so klug ist, das Kennwort clientseitig im Cookie zu speichern, auch als MD5-hash. Cracken desselben ist zwar nachwievor ungemütlich, aber es gibt Datenbanken, wo man nicht ganz so sichere Kennwörter einfach durch Gegencheck rausfinden kann.

Sinnvoller wäre es da glaube ich, einen One-Time-Key zu erzeugen, der so lange gültig ist, wie die Session und diesen dann abzugleichen.

[Gast]

Ich weiß nicht, ob es so klug ist, das Kennwort clientseitig im Cookie zu speichern

Sessions werden soweit ich weiss auf dem Server gespeichert

[Gast]

Sessions werden soweit ich weiss auf dem Server gespeichert
Nein, entweder werden die Daten der URL angehängt, oder als Cookie gespeichert.

[Gast]

Nein, entweder werden die Daten der URL angehängt, oder als Cookie gespeichert.

Unsinn:

http://www.develnet.org/28.html

Die Manipulation dieser Session-Datei bleibt nur dem serverseitig ausgeführtem PHP-Script vorbehalten. Der Client weiß nicht welche Daten von dem Script gespeichert werden und er kann keinen mittelbaren Einfluß auf diese Daten nehmen. Ausnahme bildet hier die Änderung oder Löschung dieser Daten durch den Administrator oder durch ein auf dem Server laufendes Script mit entsprechenden (Datei-)Rechten.

[ZapBee]

Unsinn:

http://www.develnet.org/28.html

Die Manipulation dieser Session-Datei bleibt nur dem serverseitig ausgeführtem PHP-Script vorbehalten. [...]
:up:
Das einzige was diesbezüglich im Cookie steht (bzw. stehen sollte), ist die Session-ID, entweder automatisch erzeugt oder per DB-Methode (s.o., Variante 2). Probleme gibts, wenn der Besucher Cookies abgeschaltet hat, dann gehts per HTML-GET oder -POST.

Zap