Login mit Session - Tutorial gesucht

[kEv*]

Begrüßung ('Hallo'),

ich suche ein Tutorial für ein Login welches Sessionbasiert ist. Da ich mich bei Goggle umgesehene habe, und leider nicht so recht das passende für mich dazu gefunden habe, frage ich einmal bei euch nach.

Kennt wer gute Tutorials, wo etwas zu den einzelnen Techniken gesagt wird?
Mein Ziel soll sein, ein eigenes zu schreiben, wo der Benutzer seinen Benutzernamen einträgt, und logischerweise das entsprechende Passwort.
Nach erfolgreichem Login, möchte ich dann bei jedem Aufruf der Seiten die einen eingeloggten User verlangen prüfen, ob der User wirklich zur Session passt.

Desweiteren stellt sich mir die Frage, wie ich die Session für eine neues Seite übergebe? Per URL?

Vielleicht habt ihr ja noch ein paar Tipps ein anständiges Login zu erstellen. Worauf sollte ich ganz speziell achten?
Ich bin für eure bereits im Vorraus dankbar, und wünsche einen schönen Freitag.

AufWiedersehen ('Vielen Dank'),
LG
--
kEv*
----

[Dennis]

Hi kEv*,

ich suche ein Tutorial für ein Login welches Sessionbasiert ist. Da ich mich bei Goggle umgesehene habe, und leider nicht so recht das passende für mich dazu gefunden habe, frage ich einmal bei euch nach.

Du kennst den Artikel Sessionbasiertes Loginsystem bei SELFHTML? Welche Teile davon waren dir unverständlich, sodass du sie detailierter erklärt haben willst?

Viele Grüße aus Kanada,
  ~ Dennis.

[Tom]

Hello Dennis,

ich war lange nicht hier und will deshalb auch gar nicht meckern...

Du kennst den Artikel Sessionbasiertes Loginsystem bei SELFHTML? Welche Teile davon waren dir unverständlich, sodass du sie detailierter erklärt haben willst?

Der Artikel zeigt aber nur die allerersten Anfänge.
Wichtig ist mMn, dass man sich über die Funktionsweise bei Sessions allgemein und insbesondere, wie sie _automatisch_ von PHP unterstützt werden, Gedanken machen muss.

Das Verfahren der Session basiert nur auf einem "seltenen Schlüssel" oder einem "verlorenen Schlüssel". Da dem Schlüssel bei diesem Verfahren ein Gegenstück fehlt, kann man nicht von einem "zertifizierten Schlüssel" sprechen.

Aufgrund des erteilten Schlüsselwertes wird die Re-Identifikation des Besuchers betrieben, aber keine Authentifizierung.

Identifikation    (hier) = Gleichsetzung mit einem Userkonto
Authentifizierung (hier) = tatsächliche und absolute Identifikation betreiben
                           Überprüfung anhand einer genügenden Anzahl von Kriterien,
                           die der eineindeutigen Identifikation dienen

Das soll heißen, dass man gerade aktive Session-Schlüssel erraten kann. Das geht besonders gut, wenn Schlüssel aufgrund der Vergabeverfahrens mit Hilfe der Zeitkomponente erteilt werden. Dann vermindert sich nämlich der verfügbare Schlüsselvorrat auf eine sehr überschaubare Zahl.

Daher sollte man für ein vernünftiges Session-Management immer ZWEI Schlüssel erteilen, die beide vorhanden sein müssen. Damit reduziert sich die Trefferwahrscheinlichkeit erheblich.
Wenn dann auch noch jeder einzeln mehrfach vorhanden sein kann, erhöht das die "Intruder Detection Quote". Jeder realisierte "Fehlschuss", bei dem also nur einer der beiden Schlüssel getroffen wurde, veranlasst ein solches System, möglichst intelligent zu reagieren.

Aber das ist ein weites Feld...

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Sven Rautenberg]

Moin!

Das soll heißen, dass man gerade aktive Session-Schlüssel erraten kann.

Das bezweifle ich doch extrem! Zumindest was den Standardmechanismus für PHP angeht.

Das geht besonders gut, wenn Schlüssel aufgrund der Vergabeverfahrens mit Hilfe der Zeitkomponente erteilt werden. Dann vermindert sich nämlich der verfügbare Schlüsselvorrat auf eine sehr überschaubare Zahl.

Die zeitliche Komponente sorgt aber, vor allem dann, wenn man sehr genau mißt, für eine gute Zufallskomponente, insbesondere wenn man danach Hashverfahren wie MD5 nachschaltet und noch ein paar weitere Daten mit einfließen läßt. Damit ist aus der selbst erhaltenen Session-ID keinerlei Rückschluß auf die dabei eingeflossene Zeit und auch nicht auf mögliche Nachbarsessions möglich.

Ansonsten darfst du gerne einen Beispielangriff demonstrieren.

Daher sollte man für ein vernünftiges Session-Management immer ZWEI Schlüssel erteilen, die beide vorhanden sein müssen. Damit reduziert sich die Trefferwahrscheinlichkeit erheblich.

Jetzt kommt dieser Unsinn wieder.

Wie wahrscheinlich bekannt sein sollte, realisieren sich Sessions durch die Nutzung einer Session-ID, damit der Server den Nutzer wiedererkennt. Was sollen dann ZWEI Session-IDs qualitativ bringen? Wenn dir die Länge der einen Session-ID nicht gefällt, dann integriere einen eigenen Mechanismus, der dir längere IDs generiert. Ist mit PHP recht problemlos möglich, einfach session_id() mit der neuen ID aufrufen, bevor session_start() aufgerufen wird.

Denn wo wäre der Unterschied, ob man den URL-Parameter ?sess1=xxxxxxx&sess2=yyyyyyy erraten muß, oder ?sess=xxxxxxxyyyyyyy - die Zahl der korrekt zu erratenden Zeichen ist gleich.

Deine Forderung nach "zwei" bringt qualitativ also nichts, es bringt nur quantitativ etwas - es steigert die Suchdauer von "hundert Universumsleben" auf "hundert Quadrillionen Universumsleben" - was in beiden Fällen extrem viel länger ist, als ein Menschenleben dauert.

Wenn dann auch noch jeder einzeln mehrfach vorhanden sein kann, erhöht das die "Intruder Detection Quote". Jeder realisierte "Fehlschuss", bei dem also nur einer der beiden Schlüssel getroffen wurde, veranlasst ein solches System, möglichst intelligent zu reagieren.

Du sprichst wirr. Erkläre dich. Eine Session-ID ist genau einmal vorhanden.

- Sven Rautenberg

[Tom]

Hello,

Das soll heißen, dass man gerade aktive Session-Schlüssel erraten kann.

Das bezweifle ich doch extrem! Zumindest was den Standardmechanismus für PHP angeht.

Das erstaunt mich nun wiederum!
Du weißt doch schließlich um die Fachausdrücke, oder?
Hier liegt "Erratbarkeit" vor.

Das bedeutet im Klartext, dass beim zufälligen oder absichtlichen Treffen eines Schlüssels durch einen Unbefugten keine weitere Erkennung vorliegt.

Das geht besonders gut, wenn Schlüssel aufgrund der Vergabeverfahrens mit Hilfe der Zeitkomponente erteilt werden. Dann vermindert sich nämlich der verfügbare Schlüsselvorrat auf eine sehr überschaubare Zahl.

Die zeitliche Komponente sorgt aber, vor allem dann, wenn man sehr genau mißt, für eine gute Zufallskomponente, insbesondere wenn man danach Hashverfahren wie MD5 nachschaltet und noch ein paar weitere Daten mit einfließen läßt. Damit ist aus der selbst erhaltenen Session-ID keinerlei Rückschluß auf die dabei eingeflossene Zeit und auch nicht auf mögliche Nachbarsessions möglich.

Zusätzliche "Wiederverwirrspiele" können einen eingeschränkten Schlüselvorrat tatsächlich fast auf ihren eigenen vollen Umfang (also den Schlüsselvorrat des Verwirrspiels) abbilden, aber nicht wieder auf den ursprünglichen spreizen. Außerdem ist das Verfahren bekannt und damit von dem ursprünglichen eigeschränkten Vorrat jederzeit replizierbar nachvollziehbar.

Bitte denke nochmals nach. Das ist einfachste Mengenlehre.

Ansonsten darfst du gerne einen Beispielangriff demonstrieren.

Das ist doch eher rhetorisch von Dir und damit äußerst unfair, da Du doch weißt, dass ich sowas niemals demonstrieren würde

Daher sollte man für ein vernünftiges Session-Management immer ZWEI Schlüssel erteilen, die beide vorhanden sein müssen. Damit reduziert sich die Trefferwahrscheinlichkeit erheblich.

Jetzt kommt dieser Unsinn wieder.

Ich werde Dir anstelle eines Beispielangriffes lieber ein paasr etablierte Mathematiker liefern, die Dir meine Überlegungen bestätigen werden. So langsam reichts mir nämlich mit Dir ;-))
Also werde ich's jetzt langsam mal in Angriff nehmen und die Unis beballern...

Wie wahrscheinlich bekannt sein sollte, realisieren sich Sessions durch die Nutzung einer Session-ID, damit der Server den Nutzer wiedererkennt. Was sollen dann ZWEI Session-IDs qualitativ bringen?

Hatte ichj eigentlich erklärt, welchen Unterschied zwei Schlüssel gegenüber einem haben.
Jeder einzelne Schlüssel ist für sich dabei mehrfach nutzbar, das Pärchen ist unique. Nur mit Pärchen ist Authentizität anzunehmen. Identifikation liefert schon jeder Schlüssel für seinen Bereich einzeln.

Wenn dir die Länge der einen Session-ID nicht gefällt, dann integriere einen eigenen Mechanismus, der dir längere IDs generiert. Ist mit PHP recht problemlos möglich, einfach session_id() mit der neuen ID aufrufen, bevor session_start() aufgerufen wird.

Denn wo wäre der Unterschied, ob man den URL-Parameter ?sess1=xxxxxxx&sess2=yyyyyyy erraten muß, oder ?sess=xxxxxxxyyyyyyy - die Zahl der korrekt zu erratenden Zeichen ist gleich.

Deine Forderung nach "zwei" bringt qualitativ also nichts, es bringt nur quantitativ etwas - es steigert die Suchdauer von "hundert Universumsleben" auf "hundert Quadrillionen Universumsleben" - was in beiden Fällen extrem viel länger ist, als ein Menschenleben dauert.

Du hast hier einige Mechanismen und die Logik dahinter scheinbar noch nicht verstanden.
Wir haben oft genug darüber diskutiert. Ein Sessionverfahren ohne Prüfverfahren ist (zumindest theoretisch) ein offenes Scheunentor. Es mag zutreffen, dass ich auf meinem 486/DX266 in angemessener Zeit mit einem guten Assemblerprogramm keinen vernünftigen Schlüssel finden werde, also einen, der passt, aber wer hat denn heute noch solche Geräte im Einsatz?

Der Einzige Schutz, der hier besteht, ist die eingeschränkte Response-Time (also die relativ lange) gepaart mit der verfügbaren Bandbreite der Netze, die heute existieren.

Du sprichst wirr.

Das gebe ich zurück, was ich gerade bei Die sehr bedaure :-)

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Sven Rautenberg]

Moin!

Das soll heißen, dass man gerade aktive Session-Schlüssel erraten kann.

Das bezweifle ich doch extrem! Zumindest was den Standardmechanismus für PHP angeht.

Das erstaunt mich nun wiederum!
Du weißt doch schließlich um die Fachausdrücke, oder?
Hier liegt "Erratbarkeit" vor.

Wenn die Aufgabe lautet "Wie lautet meine Zahl zwischen 1 und 50?", und als einzige Antwort kommt "falsch" oder "richtig", dann wird der Gefragte nicht drum herum kommen, alle Zahlen durchzuprobieren. Er kann das in beliebigen Mustern tun, aber er wird statistisch durchschnittlich 25 Versuche benötigen. Das nennt man dann "Brute Force".

Ein Ratespiel mit besseren Erfolgsaussichten wird daraus erst, wenn der Gefragte bessere Hinweise erhält, die ihn bei der Lösung der Aufgabe unterstützen. Beispielsweise durch "Meine Zahl ist kleiner/größer als dein Tipp."

Übersetzt auf Session-IDs bedeutet das: Der Gefragte müßte aufgrund von Meßergebnissen, die er selbst auf reguläre Weise machen kann, beispielsweise die ihm zugeteilten Session-IDs, Rückschlüsse auf andere existierende Session-IDs oder zumindest den in der letzten Zeit benutzten Wertebereich von Session-IDs machen können, um eben gerade nicht den Gesamtbereich von 2^128 Werten testen zu müssen (ein Versuch, der eben aufgrund der schieren Zahl an Möglichkeiten scheitern wird).

Das bedeutet im Klartext, dass beim zufälligen oder absichtlichen Treffen eines Schlüssels durch einen Unbefugten keine weitere Erkennung vorliegt.

Die Aussage stimmt natürlich: Wenn eine Session existiert, kriegt jeder Request, auch der von unbefugten Dritten, die Antwort mit dem derzeitigen Session-Status. Ist die Session gerade auf "eingeloggt", wäre auch der Dritte eingeloggt.

Das Problem ist dabei eben "nur", so eine Session-ID zu raten.

Dein vermeintlicher Lösungsansatz ändert daran aber nichts. Weiterhin muß man einfach nur die richtigen Zeichen in der URL platzieren, um Zugriff zu erhalten. Das mögen ein paar Zeichen mehr sein, was den Aufwand multipliziert (von "komplett unmöglich in einem Menschenleben" hin zu "komplett unmöglich in einem Menschenleben" - es ändert sich also nichts), wenn man nur ohne Hilfestellung alles durchprobieren muß, aber es nützt absolut nichts, wenn man auf irgendeine Weise eine gültige Kombination erfährt.

Das geht besonders gut, wenn Schlüssel aufgrund der Vergabeverfahrens mit Hilfe der Zeitkomponente erteilt werden. Dann vermindert sich nämlich der verfügbare Schlüsselvorrat auf eine sehr überschaubare Zahl.

Die zeitliche Komponente sorgt aber, vor allem dann, wenn man sehr genau mißt, für eine gute Zufallskomponente, insbesondere wenn man danach Hashverfahren wie MD5 nachschaltet und noch ein paar weitere Daten mit einfließen läßt. Damit ist aus der selbst erhaltenen Session-ID keinerlei Rückschluß auf die dabei eingeflossene Zeit und auch nicht auf mögliche Nachbarsessions möglich.

Zusätzliche "Wiederverwirrspiele" können einen eingeschränkten Schlüselvorrat tatsächlich fast auf ihren eigenen vollen Umfang (also den Schlüsselvorrat des Verwirrspiels) abbilden, aber nicht wieder auf den ursprünglichen spreizen. Außerdem ist das Verfahren bekannt und damit von dem ursprünglichen eigeschränkten Vorrat jederzeit replizierbar nachvollziehbar.

Bitte denke nochmals nach. Das ist einfachste Mengenlehre.

Hast du dir jemals den Code in PHP, der zur Erzeugung einer Session-ID benutzt wird, angesehen? Wenn ja, würdest du nicht behaupten, dass dessen Resultat "einfach angreifbar" wäre.

In dem MD5-Hash fließt ein:
1. Die "REMOTE_ADDR" des Requests, wenn vorhanden.
2. Die aktuellen Sekunden
3. Die aktuellen Mikrosekunden
4. Ein Zufallswert

Wenn gewünscht und konfiguriert, werden noch weitere Bytes aus einem Entropiefile hinzugefügt. Das Manual spricht von /dev/random oder /dev/urandom als typischer Quelle.

Das Ergebnis würde ich als ziemlich zufällig und nicht erratbar bezeichnen. Ebenso sind die MD5-Hashes dieser Zufallswerte dann nicht vorhersagbar. Und wem das nicht reicht, weil MD5 zuwenig mögliche Werte erzeugt, der kann seit PHP 5.0.0 auch SHA1 als Algorithmus wählen, und somit die Wertemenge von 2^128 auf 2^160 erhöhen, die man bearbeiten muß.

Ansonsten darfst du gerne einen Beispielangriff demonstrieren.
Das ist doch eher rhetorisch von Dir und damit äußerst unfair, da Du doch weißt, dass ich sowas niemals demonstrieren würde

Nein, das ist nicht rhetorisch, das ist ernst gemeint. Hast du schon einen entsprechenden Angriff praktisch konstruiert, oder hast du ihn dir bislang nur theoretisch ausgedacht?

Wenn du schon einen praktischen Angriff auf die Session-Generierung von PHP entwickelt hast, solltest du schleunigst die Entwickler von PHP kontakten und ihnen deine Erkenntnisse mitteilen. Erratbare Session-IDs sind in der Tat böse.

Allerdings bezweifle ich, dass du den praktischen Beweis deiner Theorie bringen kannst und Session-IDs gefährdeter sind, als durch Durchprobieren aller Möglichkeiten.

Daher sollte man für ein vernünftiges Session-Management immer ZWEI Schlüssel erteilen, die beide vorhanden sein müssen. Damit reduziert sich die Trefferwahrscheinlichkeit erheblich.

Jetzt kommt dieser Unsinn wieder.

Ich werde Dir anstelle eines Beispielangriffes lieber ein paasr etablierte Mathematiker liefern, die Dir meine Überlegungen bestätigen werden. So langsam reichts mir nämlich mit Dir ;-))
Also werde ich's jetzt langsam mal in Angriff nehmen und die Unis beballern...

Wie erwähnt: Ich bestreite nicht, dass "Size matters". Je mehr mögliche Werte die Session-ID hat, desto schwieriger wird man sie erraten können.

Ich bestreite nur, dass es irgendeinen Unterschied macht, eine längere Session-ID auf zwei oder mehr Teile aufzuteilen.

Oder willst du etwas anderes tun?

Du hast hier einige Mechanismen und die Logik dahinter scheinbar noch nicht verstanden.

Dann hast du es noch nicht gut genug erklärt.

Wir haben oft genug darüber diskutiert. Ein Sessionverfahren ohne Prüfverfahren ist (zumindest theoretisch) ein offenes Scheunentor.

Das bestreite ich. Ein Sessionverfahren beruht darauf, dass die Zahl aktiver Sessions deutlich kleiner ist als die Zahl möglicher Session-IDs, dass man die Session-IDs nicht vorhersagen kann (Zufallseinfluß), und dass ein Durchprobieren aller Werte so zeitaufwendig ist, dass es nicht in angemessener Zeit zum Erfolg führen kann.

Es mag zutreffen, dass ich auf meinem 486/DX266 in angemessener Zeit mit einem guten Assemblerprogramm keinen vernünftigen Schlüssel finden werde, also einen, der passt, aber wer hat denn heute noch solche Geräte im Einsatz?

Deine Argumentation ist fehlerhaft. Ich gehe nicht von irgendwelchen real existierenden Maschinen aus.

Denk dir einen Computer aus, den du für topaktuell hälst. Gib ihm eine Leistungsfähigkeit der Form "Geprüfte Session-IDs pro Sekunde". Multipliziere diesen Rechner mit einem Faktor "gleichzeitig eingesetzte Maschinen". Vergleiche mit 2^128 möglichen MD5-Werten. Errechne die Zeitdauer, um den gesamten Wertebereich einmal durchzuprüfen.

Vorlage:
Nehmen wir 10 GHz als Taktfrequenz und setzen 1 Takt = 1 Prüfung. Nehmen wir außerdem 6 Milliarden Rechner (jeder Mensch hat einen).

Diese Werte sind sicherlich etwas übertrieben für die heutige Zeit, aber nicht unrealistisch.

Damit ergibt sich: 10000000000 (1e+10) Prüfungen pro Maschine mit 6000000000 (6e+9) Maschinen ergibt 6e+19 Prüfungen pro Sekunde.

Dann dauert die Prüfung von 2^128 Werten gerundet 5,6713727820156410577229101238628e+18 Sekunden. Oder auch 1,7983805118010023648284215258317e+11 Jahre.

Wie schon mal erwähnt: Das Universum ist 13,5 Milliarden Jahre alt, oder auch 1,35e+10. Wir brauchen also schon mehr als 10 Universumsleben, um all die Werte durchzuprüfen - geschweige denn dass wir in die Nähe eines Menschenleben kommen.

Von der notwendigen Bandbreite, die man für diese Prüfung benötigen würde, mal ganz abgesehen.

Gewiß, mit steigender Rechnerleistung wird MD5 als Session-ID-Algorithmus nicht mehr so angenehm sein, aber SHA1 steht bei PHP schon in den Startlöchern (würde 7,9192547798915793095202439697572e+20 Jahre brauchen), die nächsten Generationen von SHA (256, 512 etc.) sind ebenfalls verfügbar.

Der Einzige Schutz, der hier besteht, ist die eingeschränkte Response-Time (also die relativ lange) gepaart mit der verfügbaren Bandbreite der Netze, die heute existieren.

Die Bandbreite ist ein zusätzlicher, limitierender Faktor, der praktische Angriffe unmöglicher macht. Aber wenn selbst ein theoretischer Angriff mit leicht unrealistischer Hardware und großen Zahlen an Parallelität nicht in einem Universumsleben zum Ziel kommt, dann halte ich ein Verfahren, dass diesem Angriff standhält, für ausreichend sicher.

Zumindest sollte man sich dann viel eher fragen, wie sicher denn eigentlich Usernamen und Passworte sind, und ob die einem Brute Force genauso gut standhalten würden.

- Sven Rautenberg

[Sven Rautenberg]

Moin!

Nanu? Schweigen im Walde? Sollte ich etwa unwidersprochen Recht haben?

- Sven Rautenberg

[kEv*]

Begrüßung ('Hallo'),

Mein Login sieht nun so.

Ein Formular welches nach absenden auf sich selber verweist.
Dort wird nach Datenbankabfrage entschieden ja du hast Zugriff oder nicht.
Wenn nicht per Header Location in eine error.php.
Wenn ja ok, dann eben die geschütze Seite.
Bei Logout auf die Startseite.

Nun habe ich für alles templates. Sprich in der Login.php wird die login.html included. Auch die zu schützenden Seite ist als template vorhanden. Da diese aber nur den Inhalt bezitzen also alles was zwischen den body tags im Normlafall steht, kann ich diese doch direkt in der adressleiste des Browser eingeben.

Reicht ein .htaccess Schutz für den template Order?
So habe ich es bisher umgesetzt:

deny from all

Ist das ausreichend? Niemand benötigt Zugriff ausser der Webapplikation selbst. Das funktioniert auch.

Ich hoffe ich habe mich verständlich ausgedrückt.

AufWiedersehen ('Vielen Dank'),
LG
--
kEv*
----