Auf diesem Rechner eingeloggt bleiben

[mcchaos]

Hallo!

Die Funktion "bleiben Sie auf diesem Rechner eingeloggt" ist ja bekannt. Das sie über Cookies realisiert wird, auch. Die Frage ist nun, wie ich dies einigermaßen sicher hinbekomme. Verschlüssele ich die Daten im Cookie selbst oder nehme ich (so scheint es Abakus zu machen) eine id, hinter der dann auf dem Server vermutlich Benutzername und Paßwort hinterlegt sind?

[marc75]

die login daten nicht im cookie speichern (auch nicht verschlüsselt), besser mit separater Id.

[heddesheimer]

So eine Funktion ist eigentlich nie wirklich "sicher". Wenn man es aber dem Benutzer wegen der Bequemlichkeit trotzdem anbieten will (oder muss - Der Kunde hat eben immer Recht), dann solltest du das Passwort z.B. per md5() verschlüsseln, damit es wenigstens nicht im Klartext aus dem Cookie ausgelesen werden kann.

Da md5() eine Einweg-Verschlüsselung ist, musst du dieses dann mit dem md5()-Ergebnis aus dem Passwort der User-Datenbank vergleichen (falls du das Passwort nicht sowieso schon md5-Verschlüsselt gespeichert hast).

Gruß Marian

[marki]

Ich hab mir auch schon die Frage gestellt, da ich im Moment ein Projekt erstelle. Eins vorweg: ich bin blutiger Anfänger was PHP betrifft.
Manche Skripte, die im Internet zu finden sind, speichern den Benutzernamen und das Passwort verschlüsselt (mit MD5) im Cookie ab. Meiner Meinung nach ist es sicherer, die SessionID abzuspeichern. Beispiel: der Benutzer ändert sein Passwort mit einem manipulierten Cookie. Die Mysql-Abfrage hierfür lautet dann "update tabelle set passwort=$_Post['passwort'] where userid = $_Cookie['benutzername']". Gar nicht gut. Hieße es allerdings Set passwort=$_Post['passwort'] where sessionid = $_Cookie['sessionid'], so ist keine Manipulation möglich. Die Sessionid wird dazu beim Login in die Tabelle geschrieben. Sollte der Cookie gelöscht werden gibts halt ne neue Sessionid beim nächsten Login.
In einem anderen Skript habe ich auch viele verwirrende Punkte und Klammern unter dem Stichwort "String-Delimiter" vorgefunden. Keine Ahnung was das soll, es ist aber eine Art Sicherheitsfeature.

[heddesheimer]

Meiner Meinung nach ist es sicherer, die SessionID abzuspeichern.

Ist prinzipiell genauso gefährlich, da dann die Session über längere Zeit gültig bleiben müsste. Standardmäßig wird eine PHP-Session nach einigen Stunden automatisch auf dem Server gelöscht.

Beispiel: der Benutzer ändert sein Passwort mit einem manipulierten Cookie.

Genau aus diesem Grund muss eine Passwort-Änderung auch immer mit der Eingabe des alten Passwortes gesondert bestätigt werden

Gruß Marian

[marki]

Genau aus diesem Grund muss eine Passwort-Änderung auch immer mit der Eingabe des alten Passwortes gesondert bestätigt werden

Oh, danke für den Tipp.
Trotzdem: Meine Lösung mit der Session ist doch nur dann gefährlich, wenn jemand den Cookie entwendet, was eigentlich immer der Fall ist, solange man anhand des Cookies automatisch identifiziert wird.
Auf meinem Server beträgt die session.gc_maxlifetime 1440 Sekunden. Ist es dann nicht möglich, bei einem späteren Aufruf die SESSIONID, die in der MySQL-Tabelle abgespeichert wurde, mit dem Cookie abzugleichen und dann in der Tabelle und im Cookie die neue ID abzuspeichern? Wäre doch mal ne Idee! Muss ich mal ausprobieren.

[heddesheimer]

Du kannst natürlich über die Lebenszeit des Session-Cookie (kannst du auch irgendwo einstellen) das Ganze so einstellen, dass man sich in den nächsten 24 Minuten auch noch ohne Login einloggen kann, weil dann die Session noch gültig ist.

Üblicherweise wird das Session-Cookie gelöscht, wenn der Browser geschlossen wird.

Gruß Marian

[cren]

...Hieße es allerdings Set passwort=$_Post['passwort'] where sessionid = $_Cookie['sessionid'], so ist keine Manipulation möglich...

Falsch. Es ist prinzipiell sehr gefährlich Usereingaben zu vertrauen. SQL-Injection lautet das Zauberwort

[marki]

Falsch. Es ist prinzipiell sehr gefährlich Usereingaben zu vertrauen. SQL-Injection lautet das Zauberwort

Habe gerade mal schnell gegoogelt. Wenn ich meinen Admin-Account nicht Admin sondern Gott nenne, woher weiß der Hacker dann, zu welchem Namen er ein neues Passwort setzen soll?

[Bauchladen]

Man vergibt hierzu einen (oder mehrere) seperate(n) Schlüssel der/die in einem
Cookie abgelegt wird/werden. Dieser Schlüssel(satz) passt zu einem Datenbank
Eintrag der dann das Autologin validiert.

[Bimbel]

Kleine Anmerkung noch: MD5 ist kein Verschlüsselungsalgorithmus sondern dient zur Erstellung von Prüfsummen.

[cren]

Falsch. Es ist prinzipiell sehr gefährlich Usereingaben zu vertrauen. SQL-Injection lautet das Zauberwort

Habe gerade mal schnell gegoogelt. Wenn ich meinen Admin-Account nicht Admin sondern Gott nenne, woher weiß der Hacker dann, zu welchem Namen er ein neues Passwort setzen soll?

Was machst du wenn er es überall setzt indem er ins Passwort-Feld einfach eingibt:

hahaha' WHERE 1--

Also Usereingaben immer auf einen plausiblen Wert prüfen bevor dieser in die Nähe der DB darf

[Bauchladen]

Kleine Anmerkung noch: MD5 ist kein Verschlüsselungsalgorithmus sondern dient zur Erstellung von Prüfsummen.

MD5 basiert auf einem krypografischen Verfahren und wird
nicht nur zur Integritätsprüfung verwendet. MD5 kommt auch
zur Einweg-Verschlüsselung von Kennwörtern über unsichere
Verbindungen (u.a. Message Digest / HTTP Auth, PGP) zum Einsatz.

Als Prüfsummenverfahren bezeichnet man eigentlich nur
einfache Additionen und Polynomdivisionen wie CRC, CRC32 ..
aber nicht zb. MD5.


Gruß

Michael