nicht angemeldet
Holladiewaldfee,
Ihr beide verwechselst da was:
- Ein Login wird (so er denn über mehrere Seiten gehen soll) mittels einer Session realisiert. Die Begriffe bezeichnen also im Endeffekt das Gleiche.
Nein. Ich kann einen Login auch mittels .htaccess machen, dann brauche ich serverseitig keine Session, es sei denn, ich will zusätzlich zur Authentifikation weitere Daten zum Login ständig parat haben oder ich muß den Zusammenhang von mehreren einzelnen .htaccess-Logins herstellen können (z.B. bei einem Warenkorb).
- Sessions arbeiten mit Cookies, nur ausnahmsweise werden URL-Parameter genutzt.
Sessions können mit Cookies arbeiten. Es gibt wenn ich mich recht erinnere durchaus einige CM-Systeme, bei denen die SessionID Teil der URL ist (nicht im Query-Teil) und nicht über Cookies realisiert wird. Aber es ist natürlich ohne Frage ansehlicher, wenn die SessionID per Cookie weitergegeben wird.
Man könnte auch sagen, daß Ihr da von ein- und demselben technsichen Vorgang redet, ihm aber drei verschiedene Begriffe zuordnet.
Was wir (bzw. mal zumindest ich) gemeint habe(n):
"Session" als einzelner Besuchsvorgang der Webseite, zusammengefasst mit Hilfe der session_*-Funktionen, also der Zeitraum, über den eine SessionID gültig ist.
Das mit dem Cookie war gedacht als Lösung, um mehrere Sessions (wie oben definiert) ohne erneutes manuelles Login durchführen zu können.
Das ist aber meiner Meinung nach aus dem Kontext heraus klar.
Cookies sind, wie Harry bereits geschrieben hat, generell als unsicher einzustufen, da sie im Klartext übertragen und gespeichert werden. Dies gilt ausdrücklich für Punkt 1 UND Punkt 2.
Hier gibt es aber durchaus einen Unterschied in der Sicherheitsstufe: Das Cookie, das die SessionID enthält, ist nach Ablauf der Session wertlos, wohingegen das andere, dauerhaft gespeicherte Cookie die Login-Daten enthält und somit weiter nutzbar ist. (Ah ja, hast Du ja unten noch beschrieben ...)
Um die allgemeine Sicherheit der auf dem Benutzerrechner gespeicherten Daten muß und kann sich nur der Benutzer kümmern.
Nein - meiner Ansicht nach habe ich als Programmierer dafür Sorge zu tragen, daß die Daten des Nutzers geschützt sind. Das gilt auch, wenn sie auf Seiten des Nutzers gespeichert werden. Mindestens 95% der Leute haben doch überhaupt keine Ahnung von den Vorgängen, die hier dahinterstecken - wie sollen (wollen?) sie sich dann um die Sicherheit derselben kümmern?
Ohne weitere Details zu kennen sehe ich das Sicherheitsproblem nicht bei dem vorübergehenden Login, sondern beim dauerhaften, denn es kann von Serverseite aus niemand garantieren, daß nicht irgendjemand anders den Rechner benutzt, wenn der Eigentümer zum Essenfassen oder in den Urlaub verschwindet.
Ja, richtig. Aber sagen wir's mal so: Der durchschnittliche Nutzer hat irgendwas zwischen einem und zwei Passwörtern. Speichere ich sein Login im Klartext, gebe ich damit einem (lokalen) Angreifer das Passwort im Klartext preis - genau das versuche ich aber zu verhindern.
Von daher sollte ein dauerhafter Login nur als Option zur Verfügung stehen, die eine schnelle Überprüfung, also lesenden Zugriff, von Daten erlaubt. Jedwede Änderung an den Daten, also schreibender Zugriff, muß immer eine zeitlich nahe Authentifizierung (also wiederum den vorübergehenden Login) erfordern. Diese Vorgehensweise ist sicher jedem von eBay bekannt.
In den meisten Fällen wäre das aber mit Kanonen auf Spatzen geschossen.
Ciao,
Harry