Wie sicher sind Cookies?

[der bär]

Hi,
ich enwickle grad einen Loginbereich und es soll 2 Login-Möglichkeiten geben:
1. Login für einen längeren Zeitraum, mit Sessions
2. Login solange bis die Seite geschlossen wird, mit Cookies.
Jetzt interessiert mich in Bezug auf Punkt 2, wie sicher es ist, einen Cookie zu setzten.
Gibt es vielleicht eine andere, sichere Methode, und wenn ja, welche?
gruß, der bär

[Harry]

Holladiewaldfee,

1. Login für einen längeren Zeitraum, mit Sessions
2. Login solange bis die Seite geschlossen wird, mit Cookies.

Ich glaube Du hast da was verwechselt ...

1. Login für einen längeren Zeitraum, mit Cookies
2. Login solange bis die Seite geschlossen wird, mit Sessions.

Jetzt interessiert mich in Bezug auf Punkt 2, wie sicher es ist, einen Cookie zu setzten.

Also Punkt 1 ...
Naja, das Cookie wird wenn Du nicht grade verschlüsselte Verbindungen einsetzt, im Klartext übertragen. Außerdem mußt Du in dem Cookie irgendwie die Login-Daten oder etwas gleichwertiges speichern. Cookies werden von den Browser normalerweise im Klartext gespeichert und können evtl. am Rechner von Dritten eingesehen werden. Wenn es also wirklich um wichtige Dinge geht, laß Dir was einfallen, um das Cookie sicherer zu machen.

Bleistift:
Verschlüssele das Cookie XOR mit einem "Einmalschlüssel". Berechne anschließend eine Quersumme des verschlüsselten Cookies (md5) und speichere diese zusammen mit dem Schlüssel in einer Datenbank. Wenn Du das Cookie überprüfen willst: Berechne wieder seine Quersumme, hol Dir den passenden Schlüssel aus der Datenbank und entschlüssel es wieder.

Ciao,

Harry

[der bär]

Hi,
also das hat mich jetzt etwas stutzig gemacht, weil die Session solange aktiv bleibt bis ich session_destroy() aufrufe. Und den Cookie wollte ich ohne Zeitangabe setzten. Aber ich bin auf dem Gebiet eher Neuling.
Und ich hab noch eine Frage: Was ist eine XOR Verschlüsselung, bei Google hab ich keine Tutorials oder sonst was gefunden.
gruß, der bär

[Andreas-Lindig]

Hallo Bär,

also das hat mich jetzt etwas stutzig gemacht, weil die Session solange aktiv bleibt bis ich session_destroy() aufrufe...

oder die Garbabe-Collection von PHP die Session löscht, oder der Braueser geschlossen wird, weil beim nächsten initialisieren eine neue Session vergeben wird. Vielleicht existiert die alte Datei dann zwar noch, ist aber für den betreffenden Besucher nicht mehr gültig.

Und den Cookie wollte ich ohne Zeitangabe setzten.

dann verfällt es, sobald der Brauser geschlossen wird

Gruß, Andreas

[der bär]

Hi,
also bei mir bleibt die Session, du kannst dir den Quelltext angucken unter http://forum.de.selfhtml.org/?t=75602&m=435427, hab allerdings 2 Änderungen vorgeommen:
1. Ich setzt keinen Cookie mehr mit der Session ID
2. Ich hab aus session_start($sessid), session_start() gemacht
Warum bleibtn die Session immer noch da?
gruß, der bär

[Andreas-Lindig]

also bei mir bleibt die Session...
Warum bleibtn die Session immer noch da?

sie bleibt solange, bis die GC vorbeigekommen ist. Wann das ist, kann man nicht so genau sagen. Es ist auch abhängig von der Einstellung der Variablen "session.gc_probability" und "session.gc_maxlifetime" in der PHP-ini.

Gruß, Andreas

[Harry]

Holladiewaldfee,

also das hat mich jetzt etwas stutzig gemacht, weil die Session solange aktiv bleibt bis ich session_destroy() aufrufe.

Jein. Nach einer gewissen Zeitspanne der Inaktivität (30min?) macht die Session von selbst 'nen Abgang. Außerdem vergisst der Browser im Normalfall die SessionID, wenn seine eigene "Session" vorbei ist.

Und den Cookie wollte ich ohne Zeitangabe setzten. Aber ich bin auf dem Gebiet eher Neuling.

Ist zwar für JavaScript, aber Du kannst hier trotzdem was über Cookies lernen:
http://selfhtml.teamone.de/javascript/objekte/document.htm#cookie

Und ich hab noch eine Frage: Was ist eine XOR Verschlüsselung, bei Google hab ich keine Tutorials oder sonst was gefunden.

XOR ist das binäre exklusive "Oder".

Beispiel:

10010110     [1]
   XOR 01001100     [2]
       --------
     = 00100101     [3]

Wenn Du nun auf [3] wieder XOR [2] anwendest erhältst Du wieder [1]

00100101     [3]
   XOR 01001100     [2]
       --------
     = 10010110     [1]

Und so funktioniert das mit jedem Zeichen (hier mal davon ausgegangen, daß Du 8-Bit-Zeichen verwendest). Hier ist [1] der zu verschlüsselnde Wert, [2] der Einmalschlüssel und [3] das verschlüsselte Ergebnis. Ohne Kenntnis von [2] ist es nicht möglich, aus [3] [1] zu gewinnen.

Ciao,

Harry

[Die allwissende Müllhalde]

1. Login für einen längeren Zeitraum, mit Sessions
2. Login solange bis die Seite geschlossen wird, mit Cookies.

Ich glaube Du hast da was verwechselt ...

1. Login für einen längeren Zeitraum, mit Cookies
2. Login solange bis die Seite geschlossen wird, mit Sessions.

Ihr beide verwechselst da was:

1. Ein Login wird (so er denn über mehrere Seiten gehen soll) mittels einer Session realisiert. Die Begriffe bezeichnen also im Endeffekt das Gleiche.
2. Sessions arbeiten mit Cookies, nur ausnahmsweise werden URL-Parameter genutzt.

Man könnte auch sagen, daß Ihr da von ein- und demselben technsichen Vorgang redet, ihm aber drei verschiedene Begriffe zuordnet.

Jetzt interessiert mich in Bezug auf Punkt 2, wie sicher es ist, einen Cookie zu setzten.

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.

Die Frage ist jetzt, um welche Sicherheit es hier geht. Absolute Verbindungssicherheit ist nur zu erreichen, indem ein verschlüsseltes Protokoll (https) eingesetzt wird.
Um die allgemeine Sicherheit der auf dem Benutzerrechner gespeicherten Daten muß und kann sich nur der Benutzer kümmern. Die Sicherheit von einzelnen Daten, auch vor dem Benutzer, wird mit fertigen Sessionlösungen (auch PHP-Sessions) erreicht, indem statt der eigentlichen Daten nur ein zufälliger Bezeichner an den Benutzer gesendet wird (Session-ID). Die Daten selber bleiben auf dem Server, dieser Datensatz wird mittels der Session-ID geladen.

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.
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.

[der bär]

Hi,
sagen wir, ich würde die Session Id in einem Cookie auf dem Pc des Users speichern, wie würde ich diese dann wieder aufnehmen?
mit session_start($session_id) oder wie?
das hat bei meinen ersten Versuchen nie geklappt.
gruß, der bär

[Die allwissende Müllhalde]

sagen wir, ich würde die Session Id in einem Cookie auf dem Pc des Users speichern, wie würde ich diese dann wieder aufnehmen?
mit session_start($session_id) oder wie?

PHP verarbeitet Sessions automatisch. session_start() reicht vollkommen, um $_SESSION[] zu füllen, und Cookies werden normalerweise sowieso verwendet.

Für den dauerhaften Login wirst Du mit Sessions aber nicht glücklich werden, da die Sessiondaten vom Server nach einer Weile Nichtnutzung automatisch gelöscht werden. Dies zu ändern wäre nicht unbedingt klug, weil sich dann sehr schnell sehr viel Datenmüll auf dem Server anhäuft.

Benutze stattdessen setcookie(), um den Benutzernamen (und nur den Benutzernamen) in einem separaten, dauerhaften Cookie zu speichern. Dieser lässt sich später über $_COOKIE[] schnell und einfach auslesen. Achte aber darauf, daß mit diesem Cookie nur lesender Zugriff möglich ist, schreibender Zugriff in jedem Fall die Passwortangabe und den Login per Session erfordert.

[Harry]

Holladiewaldfee,

Achte aber darauf, daß mit diesem Cookie nur lesender Zugriff möglich ist, schreibender Zugriff in jedem Fall die Passwortangabe und den Login per Session erfordert.

Vielleicht sollten wir uns doch mal erkundigen, was er so vor hat. Falls er nur ein kleines Board für den lokalen Trachtenverein oder sowas schreiben will ist das ... sagen wir mal ... Overkill.

Ciao,

Harry

[Die allwissende Müllhalde]

Kurzzeitige, geistige Umnachtung, Verzeihung.

Benutze stattdessen setcookie(), um den Benutzernamen (und nur den Benutzernamen) in einem separaten, dauerhaften Cookie zu speichern.

Das ist natürlich Quark, auf diese Art und Weise könnte sich jeder in das Konto jedes beliebigen anderen Nutzers einklinken.

Du brauchst auch hier wieder eine Kennung, einen schön langen (vielleicht 128 Zeichen), mit zufälligen Zeichen (wegen der Cookiebeschränkungen am Besten nur a-z, A-Z und 0-9) gefüllten Text, der in der gesamten Benutzerdatenbank nur einmal existieren darf. Diese Kennung speicherst Du im Benutzerkonto auf dem Server und im besagten Cookie. Empfängst Du eine solche Kennung, suchst du das Konto mit dieser Kennung und kannst dort den Zugriff erlauben.

[wahsaga]

hi,

Du brauchst auch hier wieder eine Kennung, einen schön langen (vielleicht 128 Zeichen), mit zufälligen Zeichen (wegen der Cookiebeschränkungen am Besten nur a-z, A-Z und 0-9) gefüllten Text

welche bescrhänkungen?

laut http://wp.netscape.com/newsref/std/cookie_spec.html ist im cookie-value so gut wie alles erlaubt,

NAME=VALUE
This string is a sequence of characters excluding semi-colon, comma and white space. If there is a need to place such data in the name or value, some encoding method such as URL style %XX encoding is recommended, though no encoding is defined or required.

wobei man sich um die URL-gerechte kodierung beim setzen eines cookies durch PHP AFAIK nicht mal selber kümmern muss.

gruss,
wahsaga

[Die allwissende Müllhalde]

Du brauchst auch hier wieder eine Kennung, einen schön langen (vielleicht 128 Zeichen), mit zufälligen Zeichen (wegen der Cookiebeschränkungen am Besten nur a-z, A-Z und 0-9) gefüllten Text

welche bescrhänkungen?

Die von Dir selbst da unten zitierten zum Beispiel:

laut http://wp.netscape.com/newsref/std/cookie_spec.html ist im cookie-value so gut wie alles erlaubt,

NAME=VALUE
This string is a sequence of characters excluding semi-colon, comma and white space.

"Characters" schließt außerdem bestimmt eine Reihe Steuerzeichen aus, denn normalerweise steht an solchen Stellen sonst "octets". Zumindest vermieden werden sollten aber die beiden Zeichen, die eine neue Zeile kennzeichnen, sowie sicherheitshalber das Nullbyte. Das Gleichheitszeichen sehe ich wegen der Verwendung in der Cookiesyntax ebenfalls als kritisch an, auch wenn ich zugegebenermaßen jetzt nicht in das Netscape-Papier geschaut habe.

Die Vermeidung von sämtlichen Zeichen außer den von mir oben genannten ist aber in der Tat eine persönliche Vorliebe (daher das "am Besten"). 62 Zeichen an 128 Stellen ergibt eine Anzahl Möglichkeiten, die mein Taschenrechner nicht mehr auspucken kann (62^128, vielleicht möchte das ja jemand ausrechnen). Insofern ist es müßig, über die Verwendung weiterer Zeichen zu sprechen, wenn die vorhandenen in so ziemlich jeder Situation ohne Ansicht der Spezifikation als sicher gelten können und vor allen Dingen mehr als ausreichen.

[Harry]

Holladiewaldfee,

62 Zeichen an 128 Stellen ergibt eine Anzahl Möglichkeiten, die mein Taschenrechner nicht mehr auspucken kann (62^128, vielleicht möchte das ja jemand ausrechnen).

62^128 ~= 0,266795497 * 10^230 (laut Maple)

Zum Vergleich: Anzahl der Atome im Universum: ~10^78

Angenommen, jedes dieser Atome könnte 1 Billion Rechnungen pro Sekunde durchführen, würde die sichere Berechnung 0,266795497 * 10^140 Sekunden dauern. Wenn wir nun annehmen, daß das Ergebnis ungefähr nach der Hälfte der Zeit gefunden wird also noch 0.1333847748 * 10^140 Sekunden.

Das sind ungefähr 0,422960343 * 10^132 Jahre. Das entspricht grob dem 0.28 * 10^122-fachen des Alters unseres Universums.

Na Prost Mahlzeit, das sollte in der Tat reichen ...

Ciao,

Harry

[Harry]

Holladiewaldfee,

Ihr beide verwechselst da was:

1. 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).

2. 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

[Die allwissende Müllhalde]

1. 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,

Richtig. Hier ging's nur die ganze Zeit um Sessions, daher hatte ich diese Möglichkeit übersehen. Und sie lässt sich wahrscheinlich auch nur schwer mit dem geplanten System und der vorhandenen Software in Einklang bringen.

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.

Ich dachte eher an den allgemeinen Zustand des Rechners, den möglichen Benutzerkreis. Sicherlich sollte man Daten, die in die Welt hinausgeschickt werden, verschlüsseln - oder besser gar nicht erst herausgeben.

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.

Diese Aussage steht in krassem Gegensatz zu Deiner Aussage von oben, daß der Programmierer dafür Sorge zu tragen hat, die Daten des Benutzers zu schützen. Was nützen Dir verschlüsselte Daten an einer Stelle, die eh nur Fortgeschrittene finden, wenn schon jeder Hans Wurst mit dem Rechner Schindluder treiben kann, weil der schreibende Zugriff auch nach Wochen noch ohne weitere Authentifizierung möglich ist? Du verrammelst die Fenster zum Garten mit Hochsicherheitsbeschlägen und planst als Haustür nur einen Fliegenvorhang ein.

Überhaupt: Was ist so umständlich daran, sich je schreibender Sitzung einmal mit dem Passwort anzumelden? Passwörter sind schließlich dazu da, benutzt zu werden.

[Harry]

Holladiewaldfee,

Diese Aussage steht in krassem Gegensatz zu Deiner Aussage von oben, daß der Programmierer dafür Sorge zu tragen hat, die Daten des Benutzers zu schützen.

Finde ich nicht. Es geht hier um sein Passwort, von dem er - DAU / Normalnutzer vorausgesetzt - nur eins oder zwei besitzt. Den automatischen Login in das Board des Trachtenvereins von um die Ecke halte ich auch mit Schreibzugriff für eher unbedenklich.

Was nützen Dir verschlüsselte Daten an einer Stelle, die eh nur Fortgeschrittene finden, wenn schon jeder Hans Wurst mit dem Rechner Schindluder treiben kann, weil der schreibende Zugriff auch nach Wochen noch ohne weitere Authentifizierung möglich ist?

Nichts - es ging mir nur um den Schutz des Passwortes.

Du verrammelst die Fenster zum Garten mit Hochsicherheitsbeschlägen und planst als Haustür nur einen Fliegenvorhang ein.

Ich glaube Du hattest nicht so ganz verstanden, worauf ich rauswollte ;)

Überhaupt: Was ist so umständlich daran, sich je schreibender Sitzung einmal mit dem Passwort anzumelden? Passwörter sind schließlich dazu da, benutzt zu werden.

Die Anzahl der Passwörter, die sich mit der Zeit so anhäufen, wenn man nicht auf das "ein oder zwei Passwörter"-Niveau herabsteigen will.

Ciao,

Harry