login

[Shade Of Mine]

Sqwan schrieb:

Das erklär mir aber bitte mal. Wieso sollte ich auf $_SESSION verzichten. Das interessiert mich doch als Kunde garnicht. Damit kann sich der hoster rumschlagen. Wenn der Hoster mir die sessions nicht iwie ganz verbietet, dann kann ich sie auch nutzen.
Also als nutzer interessiert mich sowas an für sich garnichts. Egal ob ich ein "normaler Programmierer" bin oder eben nicht. Was auch immer jetzt ein unnormaler ist.

Sollst du ja eben nicht, das sage ich ja die ganze Zeit. Ich wiederhole mich hier scheinbar nur... Ich sage die ganze Zeit: PHP Session Management benutzen!

Es gibt lediglich eine Situation wo es Sinn machen kann auf $_SESSION zu verzichten. Und das ist so eine spezielle Situation dass wir sie eigentlich nicht zu diskutieren brauchen.

Wenn du nämlich einen eigenen Cluster hast, hast du ja das Problem dass du die Session Daten nicht lokal auf dem Server speichern kannst. Da HTTP nämlich Stateless ist, ist nicht garantiert dass der User wieder auf diesem Server landet.

Wenn du die Daten nun zwischen allen Servern sharen musst dann brauchst du teilweise einfach Custom Lösungen. Je nachdem wie die Struktur aussieht und was du technisch machen kannst. Hier kann es sein dass du an die Grenzen des PHP Session Management stößt. idR sollte sich das zwar mit einer eigenen PHP Extension lösen lassen, aber uU ist dann dennoch sinnvoller das Management selber zu schreiben.

Aber wie gesagt: das sind so spezielle Situationen dass wir hier eben nicht darüber reden sollten. Denn die wenigsten Leute werden je in so eine Situation kommen.

Mit "normal" meine ich Leute die nicht in solchen extrem Situationen sind.

[Gast]

Shade Of Mine schrieb:

Wenn die lifetime des Cookies zu niedrig steht, dann wird bei dem nächsten Request des Users die Session ID aber nicht mitgesendet weil das Cookie ausgetimt ist. dh du hast auf der Serverseite keine Ahnung mehr welche Session ID dieser User hat. Ergo ist es egal wo du die Daten gespeichert hast: du hast die Session ID verloren und damit die Daten.

Wer hat was von Cookies gesagt? Wenn ich die Session z.B. in der URL mitschiebe, brauch ich keinen Cookie?! Dann muss ich nur noch in der Datenbank prüfen ob "URL-Session" zu "DB-Session" passt und das wars. Mit Logout, oder nach Timeout wird die Session aus der DB gelöscht (falls die Frage auftaucht)...

Shade Of Mine schrieb:

Kann es sein dass du krampfhaft versuchst Gründe zu finden warum du nicht $_SESSION verwenden willst? Da kann ich dir helfen: es gibt genau einen relevanten Grund: Performance auf Clustern. Aber da gehen wir jetzt erstmal nicht näher ein, da das für einen normalen Programmierer irrelevant ist, da die meisten Leute nie in so eine Situation kommen werden.

Um Himmels Willen: Nein! Ich bin jetzt eines Besseren belehrt. Meine Erfahrung gegen dein Wissen. Meine Erfahrung lügt, dein Wissen hat Recht und ich meine Ruhe ;)!

VlG

[Shade Of Mine]

RandomAccess85 schrieb:

Wer hat was von Cookies gesagt? Wenn ich die Session z.B. in der URL mitschiebe, brauch ich keinen Cookie?! Dann muss ich nur noch in der Datenbank prüfen ob "URL-Session" zu "DB-Session" passt und das wars. Mit Logout, oder nach Timeout wird die Session aus der DB gelöscht (falls die Frage auftaucht)...

dh du verwendest nur Sessions per URL Übergabe? Die Risiken kennst du, oder?

Weiters ist das immernoch kein Problem in diesem Szenario da cookie Lifetime und Session Lifetime 2 unterschiedliche Sachen sind. Nur so angemerkt

Du verwendest also das PHP Session Management nur zum generieren der Session ID und sonst zu garnichts? Nichtmal Cookies, transid, etc? Das ist natürlich eine ziemlich schlechte Idee, da du alle Nachteile des PHP Session Managements dadurch übernimmst, nur die Vorteile nicht.

zB lockt PHP die Session Datei wären der Ausführung des Scripts, was zB bei asynchronen Anfragen durchaus merkbar bremst. Auch wenn du nichts in $_SESSION reinschreibst.

Shade Of Mine schrieb:

Kann es sein dass du krampfhaft versuchst Gründe zu finden warum du nicht $_SESSION verwenden willst? Da kann ich dir helfen: es gibt genau einen relevanten Grund: Performance auf Clustern. Aber da gehen wir jetzt erstmal nicht näher ein, da das für einen normalen Programmierer irrelevant ist, da die meisten Leute nie in so eine Situation kommen werden.

Um Himmels Willen: Nein! Ich bin jetzt eines Besseren belehrt. Meine Erfahrung gegen dein Wissen. Meine Erfahrung lügt, dein Wissen hat Recht und ich meine Ruhe ;)!

Jedenfalls scheint deine Erfahrung mit Session Management nicht so toll zu sein

Oder hast du auch nur ein einziges Argument das gegen $_SESSION spricht (von meinem extrem Beispiel abgesehen)?

[ghostboss]

So, ich bins noch mal.

* warum speichere ich keine Daten in $_SESSION und warum konnte ich mich auf $_SESSION nicht verlassen?

-> als ich mit Html...Php programmieren angefangen habe, wollte ich erstmal für kein Server zahlen weil ich Anfänger war und nicht wuste wie weit ich komme (kann man ja nachvollziehen ). Also habe ich auf einem Freehoster (www.funpic.de) meine Html...Php Seiten getestet. Und da habe ich dann ein Clan Seite aufgebaut. Als ich ein Loginsystem machen wollte, hab ich erstmal versucht die Daten in $_SESSION zu speichern. Doch nach paar Minuten (mal 9, mal 15, mal 3) wurde die Session zerstört, oder so, auf jeden Fall war die weg. Also habe ich das so gelöst dass ich die session_id() in die DB und Cookie gespeichert habe.

Jetzt habe ich einen richtigen Server und hab einfach mal mein System übernommen, weil das so gut funktionier hat. Aber wenn ich Zeit habe versuche ich es mit Session .
(wo kann ich denn die Session einstellen? Im Script oder bei Serverkonfigurations Seite?)

Und noch was. Ich nutze die session_id() nur um den User zu identifizieren.

if( cookie(session_id) == DB(session_id) ) user = lars
else user = gast

Ich könnte doch statt session_id irgendwas andres hashen, z.B. md5(user_name) oder md5(timestamp()) (ist nur ein Beispiel). Und schon habe ich auch eine Id die ich in DB und Cookie speichern kann und brauche die ganzen Sachen von Session nicht mehr.

Was spricht denn eigentlich gegen mein Login-System? (DB und Cookie)
* wegen DB verbindung bei jeder Seite um User zu identifizieren? (ein DB connect zuviel)
* unsicher? (wieso)
* Cookie?
* ???

[Shade Of Mine]

ghostboss schrieb:

Was spricht denn eigentlich gegen mein Login-System? (DB und Cookie)
* wegen DB verbindung bei jeder Seite um User zu identifizieren? (ein DB connect zuviel)
* unsicher? (wieso)
* Cookie?
* ???

Dein Login System waere vermutlich (ich kenne die Details ja nicht) vollkommen OK wenn du nicht session_start() verwenden wuerdest.

Sobald du naemlich session_start() verwendest hast das ganze PHP Session Management aktiviert - ob du es nutzt oder nicht.

zB wenn transid aktiviert ist, wird die Session ID ja ueberall an die URLs drangehaengt und natuerlich wird ein Cookie gesetzt, etc. Da ist ja ein komplexes System im Hintergrund am laufen.

Wenn sich der User ausloggt musst du zB die PHP Session ja auch wieder zerstoeren, sonst bekommt der User beim naechsten Login wieder die selbe Session ID, etc. Und ganz Riskant: PHP koennte eine Session ID generieren die bei dir noch aktiv ist.

Einfach gesagt: du faehrst 2 gleisig. Das gibt diverse Fallstricke die man beachten muss. Und natuerlich gibt es beim Handling der Session wenn man nicht die erprobten Varianten nimmt, auch ein paar Fallstricke.

Daten serialisieren, Transaktionen (User requestet 2 Seiten die Session Daten aendern gleichzeitig), korrektes Session destroy, Garbage Collection, URL rewriting,...

Und natuerlich implementiert man damit Funktioanlitaet die es bereits fehlerfrei gibt. Session Management ist so schon nicht trivial (Session Fixation, Cross Seite Request Forgery,...)

Wenn man natuerlich einen Server hat der die Session Lebenszeit auf 5 Minuten stellt muss man natuerlich etwas anderes machen. Eine Moeglichkeit waere zB session_set_save_handler gewesen.

Bitte nicht falsch verstehen: das ist fuer eine kleine private Seite alles aktzeptabel. Aber wenn das hier mal jemand liest soll er es eben gleich richtig lesen - darum geht es in einem Forum ja.

[Gast]

Shade Of Mine schrieb:

blubb blubb blubb

Willst du mich ärgern ?

Nein ich kenne die Risiken nicht, wenn ich Daten an die URL hänge! Ich kann mir auch keine gravierenden Risiken vorstellen.

Was sollen denn die Risiken sein?
- Daten verfälschen?
- SQL-Injections?
Das sind keine unvorhersehbaren Risiken, die sich nicht kontrollieren lassen!

*********

Nein ich verwende nicht das PHP-Session Management zum generieren einer Session. Ich verwende folgendes um einen Benutzer eindeutig zu machen:

srand(microtime()*1000000);
$zufall = rand(1,1000000);
$zufall=$zufall.$username;
$session = MD5($zufall); //'tschuldigung dass ich die Variable "session" nannte

*********

Was ich gegen $_SESSION habe sagte ich doch bereits. Die ganze Sache ist mir nicht transparent genug und ich habe zuviel Angst dass Sessions verloren gehen. Ich bin halt einfach kein Fan von SESSION, genauso wie andere keine Javascript, oder ASP, oder C++, oder $_SERVER, oder $_GLOBALS - Fans sind

VlG

[Shade Of Mine]

RandomAccess85 schrieb:

Shade Of Mine schrieb:

blubb blubb blubb

Willst du mich ärgern ?

Nein ich kenne die Risiken nicht, wenn ich Daten an die URL hänge! Ich kann mir auch keine gravierenden Risiken vorstellen.

Was sollen denn die Risiken sein?
- Daten verfälschen?
- SQL-Injections?
Das sind keine unvorhersehbaren Risiken, die sich nicht kontrollieren lassen!

Dachte ich mir dass du sie nicht kennst.
Ein Anfang waere hier zB: http://de.php.net/manual/en/session.security.php
Session Fixation und Session Hijacking/Session Riding sind nur ein paar der Sachen auf die man aufpassen muss. Gibt noch eine Menge andere Gruende die Session ID moeglichst wenig oft anzuzeigen.

Aergern will ich eigentlich Niemanden. Aber ein bisschen etwas lehren, das will ich.

Nein ich verwende nicht das PHP-Session Management zum generieren einer Session. Ich verwende folgendes um einen Benutzer eindeutig zu machen:

srand(microtime()*1000000);
$zufall = rand(1,1000000);
$zufall=$zufall.$username;
$session = MD5($zufall); //'tschuldigung dass ich die Variable "session" nannte

Mal davon abgesehen dass man mt_rand statt rand verwendet und srand unnoetig ist, ja das ist eine schwache Funktion zur Generierung einer Session ID. Bis auf dass du halt keine Kollisionen checkst und die Session ID relativ leicht erratbar ist. Der Username in der Session ID rettet das ganze ein bisschen.

Was ich gegen $_SESSION habe sagte ich doch bereits. Die ganze Sache ist mir nicht transparent genug und ich habe zuviel Angst dass Sessions verloren gehen.

dh du verstehst das System dahinter nicht?
Da kann nichts passieren und die Sessions sind komplett transparent. Ich kann dir zu jedem Zeitpunkt genau sagen in welchem Status die Session ist. Das einzige was vielleicht ein bisschen kompliziert zu verstehen ist, ist die Garbage Collection.

Das ist wie wenn ich sage, ich traue std::sort() nicht, ich sortiere lieber selber... Dein Session ID generieren ist zB ein gutes Beispiel warum man nicht immer das rad neu erfinden sollte, weil fuer bestimmte Probleme haben die Leute schon richtig lange nachgedacht wie das richtig geht.

Ich bin halt einfach kein Fan von SESSION, genauso wie andere keine Javascript, oder ASP, oder C++, oder $_SERVER, oder $_GLOBALS - Fans sind

dh du kannst es nicht Begruenden?

Ich fuer meinen Teil versuche immer das passendste Tool fuer einen Job zu nehmen. Wenn zB bei uns jemand sagen wuerde er traut den PHP Sessions nicht wuerde ich mir ziemlich meine Gedanken machen ob diese Person bei uns richtig ist. Das bitte nicht falsch verstehen, aber ich tu mir gerade echt schwer vorzustellen wir in so einer Situation machen wuerden...

[volkard]

RandomAccess85 schrieb:

Was ich gegen $_SESSION habe sagte ich doch bereits. Die ganze Sache ist mir nicht transparent genug

Ja, das habe ich auch gelegentlich, wenn ich C++-Libs verwende.

und ich habe zuviel Angst dass Sessions verloren gehen.

Kann ich nicht direkt nachvollziehen. Aber ist auch egal.

RandomAccess85 schrieb:

Ich bin halt einfach kein Fan von SESSION

Das reicht. Ich denke, es wurde jetzt ausreichend oft gesagt, daß SESSION schon was furchtbar Gutes ist. Aber wenn ich ehrlich bin, ich würde es auch nur für Kundenprojekte und alles andere nehmen, aber nicht für mein Steckenpferdprojekt.

[Gast]

@Shade Of Mine
Ich bitte dich! Wir sind Programmierer und nicht das FBI! Es hat alles seine Vor- und Nachteile und überall gibts Sicherheitslücken oder Risiken. OK, du findest Sessions super gut - hab ich verstanden. Ich finde sie nicht gut und damit is auch schon alles gesagt.
Das gibt dir beim Besten Willen nicht das Recht mich belehren zu müssen. Zumal ich deine "Belehrungen" für nicht sonderlich hilfreich halte....

ICH NUTZE KEINE SESSIONS => da kannst du schwärmen bis du heiß wirst.

Was mein Chef oder mein Job dazu sagt ist eine ganz andere Geschichte. Aber ich bin gerne anonym genug um da hier nicht weiter drüber zu diskutieren

Mein Privatprojekt zieh ich auch weiterhin über die gebastelte Session-Lösung groß. Ich hatte bisher keinerlei Probleme damit und bisher hat es auch keiner geschafft Blödsinn anzurichten. Das ganze läuft seit knapp 4 Jahren...

VlG

[volkard]

RandomAccess85 schrieb:

@Shade Of Mine
Ich bitte dich! Wir sind Programmierer und nicht das FBI!

Ich war jahrelang als Programmierer beim FBI.
http://www.fbi.h-da.de/

[Gast]

:p

[Shade Of Mine]

RandomAccess85 schrieb:

@Shade Of Mine
Ich bitte dich! Wir sind Programmierer und nicht das FBI! Es hat alles seine Vor- und Nachteile und überall gibts Sicherheitslücken oder Risiken.

Es ist OK wenn du das privat so machen willst.
Aber fuer relevante Webauftritte finde ich sowas halt schon riskant. Jedenfalls wuensche ich mir dass die Leute es hier gleich richtig lernen.

Session Management selber machen ist ja auch vollkommen OK. Aber dann machs richtig. Lies zB mal: http://seclists.org/vuln-dev/2001/Jul/33
Session IDs generieren ist kein trivialer Task. Natuerlich kann man es auch selber machen, aber es gibt eine Menge Sachen zu bedenken.

srand mit der aktuellen Zeit zu initialisieren ist hier zB keine gute Idee. Schau mal wie PHP das macht: http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/ext/session/session.c?view=markup -> php_session_create_id

[Gast]

Hallo,

du erzählst mir immer das es keine gute Idee ist, oder falsch es so zu machen und lieferst Beispiele wie ich es anders machen könnte. Warum, sagst du mir aber nicht. Gib mir doch die Möglichkeit zu verstehen, wieso du meine Variante nicht gut findest und welche Möglichkeiten der normale Webuser hat diese zu umgehen, bzw Mist damit zu machen.

Ich betone nochmal: Ich mache den Nutzer damit lediglich eindeutig, damit ich ihn später wieder identifizieren kann!

ICH NUTZE IMMERNOCH KEINE SESSIONS

VlG

[PRIEST]

find die php sessions eig. gut ^^

(mal so von hinten einwerf) :schland:

[schmidt-webdesign.net]

Es gibt viele Möglichkeiten, einen User eindeutig (und sicher) zu identifizieren. Session und Cookies gehören m. E.^* zu den schlechtesten ...

^* Abk.^** für meines Erachtens

^** Abkürzung für Abkürzung

[Shade Of Mine]

schmidt-webdesign.net schrieb:

Es gibt viele Möglichkeiten, einen User eindeutig (und sicher) zu identifizieren. Session und Cookies gehören m. E.^* zu den schlechtesten ...

Und woran erkennst du einen User?

Sessions, auf die eine oder andere Art sind notwendig.

@RandomAccess85:
Was genau ist dir unklar? Stell eine Frage, ich erklär es dir gerne.
Ich habe zB gezeigt dass deine Session ID den User nicht eindeutig identifiziert.
Und damit habe ich bewiesen dass dein Session Management fehlerhaft ist.

[Gast]

Hallo,

Allein schon die Benutzernamen sind eindeutig?! Alles andere ist reine Vorsicht, weil der Benutzername von allem am schnellsten rausgefunden ist :p

Mir ist nichts unklar, ich komm mit meiner - wie du es nennst - Sessionverwaltung ganz gut klar. Du bist derjenige der meint sie wäre unsicher und falsch.

VlG

[Shade Of Mine]

RandomAccess85 schrieb:

Allein schon die Benutzernamen sind eindeutig?! Alles andere ist reine Vorsicht, weil der Benutzername von allem am schnellsten rausgefunden ist :p

Ich weiss garnicht was man da noch groß sagen soll...

Bitte lies dich in die entsprechenden Security Themen ein. Eindeutige ID bringt nichts wenn sie trivial erratbar ist. Denn wenn ich die Session ID des Admins erraten kann, dann kann ich sie übernehmen:

Session Fixation, Session Riding, Session Hijacking,...

Bitte bitte bitte lies dich da mal rein.

PS:
mir ist klar dass ich auf verlorenem Posten stehe. Man muss sich nur einmal durch die Security Maillists durchlesen um zu sehen dass Sicherheit im Web einfach nicht existent ist. Aber n bisschen träumen darf man ja wohl...

[PRIEST]

Shade schreib mal nen Artikel drüber den les ich mir dann durch, komm grad net zum punkt was genau jetzt euer Thema is .. irgendwie hüpft man von A zu X und von X zu G und von G zu A oO

:schland:

[Shade Of Mine]

PRIEST schrieb:

Shade schreib mal nen Artikel drüber den les ich mir dann durch, komm grad net zum punkt was genau jetzt euer Thema is .. irgendwie hüpft man von A zu X und von X zu G und von G zu A oO

Der Punkt ist leicht:
Security Management sollte man bestehenden, erprobten, wenn möglich Open Source basierten Lösungen überlassen und nicht selber machen.

Das ist wie Verschlüsselung. Da nimmt man ja auch fertige Systeme und baut nicht seinen eigenen Algorithmus.