[phpdev]

Nabend,

ich überlege mir gerade wie ich eine Session Klasse am besten schreiben kann.
Ich habe nun eine Klasse namens Session und eine Methode namens login, dieser Methode werden Benutzername und Passwort übergeben.

Nun denke ich darüber nach wie ich das mit der "Session" am besten mache. Bis jetzt habe ich immer den Benutzernamen und das Passwort (verschlüsselt) in zwei Cookies gespeichert und auf jeder Seite den Benutzernamen und das Passwort ausgelesen und auf Übereinstimmung mit den Daten aus der MySQL Datenbank überprüft.

Jetzt gibts ja das Problem das manche User keine Cookies zulassen, aber auf verschiedenen Seiten habe ich gelesen das auch eine Session ID entweder im Cookie gespeichert wird (geht automatisch) oder mit POST oder GET übergeben wird.

Auf die Übergabe in der URL per POST oder GET möchte ich eigentlich verzichten, da man ja auch gerne mal
einen Link weitergibt und nicht auf die URL achtet.

Ist es denn Sinnvoll NUR die SessionID mit session_start() zu erstellen und in einem Cookie zu speichern und diese dann in der Datenbank einzutragen und so dann den Benutzer mittels $_COOKIE['PHPSESSID'] zu identifiezieren ?

PS: Ich habe zwar schon mehrere Seiten gefunden und durchstöbert aber richtig beantworten konnte mir diese Frage noch keine.

[mepeisen]

Gegenfrage: Wieso ist das nicht sinnvoll?

Es gibt exakt drei Möglichkeiten, einen Benutzer zuverlässig zu erkennen und eine davon fällt im Internet eh flach.
1. Verschlüsselte Ablage der Benutzer-/Passwort-Daten in einem Cookie. Das ist für paranoide Sicherheitsneurotiker der Worst Case. Aber nun ja. Möglich ist es.
2. Eine normale PHP-Session und dort (in welcher Form auch immer) die Session-Daten hinterlegen. In diesem Fall nutze ich eigentlich immer ein zusätzliches Identifizierungsmerkmal für die Session, zum Beispiel den aktuell verwendeten Browser, IP-Adresse usw. Je nach Anforderung. Es gibt nur zwei Chancen, die Session-ID vom Client zu erfahren, das ist entweder ein Cookie oder als POST-/Get-Variable. Wenn man beides nicht haben will hat man Pech gehabt.
3. Nutzen zusätzlicher Dienste, zum Beispiel eines Microsoft Authentifizierungsdienstes. Sowas fällt in 99,99% im Internet flach und ist eher in einem LAN zu finden bzw. in Unternehmesnetzwerken.

Nun nochmal ausführlich: Worum gehts dir eigentlich? Um Sicherheit? Wenn ja um welche Sicherheit? Das des Passwortes? Die Sicherheit, einen User wiederzuerkennen? Um Cookies? Fragen über Fragen.

Ich gehe mal davon aus, dass du dir die Frage selbst beantworten kannst, sobald du genau weisst, worum es dir geht, denn so viele Möglichkeiten hat man eh nicht.

[MrNiceGuy]

Zum Thema Sicherheit mit Sessions habe ich mir selber mal eine alternative Lösung erarbeitet, die ich persönlich sicherer finde, als die IP oder den Browser zu verwenden:

Beim ersten Zugriff auf die Session speichere ich in der Session einen HASH-Key als Schlüssel eines Arrays (beinhaltet widerum auch ein Array) mit einem UNIX-Timestamp (aktuelle Zeit + konfigurierbarer Timeout) als einen Wert dieses Array-Elements und einem Boolean als anderen Wert (Speichert, ob dieser Key bereits aufgerufen wurde oder nicht). Zusätzlich wird der HASH-Key als Cookie gespeichert, um beim nächsten Seitenaufruf wieder an den Server übertragen zu werden.

Das Array sieht dann etwa wie folgt aus:

PHP-Code:

$_SESSION['arrayAuthorisationCheck']['hierDerHashKey'] = array ('booleanUsed' => FALSE, 'integerTimeout' => (time () + $integerTimeout)); 


Soweit so gut, es gibt also einmal die ID zur Session und den HASH-Key als Cookie. Beim nächsten Seitenaufruf wird geschaut, ob der Timestamp zum HASH-Key in der Session abgelaufen ist. Ist dies der Fall oder ist der HASH-Key garnicht in der Session enthalten, wird die Session geschlossen und als ungültig erkannt. Befindet sich der HASH-Key in der Session und der Timestamp ist noch nicht abgelaufen, wird der Boolean-Wert überprüft. Steht er noch auf "FALSE", wird er auf "TRUE" gesetzt, der Timeout neu gesetzt und ein neu generierter HASH in der Session (wie oben auch schon) angelegt, als Cookie verschickt und für den aktuellen HASH als "neuer HASH" im String gespeichert. Steht der Boolean bereits auf "TRUE", wird kein neuer HASH generiert, sondern die Session "lediglich" als gültig anerkannt. Ein neuer HASH-Key wurde ja bereits übermittelt.
Dies hat folgenden Hintergrund: Jeder Hash soll, bis er verwendet wurde, die Gültigkeitsdauer wie eine Session selbst haben (z.B. 15 Minuten). Befindet man sich auf einer Seite mit mehreren Links, die man gleichzeitig öffnet (z.B. Forum, Gallery, etc.), die alle auf die selbe Seite mit der Session zugreifen, wird auch bei nahezu jedem Aufruf der gleiche HASH-Key übermittelt. Würde jetzt nach erstmaliger Benutzung der HASH-Key gelöscht und somit ungültig werden, wäre nur eine Seitenanfrage gültig und der Rest würde mit Fehler abgebrochen. Um dies zu überbrücken, sollte nach der ersten Verwendung der HASH noch für z.B. 30 Sekunden gültig bleiben, bevor er dann gelöscht wird.

Ich finde, dass durch diese Methode die Möglichkeit eine Session zu erschleichen deutlich sinkt, auch wenn sie nicht zu 100% gebannt ist. Aber wie ich eh immer sage: Es gibt keine 100%ige Sicherheit.

Was mich nach meinem doch recht ausschweifendem Post jedoch interessiert ist, was ihr davon haltet!? Ich habe diese Methode bereits erfolgreich in mein CMS (noch eine Alpha) integriert und ohne Probleme getestet - bisher.

ich hoffe ihr versteht alle die Arbeitsweise dieser Technik!?

[phpdev]

Danke für eure Antworten

Mir gehts eigentlich darum die beste Möglichkeit zu finden den user zu identifizieren, aber auch um die Sicherheit des Users.
Hätte ich gleich sagen sollen, sorry.
Ich habe das so verstanden, das wenn man session_start() verwendet, automatisch versucht wird einen Cookie zu setzen und wenn der User Cookies deaktiviert hat ist man gezwungen das ganze per Hand (URL) weiterzugeben.
Ist das so richtig?

Ich bin noch nicht lange dabei PHP zu programmieren, deswegen auch die Frage, wird die Session ID bei vielen Webanwendungen weitergegeben und anhand derer der user identifiziert ?

Oder welche Methoden sind da so üblich ?

EDIT: MrNiceGuy hab deinen Beitrag jetzt erst gesehen, das lese ich mir doch gleich mal genau durch

[MrNiceGuy]

Also Cookies sind ansich üblich für die Verwendung von Session-IDs und ich muss auch ganz ehrlich sagen, dass ich persönlich nichts anderes verwenden würde. Die Einstellung "session.use_only_cookies = 1" in der php.ini sollet meiner Meinung nach immer gesetzt sein. Es ist zwar "schlecht", User auszuschließen, die keine Cookies aktiviert haben, da es sich bei einem Cookie jedoch um reine Textinformationen handelt, sehe ich hier keien Gefahr für einen User.
Ich weiß zwar, dass es sich nicht gehört, User wegen anderer Einstellungen "auszuschließen" und zu sagen, dass es ihr eigenes Problem sei, aber in diesem Fall muss ich einfach sagen, dass für mich das Verständnis aufhört, weil der Aufwand, den man betreiben muss, irgendwo nicht gerechtfertigt ist. Einfacher wäre dann wohl eher ein dezenter Hinweis mit einem gut formuliertem Text, der die Leute darauf hinweißt, dass die Cookies dieser Seite nichts böses sind und lediglich der Identifizierung für diese eine Session notwendig machen und diese zu aktivieren sind.
Man erwischt in der Regel so oder so keine Leute, die nicht wissen, wie man Cookies aktiviert, da eigentlich alle Browser standardmäßig Cookies an haben (zumindest alle, die ich je benutzt habe) und somit lediglich Sicherheitsfanatiker und Leute mit paranoider Schitzophrenie ihre Cookies deaktivieren. Diese Leute wissen dann aber auch, wie sie das wieder rückgängig machen können.

[dago]

Hallo MrNiceGuy,

würde aber nicht auch das gehen:

PHP-Code:

$_SESSION['arrayAuthorisationCheck']['hierDerHashKey'] = (time () + $integerTimeout); 


und anstatt "booleanUsed" auf TRUE zu setzen, einfach das:

PHP-Code:

$_SESSION['arrayAuthorisationCheck']['hierDerHashKey'] = FALSE;
// oder
unset($_SESSION['arrayAuthorisationCheck']['hierDerHashKey']); 


Aber ich verstehe denn Sinn dahinter nicht. Das man ein Hash im Cookie zur Wiedererkennung abspeichert ist mir klar. Dieser Setzt sich aber dann auch aus Userdaten zusammen. Einen extra zufällig generiertes Hash pro Seitenaufruf erscheint mir unsinnig. Denn was soll das jetzt genau bringen. Verstehe da dich nicht ganz.

Das denke ich würde das gleiche bringen:

PHP-Code:

$_SESSION['integerTimeout'] = (time () + $integerTimeout); 


[MrNiceGuy]

Natürlich würde das gehen, nur wie ich in meinem Text schon geschrieben hatte: Wenn dann mehrere Seitenaufrufe quasi-gleichzeitig erfolgen, führt nur die Erste davon zum Erfolg, der Rest wäre ungültig.

Der Sinn, weshalb bei jedem Seitenaufruf ein neuer Hash-Key generiert wird ist ganz einfach: Es wird schwieriger für Dritte sich in genau diese Session reinzumogeln, da der Hash-Key spätestens nach der Timeout-Zeit nicht mehr gültig ist (das ist der Maximalfall).

Der Hash-Key muss nicht aus Benutzerdaten bestehen, da kann auch ein md5 () über einen microtime () genutzt werden. microtime () liefert bei jeder Anfrage ein anderes Resultat, da PHP-Scripte nacheinander abgearbeitet werden und somit gewährleistet wird, dass der Key auch eindeutig ist. Man kann aber auch die Funktion uniqid () verwenden oder sich irgend etwas anderes tolles einfallen lassen

[dago]

Zitat von MrNiceGuy

Natürlich würde das gehen, nur wie ich in meinem Text schon geschrieben hatte: Wenn dann mehrere Seitenaufrufe quasi-gleichzeitig erfolgen, führt nur die Erste davon zum Erfolg, der Rest wäre ungültig.

Der Sinn, weshalb bei jedem Seitenaufruf ein neuer Hash-Key generiert wird ist ganz einfach: Es wird schwieriger für Dritte sich in genau diese Session reinzumogeln, da der Hash-Key spätestens nach der Timeout-Zeit nicht mehr gültig ist (das ist der Maximalfall).

Also mir reicht da eine Timeout-Zeit der Session. Also die Zeit wie lange ein Benutzer bei Inaktivität noch angemeldet bleibt.


Aber um das noch genau zu verstehen, was du damit vor hast. Wenn ich jetzt 10mal auf ein Link klicke und jedesmal ein neues Fenster öffne. Dann bin ich so 20min nur noch im letzten Fenster unterwegs.
Wenn ich jetzt wieder zum 4. Fenster gehe, müsste dann ja der Hash der ja beim letzten Aufruf des Fensters erzeugt wurde, ungültig werden. Also müsste ich in diesem Fenster abgemeldet sein. Aber im letzten Fenster wo ich zuletzt aktiv war noch angemeldet.

Verstehe ich deine Motivation richtig?

Dies würde aber nicht funktionieren. Denn dazu müsste das ursprüngliche Fenster nicht von Cookies des aufgerufenes Fensters wissen. Aber so weit mir bekannt gelten die Cookies Browserweit. Also verhält sich das arbeiten mit mehreren Fenstern genauso wie mit nur einem.


EDIT: Oder missverstehe ich deine Absicht? Und du versuchst damit nur das entwenden des Cookies zu verhindern. (bzw. des darin enthaltenen Hashes) Aber das erscheint mir auch als unnötig.

[MrNiceGuy]

Stopp. Bevor wir weiter aneinander vorbeireden: Was ich meinte ist folgendes...

Nehmen wir mal an, du befindest dich auf dieser Seite im Forum "PHP-Programmierung". Es gibt dort 3 interessante Themen, die du möglichst gleichzeitig öffnen willst, damit die 2 übrigen Themen, sich schön öffnen, während du das eine schon am Lesen bist. Du klickst also z.B. mit gehaltener SHIFT-Taste auf die 3 Links und es öffnen sich 3 weitere Fenster. Je anch Verbindung, Geschwindigkeit des Servers, etc. lädt die Seite im ersten Fenster noch, während du die nächsten 2 Fenster durch die klicks öffnest.

So weit, so gut. Alle 3 Fenster werden jetzt mit dem selben Hash als Cookie geöffnet, allerdings wird das 2. Fenster erst dann anfangen die Daten zu laden, sobald das Script im ersten Fenster die Session geschlossen hat (PHP blockiert die Sessions, bis sie nicht mehr benötigt werden, das ist aber ein anderes Thema) und das 3. lädt erst, wenn das 2. die Session nicht mehr braucht. Wenn du nun im 1. Fenster schon den Hash aus der Session löschen würdest, könnten die Fenster 2 und 3 nicht mehr erfolgreich ausgeführt werden, weil der Hash, der bei ihnen übergeben wird nicht mehr existiert. Die Anfrage wurde ja schon gestellt, bevor das erste Script abgearbeitet war und den neuen Hash übertragen konnte.

Deswegen habe ich die Übergangszeit von z.B.20 oder 30 Sekunden, um dies zu verhindern. So lange wäre der Hash dann noch aktiv. Der Boolean ist eigentlich nur dazu da, damit nur das 1. Fenster einen neuen Hash generiert und als Cookie zurückschickt. Auf diese Weise gibt es bei allen 3 Fenstern zusammen nur einen neuen Hash (weniger Berechnungszeit, weniger Transfer, weil kein neuer Hash als Cookie an den Browser geschickt werden muss, das Array in der Session bleibt so klein wie nötig, etc.), wohingegen ohne den Boolean bei allen 3 Fenstern ein neuer Hash erzeugt und verschickt würde. Davon würde beim nächsten Seitenaufruf jedoch nur der letzte wieder übertragen werden und die übrigen Hashes sind sinnlos und verbrauchen für die Dauer ihrer Existenz nur Speicherplatz und mehr nicht. Außerdem steigt das Risiko, dass sich jemand in diese Session einschleichen kann, da die Anzahl gültiger Hashes steigt.

Ich hoffe, dass ich einigermaßen klar rüberbringen konnte, was ich meine!? Ich versuche das nochmal alles in einem kleinen PAP darzustellen und zu posten, das könnte aber noch ein bisschen dauern, bis ich da die Zeit zu habe.

EDIT: Hier nun das Struktogramm, wie ich es meinte, vielleicht bringt das ein bisschen Licht ins Dunkel!?

[dago]

Ach, vielen Dank für deine ausführliche und gute Erklärung! Aber so weit komme ich eigentlich garnicht. Ich verstehe nicht wozu du mehre Hashes erstellst.

Ich generiere ein Hash nur beim start einer Sitzung, Besipiel:

PHP-Code:

$hash1 = sha1($username . $browser . $ip); 


und auch nur eines zusätzliches beim Login, Beispiel:

PHP-Code:

$hash2 = sha1( uniqid( rand() ) ); 


Diese beiden lege ich nun im Cookie aber auch in der Session zum abgleich ab. Dazu noch den TIMESTAMP der letzten Aktivität des Benutzers. Fertig!

Es muss kein weiterer Hash erstellt werden oder diese ersetzt werden, bis der Benutzer eine bestimmte Zeit inaktiv gewesen ist.

In wie weit ist deine Lösung sicherer wie diese hier?

[Jann Hendrik]

da du die IP mit einbeziehst solltest folgendes beachten:
29.15. Warum verwendet PHP nicht die IP-Nummer des Browsers als Schutz gegen eine Übernahme der Session?
insbesondere den Teil:

Die sichtbare IP-Nummer eines Benutzers kann während der Session wechseln.

[Waq]

Zitat von phpdev

ich überlege mir gerade wie ich eine Session Klasse am besten schreiben kann.

Das ist IMHO schonmal der erste Fehler. Benutz die PHP-eigenen Sessions, setze bei Bedarf einen eigenen Speichermechanismus drunter (http://de3.php.net/manual/en/functio...ve-handler.php) und geeignete Sicherheitsmechanismen oben drauf.

Einen Login würdest Du so bauen, dass nach erfolgreicher Passwortabfrage in der Session gepeichert wird, dass der User eingeloggt ist, fertig. Unverschlüsselt natürlich, da auf dem Server.

Warum? Weil Sessions eine Solide Implementation sind, um Daten mitzuschleppen, denn z.B. ...

Zitat von phpdev

Ich habe das so verstanden, das wenn man session_start() verwendet, automatisch versucht wird einen Cookie zu setzen und wenn der User Cookies deaktiviert hat ist man gezwungen das ganze per Hand (URL) weiterzugeben.

... ist das genau falsch. PHP-Sessions können, falls Du es so einstellst und Cookies nicht angenommen werden, die Session-Id automatisch an jeden Link anhängen.

[MrNiceGuy]

@dago: Dadurch, dass ein einzelner Hash nur für eine begrenzte Zeit (bei mir z.B. 15 Minuten) gültig ist, verkleinere ich das Fenster für jemanden, der sich unerlaubt Zutritt zu dieser Session verschaffen möchte auf maximal 15 Minuten. Wenn du nur ein Mal diese Hashes am Anfang der Session erstellst, ist das Fenster zum Einschleichen in die Session so groß, wie die Session selbst aktiv ist, also im Groben: Vom Login bis zum Logout.

Ein Beispiel: Was ist wahrscheinlicher? Dass eine Fußballmannschaft in 15 Minuten ein Tor schießt oder in 90?

Natürlich MUSS man das ja nicht so machen. Es ist nur eine Methode, die ich mir selber für mich überlegt habe, die relativ einfach zu realisieren ist und meiner Meinung nach eine vergleichsweise hohe Sicherheit bietet.

@Waq: Das ist soweit richtig. Jetzt aber mal eine Frage an die Allgemeinheit von mir: Würdet ihr eine andere Session-Authentifikation als Cookies zulassen?

[Waq]

Zitat von MrNiceGuy

Also Cookies sind ansich üblich für die Verwendung von Session-IDs und ich muss auch ganz ehrlich sagen, dass ich persönlich nichts anderes verwenden würde.

Da seit der Erfindung der XSRF-Attacke Session-IDs in Keksen kein bisschen sicherer sind als in der URL, ist das so mittlerweile Unsinn.
http://de.wikipedia.org/wiki/XSRF

Zitat von MrNiceGuy

[..] dass für mich das Verständnis aufhört, weil der Aufwand, den man betreiben muss, irgendwo nicht gerechtfertigt ist.[..]

Welcher Aufwand? session_use_only_cookies wieder anzuschalten?

Zitat von MrNiceGuy

Einfacher wäre dann wohl eher ein dezenter Hinweis mit einem gut formuliertem Text, der die Leute darauf hinweißt, dass die Cookies dieser Seite nichts böses sind [..]

Da doch lieber ein dezenter Hinweis, dass der User, da er ja keine Cookies nimmt, bitte auf seine Session-ID aufpassen und die URLs nicht weitergeben möge. Rausschmeissen muss man ihn dafür nicht.

Für die Weitergabe/Mitbenutzung von Session-IDs gibt es folgende einfachen Möglichkeiten:
- Weitergabe der URL durch den User (durch o. g. Warnung eindämmbar?)
- URL wird bei ausgehenden Links als Referrer an fremde Seiten weitergegeben (durch Redirect vor ausgehenden Links verhinderbar, potentiell nichttriviale Aufgabe)
- XSRF-Attacke auf den Keks (verhinderbar durch zus. shared secret per URL/Hidden-Feld)

Da es aber keinen "einfachen" Angriff sowohl auf die URL als auch auf den Keks gibt, sollte man IMHO, um halbwegs sicher zu sein, beides machen.
Strukturell am Einfachsten ist es hierbei, die Session-ID erstmal grundsätzlich in die URL zu tun (per session_use_cookies=0, um trans-sid nutzen zu können), und eine zusätzliche ID per Keks durchzuschleifen, die natürlich in der Session gespeichert wird.
Wenn man einen Cookie-Check einbaut, kann man den Keks auch optional halten.

PS: Ich hatte eine etwas längere Diskussion zu dem Thema hier: http://phpforum.de/forum/showthread....highlight=xsrf
Ich will das nicht alles nochmal wiederholen *g*

[dago]

Zitat von Jann Hendrik

da du die IP mit einbeziehst solltest folgendes beachten:
29.15. Warum verwendet PHP nicht die IP-Nummer des Browsers als Schutz gegen eine Übernahme der Session?
insbesondere den Teil:

Jup, ist klar. Wahr jetzt nur als Beispiel.


@MrNiceGuy
Gut bei meiner Version währen es 15 Minuten + Aktivitätszeit des Benutzers. Ich hab nur aufgrund deiner Erklärung angenommen gehabt, dass du damit mehr bezweckst.

Danke für deine Erläuterungen!

[MrNiceGuy]

Hmm... OK, klingt auch irgendwie einleuchtend @Waq. Ich bezweifle allerdings, dass ein Otto-Normal-Verbraucher versteht, weshalb er die URL nicht weitergeben sollte und diese Regel entsprechend umsetzt!?. Im Grunde muss man eigentlich sagen, dass es keine praktikable Lösung für das Problem gibt und man - egal, was man nun anwendet - den Bedienkomfort in gewissen Dingen einschränken muss.

Also ich für meinen Teil schließe jedoch lieber Benutzer aus, die ihre Cookies nicht aktiviert haben, als dass ich darauf hoffen muss, dass die DAUs ihre URLs nicht weitergeben...

[mepeisen]

Zitat von MrNiceGuy

microtime () liefert bei jeder Anfrage ein anderes Resultat, da PHP-Scripte nacheinander abgearbeitet werden

Das vor dem Komma ist im Normalfall richtig, man sollte sich aber nicht drauf verlassen. Das nach dem Komma ist schlichtweg falsch. Wollte es nur nochmal herausstellen, denn das Session-Blockieren hat nichts mit der Abarbeitung des gesamten Scriptes zu tun.

Zitat von Jann Hendrik

da du die IP mit einbeziehst solltest folgendes beachten:
29.15. Warum verwendet PHP nicht die IP-Nummer des Browsers als Schutz gegen eine Übernahme der Session?
insbesondere den Teil:

Logischerweise richtig. Wobei das selten vorkommt. Einige Stundentenbuzzen machen so komische Sachen. Und wenn sich einer neu ins Internet einwählt hat er Pech gehabt Aber mal das Model heisse als Vorbild: "Login auf diese IP beschränken." Also den Grad der Sicherheit vom User selbst bestimmen lassen.

Und wie ich eingangs schrieb: Es geht eigentlich nur darum, den User zuverlässig wiederzuerkennen. Es gibt für dieses Problem eine Handvoll Variationen. Im Grundkonzept läuft es darauf hinaus, eine Session-ID zu erhalten (die ja gegenüber verschlüsselten Passwort/User-Kombinationen den Vorteil hat, dass sie relativ anonym ist). Da gibt es grundsätzlich nur 2 (bzw. 3) Möglichkeiten: Cookies, Get, Post. Mehr kann HTTP einfach nicht. Und es gibt nur die Option, das ganze durch Timeouts oder zusätzliche Identifikationsmerkmale/ Referrer-Abfrage halbwegs sicher zu machen, so dass die Hürde für einen Angreifer größer wird.
Irgendwelche Hashes in der Session selbst zu hinterlegen und diese dann wieder zu übergeben, ist sicherlich interessant, aber man handelt sich gleich eine Reihe neuer Probleme ein (z.B. Browser-Zurück-Button funktioniert grundsätzlich nicht mehr), die einem bewusst sein müssen. Wenn einer einfache Session-Cookies nicht abzeptiert heutzutage, mag er Pech haben, das sollte ihn aber nicht davon abhalten, die Webseite zu nutzen. Leider ist die Diskussion an dieser Stelle müßig, da es sachlich kaum Argumente für eine wirklich vernünftige und sichere Lösung gibt. Jeder sollte das machen, was er kann und will und sich bewusst sein, welche Risiken er eingeht. 100%ige Sicherheit gibt es nicht. Es gilt lediglich, die Hürden so hoch zu legen, dass es keinem 08/15 "Hacker" möglich ist, sich einer Session zu bemächtigen. Fertig.

[MrNiceGuy]

Zitat von mepeisen

Das vor dem Komma ist im Normalfall richtig, man sollte sich aber nicht drauf verlassen. Das nach dem Komma ist schlichtweg falsch. Wollte es nur nochmal herausstellen, denn das Session-Blockieren hat nichts mit der Abarbeitung des gesamten Scriptes zu tun.

Ich bezog die Aussage hauptsächlich auf die Prozessorarchitektur, da dieser nur nach und nach die Daten verarbeitet. Außerdem arbeiten PHP-Scripte ganz normal von "oben nach unten", also ist die Aussage auch in dieser Hinsicht nicht wirklich falsch oder verstehe ich dich nur gerade falsch?
OK, in Multiprozessor-Systemen können auch mal 2 Scripte parallel abgearbeitet werden. Aber: Wie wahrscheinlich ist es bitte, dass wirklich beide Anfragen zu genau der selben µsec abgearbeitet werden? Und dann kommt noch dazu, dass in diesem super unwahrscheinlichen Fall lediglich 2 User ein und den selben Hash-Key haben. Na und? Das stört das System ja nicht und vereinfacht einem "Hacker" auch nicht im Geringsten die Arbeit.

Achso, btw: Der Browser-Zurück-Button funktioniert mit meiner Methode ohne Probleme.

EDIT: Du hast allerdings recht, dass es kein vernünftiges System zur Wiedererkennung gibt. Jede Technik der Wiedererkennung birgt die Gefahr, dass sich jemand unrechtmäßig Zugang zu der Webseite verschafft, weil er irgendwie an die lokal gespeicherten Daten kommt. Fraglich ist nur, was einfach ist: An diese Daten zu kommen oder irgendwo einfach das Kennwort mitschneiden!?

[mepeisen]

Zitat von MrNiceGuy

Ich bezog die Aussage hauptsächlich auf die Prozessorarchitektur, da dieser nur nach und nach die Daten verarbeitet. Außerdem arbeiten PHP-Scripte ganz normal von "oben nach unten", also ist die Aussage auch in dieser Hinsicht nicht wirklich falsch oder verstehe ich dich nur gerade falsch?

Auch der Bezug auf die Prozessorarchitektur ist falsch.
Du hast es auf microtime bezogen. Microtime liefert dir nur einen Timestamp, mehr nicht. Dass dieser Timestamp immer unterschiedlich bzw. dass zwischen zwei Aufrufen genug Zeit vergangen ist, so dass er unterschiedlich ist, wird nirgendwo garantiert.

OK, in Multiprozessor-Systemen können auch mal 2 Scripte parallel abgearbeitet werden.

Nicht nur in Multiprozessor-Systemen (davon abgesehen, dass Profi-Hoster von Webspaces oft genug Multi-Prozessor-Systeme nutzen). Es gibt inzwischen auch Hybrid-Prozessoren, wie Intels HT-Technologie. Die sind teilweise derart geschickt, dass sie teilweise zwanzig oder vierzig Anweisungen (auf Assembler-Ebene logischerweise) parallel verarbeiten und Ergebnisse (in der Hoffnung, die Ausgangssituation ändert sich nicht) vorausberechnen. Das führt aber denke ich zu weit. Selbst in Systemen mit einem Kern ist es nicht gesagt, dass immer genau ein Script nach dem anderen abgearbeitet wird. Threads, Prozesse...

Aber: Wie wahrscheinlich ist es bitte, dass wirklich beide Anfragen zu genau der selben µsec abgearbeitet werden? Und dann kommt noch dazu, dass in diesem super unwahrscheinlichen Fall lediglich 2 User ein und den selben Hash-Key haben. Na und? Das stört das System ja nicht und vereinfacht einem "Hacker" auch nicht im Geringsten die Arbeit.

Das habe ich nicht gesagt. In meinen Augen ist das ganze System auch überflüssig, aber das sei mal dahingestellt. Es geht um die Eindeutigkeit und die Erklärung dazu, um nichts anderes ging es mir, denn die Erklärung ist falsch, genauso wie die Annahme, microtime ist immer eindeutig. Sicherlich ist es unwahrscheinlich, aber nicht unmöglich. Um das in Wahrscheinlichkeit auszudrücken muss man die Randfaktoren mit dazu nehmen (wie oft werden Scripte aufgerufen etc. pp.). So abwägig ist es bei Webseiten, die einen hohen Workload haben, nicht. Im übrigen kommt dazu, dass bei microtime() nicht auf allen Betriebssystemen die kleinste mögliche Zeiteinheit gemessen und zurückgegeben wird. Das mag jetzt wie Erbsenzählerei klingen, aber wenn man solche falsche Annahmen für bare Münzen nimmt und sich darüber eine Eindeutigkeit erhofft, kann das nach hinten losgehen und kann zu Fehlern führen, die man schlichtweg nie (oder nur zufällig) nachstellen und finden kann.

Achso, btw: Der Browser-Zurück-Button funktioniert mit meiner Methode ohne Probleme.

Dürfte er nicht bei Übergabe in einer URL, da der zuvor mitgelieferte Hash dann ungültig sein muss. Zusammen mit der Ausgangssituation (Ich sperre alle, die keien Cookies erlauben) hast du wohl Recht...

EDIT: Du hast allerdings recht, dass es kein vernünftiges System zur Wiedererkennung gibt. Jede Technik der Wiedererkennung birgt die Gefahr, dass sich jemand unrechtmäßig Zugang zu der Webseite verschafft, weil er irgendwie an die lokal gespeicherten Daten kommt. Fraglich ist nur, was einfach ist: An diese Daten zu kommen oder irgendwo einfach das Kennwort mitschneiden!?

Müßig zu diskutieren. Fakt ist, dass man die einfachste Methode ausschliessen sollte (Link Copy&Paste inkl. Session-ID). Das ist bereits eine entsprechende Hürde. Sicherheitsrelevante Funktionen kann man beispielsweise sinnvoll per Captcha schützen, so auch das Ändern des Passwortes. Dann gehts halt nicht darum, Bots auszusperren, sondern ein zusätzliches Identifikationsmerkmal zu haben. Oder auch einfach deine Methode, die ist ja im Ansatz nicht schlecht Wie auch immer man dies löst. Alles weitere sollte man IMHO dem User selbst überlassen, wobei man die höchst mögliche Sicherheit per Default setzt, jedoch jedem selbst überlässt, beispielsweise auch das Passwort und den Usernamen verschlüsselt per Cookie auf dem Rechner abzulegen oder solche Geschichten. Aber das bleibt jedem überlassen denke ich, zumal es wenig Variationsmöglichkeiten gibt.

[MrNiceGuy]

Ich glaube, dass eine Diskussion über Prozessorarchitektur usw. jetzt etwas zu sehr am Thema vorbei geht. Ich schreibe dir mal eine PN, wenn das genehm ist.