Jörg Reinholz: PHP/Anwendung und Praxis/Loginsystem

0 48

PHP/Anwendung und Praxis/Loginsystem

Jörg Reinholz
  • selfhtml-wiki
  1. 0

    Link zu: PHP/Anwendung und Praxis/Loginsystem

    Jörg Reinholz
  2. 0
    Matthias Apsel
    1. 0
      Jörg Reinholz
      1. 0
        Matthias Apsel
        1. 0
          Jörg Reinholz
    2. 0
      Sven Rautenberg
      1. 0
        Matthias Apsel
        1. 0
          Sven Rautenberg
          1. 0
            Matthias Apsel
          2. 0
            Matthias Apsel
            1. 0
              Sven Rautenberg
      2. 0
        Jörg Reinholz
        1. 0
          Matthias Apsel
          1. 0
            Jörg Reinholz
            1. 0
              Matthias Apsel
              1. 0
                dedlfix
                1. 0
                  Matthias Apsel
                  1. 0
                    dedlfix
                    1. 0
                      Matthias Apsel
  3. 0
    Sven Rautenberg
    1. 0
      Jörg Reinholz
      1. 0
        Sven Rautenberg
        1. 0
          Jörg Reinholz
          1. 0
            Auge
        2. 0
          Jörg Reinholz
  4. 0
    Matthias Apsel
  5. 0

    Fortschritte I

    Jörg Reinholz
    1. 0
      Jörg Reinholz
      1. 0
        Sven Rautenberg
        1. 0
          Jörg Reinholz
  6. 0
    Paul
    1. 0
      Jörg Reinholz
  7. 0
    1UnitedPower
    1. 0
      Jörg Reinholz
      1. 0
        Matthias Apsel
      2. 0
        1UnitedPower
    2. 0
      Jörg Reinholz
      1. 0
        1UnitedPower
        1. 0
          Jörg Reinholz
      2. 0
        Sven Rautenberg
    3. 0
      Sven Rautenberg
  8. 0

    Rückfrage zum Design der Verwaltung

    Jörg Reinholz
  9. 0
    Paul
    1. 0
      Jörg Reinholz
  10. 0

    Fortschritte II - (Diskussion: Schutz anderer Dateien)

    Jörg Reinholz
    1. 0
      Jörg Reinholz
  11. 0

    Fortschritte III - PHP/Anwendung und Praxis/Loginsystem

    Jörg Reinholz

Ich denke mal, die Sache rechtfertigt jetzt doch einen neuen Thread.

Ich habe den Artikel inzwischen noch von ein paar Textstellen befreit, die obsolet geworden sind und um ein paar solche ergänzt, die mir notwendig oder sinnvoll erschienen.

Matthias Apsel fragte zuletzt:

Vor allem müsste es _ein_ Artikel werden.

Ein Artikel. Das halte ich jetzt wegen des Stoffumfangs für etwas schwierig. Da könnte man nämlich ein nicht ganz kleines Buch darüber schreiben.

Ich würde das ergo gerne aufspalten:

Eigentliches Login und Hashing wie jetzt folgenden mit Erweiterungen

* Binden von IP-Adressen an die Session (als höchst simple Erweiterung der bisherigen login.php und auth.php)
* Gruppen, in Verbindung mit Benutzer-Verwaltung einbauen - mit Gruppen root (darf Benutzer verwalten) und user
* lastlogin und dazu
* Möglichkeiten des Zerstören einer Session (und somit sofortigen Sperren und Rauswerfen eines Benutzers)

mit folgenden Verweisen zu Artikeln

* Benutzerverwaltung und Speicherung
** Aufnahme weiterer Informationen
** Funktionen:
*** adduser,
*** deluser,
*** moduser, + inklusive Sperren
*** addgroup,
*** delgroup,
*** nodgroup
*** passwd,
*** Diskussion: eigener Namenspreset für Funktionen?
    Bsp. adduser -> SELFHTML_adduser?

** Speicherort, Module für das Lesen und Schreiben
** Modularisierung jeweils durch Funktionsbibliotheken!
*** wann welche (Leitungsfähigkeit, Editierbarkeit, ggf Umstieg...)
*** in CSV-Dateien
*** in Json-Dateien
*** Nur wenn ich mit Waffengewalt gezwungen werde: in XML-Dateien
*** in Datenbank (MySQL)

* Sicherung und Auslieferung von statischen Inhalten (Texte, Grafiken, Medien, Downloads) mit diesem Verfahren. (Thematisierung: htaccess, passthru(), mod_rewrite, mimetyp, header)

* ? (Vorschläge)

Jörg Reinholz

  1. Mist. Jetzt habe ich vergessen, den Artikel zu verlinken:

    Link zum Artikel PHP/Anwendung und Praxis/Loginsystem

    Jörg Reinholz

  2. Om nah hoo pez nyeetz, Jörg Reinholz!

    [Inhaltsverzeichnis]

    Da bin ich voll auf deiner Seite, falls du wikitechnisch Hilfe brauchst, sag Bescheid.

    Matthias Apsel fragte zuletzt:

    Vor allem müsste es _ein_ Artikel werden.

    Ein Artikel. Das halte ich jetzt wegen des Stoffumfangs für etwas schwierig. Da könnte man nämlich ein nicht ganz kleines Buch darüber schreiben.

    Gemeint war eher, dass Suit mit seinem Beitrag schon damals im Auge hatte, den anderen zu ersetzen. Siehe dazu http://forum.de.selfhtml.org/archiv/2013/10/t215374/#m1474851

    Matthias

    --
    Der Unterschied zwischen Java und JavaScript ist größer als der zwischen Arm und Armut.

    1. Gemeint war eher, dass Suit mit seinem Beitrag schon damals im Auge hatte, den anderen zu ersetzen. Siehe dazu http://forum.de.selfhtml.org/archiv/2013/10/t215374/#m1474851

      Naja. Das ist dann obsolet. Ich würde jetzt schrittweise vorgehen wollen und zunächst folgendes machen:

      [Schritt 1 - wenig Arbeit, kein neuer Artikel]
      * Modularisierung vorbereiten(!). Also eine Bibliothek vorsehen, die dann Funktionen mit identischen Namen, Parametern, und Returns enthält und abhängig von der in der Konfiguaration vorgesehnen Art der Datenspeicherung (text/csv, text/json oder Datenbank) eingebunden wird.
      * Konfigurationsdatei anlegen und nutzen.

      [Schritt 2 - viel Arbeit, weiterer Artikel]
      Dann käme die Benutzerverwaltung als eigener Artikel.

      * Benutzerverwaltung und Speicherung
      ** Aufnahme weiterer Informationen
      ** Funktionen:
      *** adduser,
      *** deluser,
      *** moduser, + inklusive Sperren
      *** addgroup,
      *** delgroup,
      *** modgroup
      *** passwd, userpasswd

      Der Artikel zur Benutzerverwaltung kann auch auch gleich erklärten, was es mit den Gruppenrechten auf sich hat...

      Ich würde das gerne auch separaten Downlaod anbieten bzw. sogar einen Installer schreiben (Ein PHP-Skript, welches die notwendigen Dateien holt und mit Angaben aus einem Affen-Formular die Konfiguration schreibt). Möglicherweise sollte ich auch gleich ein Update-Skript vorsehen.

      [Schritt 3 - viel Arbeit, kein weiterer Artikel]
      Die nächsten Schritte wären dann die übrigen Module/Bibliotheken nachzureichen, den Installer anzupassen und die Konfiguration zu erweitern. Alles so, dass die bisherigen Inhalte immer nur erweitert werden, d.h. am bisherigen Artikel und der Konfigurationsdatei nur Hinzufügungen notwendig sind, wenn man einen andere Weise des Speicherns hinzufügt.

      [Schritt 4 - eher "mittelviel" Arbeit, weiterer Artikel]
      Völlig unabhängig davon ist übrigens:
      * Sicherung und Auslieferung von statischen Inhalten (Texte, Grafiken, Medien, Downloads) mit diesem Verfahren. (Thematisierung: htaccess, passthru(), mod_rewrite, mimetyp, header)

      Jörg Reinholz

      1. Om nah hoo pez nyeetz, Jörg Reinholz!

        Ich würde mich sehr freuen, wenn du dich für SELFHTML engagieren würdest. Ich befürchte aber auch, dass es Gegenwind und Phasen von Desinteresse geben wird und würde mich deshalb noch mehr freuen, wenn das Projekt auch zuende gebracht werden würde.

        Matthias

        --
        Der Unterschied zwischen Java und JavaScript ist größer als der zwischen satt und Sattel.

        1. Ich würde mich sehr freuen, wenn du dich für SELFHTML engagieren würdest. Ich befürchte aber auch, dass es Gegenwind

          Also nee: In den Knast muss sich nach der neuesten Entscheidung des LG Köln(!) nun ganz gewiss nicht...

          und Phasen von Desinteresse geben wird und würde mich deshalb noch mehr freuen, wenn das Projekt auch zuende gebracht werden würde.

          Und der Sommer und somit der Herbst (und damit die Streßphase) sind erst noch recht lange hin...

          Inzwischen kann ich das in die Werbung investieren, was ich habe: Ein wenig Wissen, Arbeitskraft und Zeit.

          Es ist nicht ganz uneigennützig.

          Jörg Reinholz

    2. Moin!

      Da bin ich voll auf deiner Seite, falls du wikitechnisch Hilfe brauchst, sag Bescheid.

      Ich mag diese riesigen Code-Blocker nicht im Fließtext. Die zerreißen ihn vollkommen, vor allem, wenn sie gehäuft in einem Absatz vorkommen. Monospaced-Schrift: Klar. Farbig hinterlegt: Auch. Aber nicht fett und riesig. :)

      - Sven Rautenberg

      1. Om nah hoo pez nyeetz, Sven Rautenberg!

        Ich mag diese riesigen Code-Blocker nicht im Fließtext. Die zerreißen ihn vollkommen, vor allem, wenn sie gehäuft in einem Absatz vorkommen. Monospaced-Schrift: Klar. Farbig hinterlegt: Auch. Aber nicht fett und riesig. :)

        font-size: 1.1em?

        Matthias

        --
        Der Unterschied zwischen Java und JavaScript ist größer als der zwischen Scheuer und Scheuerleiste.

        1. Moin!

          Om nah hoo pez nyeetz, Sven Rautenberg!

          Ich mag diese riesigen Code-Blocker nicht im Fließtext. Die zerreißen ihn vollkommen, vor allem, wenn sie gehäuft in einem Absatz vorkommen. Monospaced-Schrift: Klar. Farbig hinterlegt: Auch. Aber nicht fett und riesig. :)

          font-size: 1.1em?

          Keine Ahnung, warum das größer ist, als der Fließtext, und fetter dargestellt erscheint.

          So schaut's aus bei mir.

          - Sven Rautenberg

          1. Om nah hoo pez nyeetz, Sven Rautenberg!

            Keine Ahnung, warum das größer ist, als der Fließtext, und fetter dargestellt erscheint.

            So schaut's aus bei mir.

            Ja. So soll es aussehen. Im Moment ist für die Code-Elemente eine Schriftgröße von 1.25em festgelegt. Nichts, was sich nicht ändern ließe.

            Matthias

            --
            Der Unterschied zwischen Java und JavaScript ist größer als der zwischen Akt und Aktenordner.

          2. Om nah hoo pez nyeetz, Sven Rautenberg!

            Ich mag diese riesigen Code-Blocker nicht im Fließtext. Die zerreißen ihn vollkommen, vor allem, wenn sie gehäuft in einem Absatz vorkommen. Monospaced-Schrift: Klar. Farbig hinterlegt: Auch. Aber nicht fett und riesig. :)

            Bitte einmal den Browsercache löschen.

            Matthias

            --
            Der Unterschied zwischen Java und JavaScript ist größer als der zwischen Ziege und Ziegelstein.

            1. Moin!

              Om nah hoo pez nyeetz, Sven Rautenberg!

              Ich mag diese riesigen Code-Blocker nicht im Fließtext. Die zerreißen ihn vollkommen, vor allem, wenn sie gehäuft in einem Absatz vorkommen. Monospaced-Schrift: Klar. Farbig hinterlegt: Auch. Aber nicht fett und riesig. :)

              Bitte einmal den Browsercache löschen.

              Aha, zumindest nicht mehr FETT. :) Schöner.

              - Sven Rautenberg

      2. Ich mag diese riesigen Code-Blocker nicht im Fließtext. Die zerreißen ihn vollkommen, vor allem, wenn sie gehäuft in einem Absatz vorkommen. Monospaced-Schrift: Klar. Farbig hinterlegt: Auch. Aber nicht fett und riesig. :)

        Ich habe das CSS durchsucht. <pre> geht nicht. <kbd> könnte man missbrauchen...

        Jörg Reinholz

        1. Om nah hoo pez nyeetz, Jörg Reinholz!

          Ich habe das CSS durchsucht. <pre> geht nicht. <kbd> könnte man missbrauchen...

          Man kann das CSS ändern.

          Matthias

          --
          Der Unterschied zwischen Java und JavaScript ist größer als der zwischen Brom und Bromelie.

          1. Om nah hoo pez nyeetz, Jörg Reinholz!

            Ich habe das CSS durchsucht. <pre> geht nicht. <kbd> könnte man missbrauchen...

            Man kann das CSS ändern.

            Ja nee. Schon klar. Das kann aber eine Menge "Seiteneffekte" haben.

            Jörg Reinholz

            1. Om nah hoo pez nyeetz, Jörg Reinholz!

              Man kann das CSS ändern.
              Ja nee. Schon klar. Das kann aber eine Menge "Seiteneffekte" haben.

              In dem Fall gibt es wohl keine. Du solltest aber auch nicht kbd-Elemente missbrauchen.

              Matthias

              --
              Der Unterschied zwischen Java und JavaScript ist größer als der zwischen Gast und Gastritis.

              1. Tach!

                Man kann das CSS ändern.
                Ja nee. Schon klar. Das kann aber eine Menge "Seiteneffekte" haben.
                In dem Fall gibt es wohl keine.

                Na, dann machst du was falsch, wenn das CSS keine Effekte auf die Seite hat.

                dedlfix.

                1. Om nah hoo pez nyeetz, dedlfix!

                  Man kann das CSS ändern.
                  Ja nee. Schon klar. Das kann aber eine Menge "Seiteneffekte" haben.
                  In dem Fall gibt es wohl keine.
                  Na, dann machst du was falsch, wenn das CSS keine Effekte auf die Seite hat.

                  Ne, es gibt nur die beabsichtigten Effekte, keine „Seiteneffekte“. ;-)

                  Matthias

                  --
                  Der Unterschied zwischen Java und JavaScript ist größer als der zwischen Hang und Hangar.

                  1. Tach!

                    Man kann das CSS ändern.
                    Ja nee. Schon klar. Das kann aber eine Menge "Seiteneffekte" haben.
                    In dem Fall gibt es wohl keine.
                    Na, dann machst du was falsch, wenn das CSS keine Effekte auf die Seite hat.
                    Ne, es gibt nur die beabsichtigten Effekte, keine „Seiteneffekte“. ;-)

                    Also doch Seiteneffekte, die aber ohne Nebenwirkungen.

                    dedlfix.

                    1. Om nah hoo pez nyeetz, dedlfix!

                      Man kann das CSS ändern.
                      Ja nee. Schon klar. Das kann aber eine Menge "Seiteneffekte" haben.
                      In dem Fall gibt es wohl keine.
                      Na, dann machst du was falsch, wenn das CSS keine Effekte auf die Seite hat.
                      Ne, es gibt nur die beabsichtigten Effekte, keine „Seiteneffekte“. ;-)

                      Also doch Seiteneffekte, die aber ohne Nebenwirkungen.

                      jetzt habs ichs dann auch kapiert ;-)

                      Matthias

                      --
                      Der Unterschied zwischen Java und JavaScript ist größer als der zwischen Lachs und Lachsack.

  3. Moin!

    Ich denke mal, die Sache rechtfertigt jetzt doch einen neuen Thread.

    Ich habe den Artikel inzwischen noch von ein paar Textstellen befreit, die obsolet geworden sind und um ein paar solche ergänzt, die mir notwendig oder sinnvoll erschienen.

    Matthias Apsel fragte zuletzt:

    Vor allem müsste es _ein_ Artikel werden.

    Ein Artikel. Das halte ich jetzt wegen des Stoffumfangs für etwas schwierig. Da könnte man nämlich ein nicht ganz kleines Buch darüber schreiben.

    Richtig, das Thema ist notwendigerweise komplex. Deswegen würde ich alles weglassen, was auf die notwendige Komplexität noch unnötige draufsetzt.

    Was ist für ein aktuelles Login-System zwingend notwendig? Ein User muss sich neu anmelden können mit Username und Passwort, und er muss sich einloggen und dabei das Passwort geprüft kriegen. Gerade im Hinblick auf die nicht ganz offensichtliche Vorgehensweise mit irreversiblen Hashes sollten die relevanten Schritte gezeigt werden: password_hash(), password_verify(), password_needs_rehash(). Und natürlich das Prüfen des Passworts auf Komplexität

    Das Speichermedium für die User steht nicht im Mittelpunkt. Die auszuliefernden Inhalte auch nicht. Die Fallback-Lösung für PHP-Versionen kleiner 5.5 ebenfalls nicht (das ist ein Einzeiler mit "Lad die Kompatibilitätslib runter und rufe am Anfang einmal require_once(libdatei.php) auf."). Das sind alles Themen für andere Artikel drumherum.

    - Sven Rautenberg

    1. Tach!

      Richtig, das Thema ist notwendigerweise komplex. Deswegen würde ich alles weglassen, was auf die notwendige Komplexität noch unnötige draufsetzt.

      In der Hinsicht sollte die Frage in den Raum geworfen werden, wie weit wir gehen wollen.
      * Komplette Lösung?
      * Nur ein Anriss?

      Was ist für ein aktuelles Login-System zwingend notwendig? Ein User muss sich neu anmelden können mit Username und Passwort, und er muss sich einloggen und dabei das Passwort geprüft kriegen.

      Das ist der Stand der Dinge.

      password_needs_rehash().

      Oha! Das schafft einen völlig neuen Punkt und einen völlig neue Diskussionsbedarf:

      * Das Passwort im Hintergrund schweigend neu hashen
      * und/oder (auch zu diskutieren!)
      * den Benutzer hinsichtlich des schwach gehashten Passworts warnen und ein neues eingeben lassen. Bitte auch an die Verwirrung der Benutzer und die "Kommerzköppe" denken.

      Und natürlich das Prüfen des Passworts auf Komplexität

      Woll. Das dann gleich mit.

      Das Speichermedium für die User steht nicht im Mittelpunkt.

      Hab ich gelesen. Mal sehen, was die anderen dazu sagen.

      Die auszuliefernden Inhalte auch nicht.

      Naja. Ohne den Schutz auch auf andere Dateien (Pics, Medien, Downloads) auszudehnen macht das nicht so viel Sinn - oder? Meinst Du das überhaupt?

      Die Fallback-Lösung für PHP-Versionen kleiner 5.5 ebenfalls nicht (das ist ein Einzeiler mit "Lad die Kompatibilitätslib runter und rufe am Anfang einmal require_once(libdatei.php) auf."). Das sind alles Themen für andere Artikel drumherum.

      Hier bin ich ziemlich fest anderer Meinung und habe dafür nach meiner Meinung auch gute Gründe: Wir schreiben den Februar anno 2015. Viele haben in dieser Realität bei ihrem Hoster noch kein PHP 5.5 oder jünger. Ich halte es für keine gute Idee Skripte anzubieten, die bei denen (noch) nicht laufen. Das würde einen Ansehensverlust und eine Menge Rückfragen - nicht nur hier im Forum - nach sich ziehen.

      Jörg Reinholz

      1. Moin!

        Tach!

        Richtig, das Thema ist notwendigerweise komplex. Deswegen würde ich alles weglassen, was auf die notwendige Komplexität noch unnötige draufsetzt.

        In der Hinsicht sollte die Frage in den Raum geworfen werden, wie weit wir gehen wollen.
        * Komplette Lösung?
        * Nur ein Anriss?

        Du kannst keine komplette Lösung in einem Artikel präsentieren, sonst hast du in nahezu jedem Teilaspekt, der für das Thema wichtig ist, zwei bis drei Aspekte, die davon ablenken.

        Wenn du eine komplette Lösung anbieten willst, biete sie zum Download an. Viel Spaß bei der Pflege die nächsten Jahre (was leider, auch bei Code in Artikeln, ein grundsätzliches Problem ist, zu dem ich keine Lösung habe).

        Was ist für ein aktuelles Login-System zwingend notwendig? Ein User muss sich neu anmelden können mit Username und Passwort, und er muss sich einloggen und dabei das Passwort geprüft kriegen.

        Das ist der Stand der Dinge.

        password_needs_rehash().
        Oha! Das schafft einen völlig neuen Punkt und einen völlig neue Diskussionsbedarf:
        * Das Passwort im Hintergrund schweigend neu hashen
        * und/oder (auch zu diskutieren!)
        * den Benutzer hinsichtlich des schwach gehashten Passworts warnen und ein neues eingeben lassen. Bitte auch an die Verwirrung der Benutzer und die "Kommerzköppe" denken.

        Und natürlich das Prüfen des Passworts auf Komplexität
        Woll. Das dann gleich mit.

        Das Speichermedium für die User steht nicht im Mittelpunkt.
        Hab ich gelesen. Mal sehen, was die anderen dazu sagen.

        Die auszuliefernden Inhalte auch nicht.
        Naja. Ohne den Schutz auch auf andere Dateien (Pics, Medien, Downloads) auszudehnen macht das nicht so viel Sinn - oder? Meinst Du das überhaupt?

        Eine "komplette Lösung" müsste ja sinnvollerweise irgendwelchen Content anbieten, den nicht jeder sehen darf. Würdest du noch Usergruppen ins Thema hineinziehen, brauchst du sogar zwei unterschiedliche Inhalte. Und musst außerdem Dinge wie ACL oder RBAC erklären und implementieren (beides bietet allein schon Stoff für jeweils mehr als zwei Artikel, IMHO).

        Die Fallback-Lösung für PHP-Versionen kleiner 5.5 ebenfalls nicht (das ist ein Einzeiler mit "Lad die Kompatibilitätslib runter und rufe am Anfang einmal require_once(libdatei.php) auf."). Das sind alles Themen für andere Artikel drumherum.

        Hier bin ich ziemlich fest anderer Meinung und habe dafür nach meiner Meinung auch gute Gründe: Wir schreiben den Februar anno 2015. Viele haben in dieser Realität bei ihrem Hoster noch kein PHP 5.5 oder jünger. Ich halte es für keine gute Idee Skripte anzubieten, die bei denen (noch) nicht laufen. Das würde einen Ansehensverlust und eine Menge Rückfragen - nicht nur hier im Forum - nach sich ziehen.

        Die Lib läuft bis runter zu PHP 5.3.7. Sie läuft deswegen nicht mit älteren Versionen, weil deren Crypt-Funktion kaputt ist!

        Du willst auf kaputter Softwaregrundlage keine Reimplementierung relevanter Hashing-Algorithmen bauen. Es ist unmöglich, bcrypt nativ in PHP zu implementieren - der Laufzeitunterschied zur C-Variante wäre vermutlich recht hoch, was dazu zwingen würde, einen deutlich kleineren Kostenfaktor zu wählen - das gefährdet aber die Sicherheit. Dasselbe gilt für alternative Hash-Algorithmen.

        Ich finde es sehr bedauerlich, dass man auf eine Plattform, deren offizieller Support bereits vor über einem halben Jahr endete (18. August 2014), immer noch mit Primärfokus Rücksicht nehmen soll. Wie sollen Entwickler lernen, mit den Möglichkeiten der neuen Versionen umzugehen und sie folgerichtig bei ihren Hostern auch einzufordern, wenn es niemand vormacht?

        Abwärtskompatibilität ist kein Primärziel des Artikels, sondern eine Randerscheinung.

        - Sven Rautenberg

        1. Du willst auf kaputter Softwaregrundlage keine Reimplementierung relevanter Hashing-Algorithmen bauen. Es ist unmöglich, bcrypt nativ in PHP zu implementieren - der Laufzeitunterschied zur C-Variante wäre vermutlich recht hoch, was dazu zwingen würde, einen deutlich kleineren Kostenfaktor zu wählen - das gefährdet aber die Sicherheit. Dasselbe gilt für alternative Hash-Algorithmen.

          So ist es.

          Allerdings könnte man (wenn man wöllte), um das Problem auzunullen, für PHP-Versionen unterhalb 5.3.7 sogar eine recht einfach erscheinende Lösung anbieten:

          "In versions of PHP older than 5.3.7, $2a$ inadvertently resulted in system-specific behavior for passwords with non-ASCII characters in them."

          (Einfach keine Nicht-ASCII-Zeichen zulassen).

          Ich vermute aber, dass ich dazu auch wenig Lust hätte. Kann man vielleicht, wenn es sich irgendwie anbietet, vielleicht irgendwo in den Beschreibungstext aufnehmen, denn so relevant dürften PHP-Versionen unterhalb von 5.3.7 auch nicht sein. Äh. Hoffe ich.

          Merkzettel:
          In Setup-Skript aufnehmen, Warnung ausgeben.

          Jörg Reinholz

          1. Hallo

            Allerdings könnte man (wenn man wöllte), um das Problem auzunullen, für PHP-Versionen unterhalb 5.3.7 sogar eine recht einfach erscheinende Lösung anbieten:

            "In versions of PHP older than 5.3.7, $2a$ inadvertently resulted in system-specific behavior for passwords with non-ASCII characters in them."

            (Einfach keine Nicht-ASCII-Zeichen zulassen).

            Man könnte aber auch beschreiben, warum man solche Versionen nicht benutzen will. Die sich daraus ergebende Empfehlung ist dann, dem Hoster auf die Eier zu gehen oder ihn zu wechseln.

            Das ist meiner Meinung die wesentlich ehrlichere und einzig richtige Antwort. Die schlechte Implementierung von Hashing-Algorithmen, der hier Teil des Themas ist, ist ja nicht der einzige Grund für ein zwingend zu empfehlendes Upgrade auf den aktuellen Stand der Technik.

            Tschö, Auge

            --
            Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war.
            Terry Pratchett, "Wachen! Wachen!"
            ie:{ fl:| br:> va:) ls:[ fo:) rl:( ss:| de:> js:| zu:}
        2. Eine "komplette Lösung" müsste ja sinnvollerweise irgendwelchen Content anbieten, den nicht jeder sehen darf. Würdest du noch Usergruppen ins Thema hineinziehen, brauchst du sogar zwei unterschiedliche Inhalte. Und musst außerdem Dinge wie ACL oder RBAC erklären und implementieren (beides bietet allein schon Stoff für jeweils mehr als zwei Artikel, IMHO).

          Das geht wirklich zu weit! Ich würde dabei halt machen wollen, dass Mitglieder der Gruppe "root" Benutzer, Gruppen verwalten dürfen (weil das sowieso noch gebraucht wird) und die aufrufende Zeile bzw. dann die auth.php so erweitern, dass diese die Mitgliedschaft in der Gruppe root fordern.

          Jörg Reinholz

  4. Om nah hoo pez nyeetz, Jörg Reinholz!

    * ? (Vorschläge)

    Es wäre schön, wenn du dich im Wiki anmelden würdest, dann würden alle deine Beiträge dir zugeordnet und nicht der gerade aktuellen IP.

    Matthias

    --
    Der Unterschied zwischen Java und JavaScript ist größer als der zwischen Spitz und Spitzer.

  5. Test:
    http://www.fastix.org/test/selfhtml_login/

    Es gibt:

    1. Test:
      http://www.fastix.org/test/selfhtml_login/

      Es gibt:

      • Login an IP-Adresse gebunden
      • IDLE-Time (Zeit ohne Aktivität) begrenzt
      1. Moin!

        Test:
        http://www.fastix.org/test/selfhtml_login/

        Es gibt:

        • Login an IP-Adresse gebunden

        IPv4? Wie verträgt sich das mit NAT und Zwangsreconnect?

        IPv6? Und welchen Sinn macht das dort, wenn Privacy Extensions eingeschaltet sind?

        • IDLE-Time (Zeit ohne Aktivität) begrenzt

        Sinnvoll.

        - Sven Rautenberg

        1. IPv4? Wie verträgt sich das mit NAT und Zwangsreconnect?

          Mit NAT sehr gut. Bietet dann halt nur gegen den Klau der Session aus dem selben Netz keinen Schutz. Bein Zwangereconnect fliegt der Benutzer raus, wenn es eine neue IP gibt.

          Das senden des SESSION-COOKIES auf HTTPS-Verbindungen zu begrenzen wäre eine weitere Möglichkeit. Das scheint mir sinnvoll, wenn die Login-Seite über HTTPS aufgerufen wird.
          [x] als schnell umsetzbare Idee gebucht.

          IPv6? Und welchen Sinn macht das dort, wenn Privacy Extensions eingeschaltet sind?

          Das Binden an die IP-Adresse ist abschaltbar.

          Jörg Reinholz

  6. Hallo Herr Reinholz,

    da habe ich ja etwas los getreten. Wenn auch mal was Gutes. : )
    Ich und wahrscheinlich viele andere nach mir danken das es solche User und DAS Forum hier gibt. Auf das dies noch lange so bleiben wird.

    Danke .. .. ...

    MfG
    $paul = 'Paul';

    echo $paul . 'wünscht einen schönen Abend';

    1. Hallo Herr Reinholz,

      da habe ich ja etwas los getreten.

      Naja. Nicht ganz. Die Sache stand irgendwie schon länger auf so manchem Zettel auf so manchem Klemmbrett.

      Jörg Reinholz

  7. Hakuna matata!

    * ? (Vorschläge)

    Ich hab mir den Artikel gerade das erste mal durchgelesen und bin einigermaßen erschüttert. Vorallem weil der Quelltext selbst Sicherheitslücken aufweist:

      session_regenerate_id(); // erneuert die Session-ID,  
      #                         // erschwert Session-Hijacking
    

    Inwiefern sollte es gegen Session-Hijacking nützlich sein, bei jedem Request eine weitere gültige Session zu erzeugen? Das ist geradezu eine Einladung für Angriffe dieser Art.

    Über den Rest des Quelltextes lässt sich wegen der vielen exit-,die- und return-Statements erst gar nicht rational argumentieren. Der Kontrollfluss ist leider eine absolute Katastrophe.

    Auch die Fehlerbehandlung ist mehr schlecht als recht:

    if (! function_exists('crypt') ) {  // es gibt auch noch ältere ...  
       die ("Sorry: Aber Sie sollten Ihr PHP wirklich updaten!");  
    }
    

    Wieso wird hier kein PHP-Fehler produziert, sondern eine Ausgabe an den Endnutzer vorgenommen? Wieso befinden sich diese Zeilen überhaupt irgendwo mitten im Loginskript und nicht ganz am Anfang oder ausgelagert in einem Unterprogramm, das nur die Systemabhängigkeiten prüft?

    Ich sehe da noch deutlichen Handlungsbedarf und ich finde, solange der Artikel in diesem schlechten Zustand verweilt, sollten wir ihn mit einer dicken, fetten Warnung versehen.

    --
    “All right, then, I'll go to hell.” – Huck Finn
    1. Hakuna matata!

      * ? (Vorschläge)

      Ich hab mir den Artikel gerade das erste mal durchgelesen und bin einigermaßen erschüttert. Vorallem weil der Quelltext selbst Sicherheitslücken aufweist:

      session_regenerate_id(); // erneuert die Session-ID,

      #                         // erschwert Session-Hijacking

        
      Das habe ich von der Vorversion übernommen. Ich habe den Artikel ja umgeschrieben.  
        
      
      > Über den Rest des Quelltextes lässt sich wegen der vielen exit-,die- und return-Statements erst gar nicht rational argumentieren. Der Kontrollfluss ist leider eine absolute Katastrophe.  
      >   
      > Auch die Fehlerbehandlung ist mehr schlecht als recht:  
      >   
      > ~~~php
      
      if (! function_exists('crypt') ) {  // es gibt auch noch ältere ...  
      
      >    die ("Sorry: Aber Sie sollten Ihr PHP wirklich updaten!");  
      > }
      
      

      Ich sehe da noch deutlichen Handlungsbedarf

      Ich habe nie behauptet, dass der Artikel fertig ist. Ich sprach von Fortschritten.

      und ich finde, solange der Artikel in diesem schlechten Zustand verweilt, sollten wir ihn mit einer dicken, fetten Warnung versehen.

      He, halt mal. Du willst warnen? Das ist ein wenig so als würdest Du wegen eines Steinchens auf dem Weg die Wanderer in den Sumpf schicken:

      Wenn schon warnen, dann doch bitte erst mal den hier. Da stehen Passwörter a) im Programm und das dann noch im Klartetxt. Und der hier erfüllt die von Dir genannten Kritikpunkte hinsichtlich des Kontrollflusses auch.

      Jörg Reinholz

      1. Om nah hoo pez nyeetz, Jörg Reinholz!

        Wenn schon warnen, dann doch bitte erst mal den hier. Da stehen Passwörter a) im Programm und das dann noch im Klartetxt.

        Dieser wird demnächst auf http://wiki.selfhtml.org/wiki/PHP/Anwendung_und_Praxis/Loginsystem weiterleiten.

        Und der hier erfüllt die von Dir genannten Kritikpunkte hinsichtlich des Kontrollflusses auch.

        Und hier verweise ich ebenfalls auf http://wiki.selfhtml.org/wiki/PHP/Anwendung_und_Praxis/Loginsystem

        Matthias

        --
        Der Unterschied zwischen Java und JavaScript ist größer als der zwischen Manga und Mangan.

      2. Hakuna matata!

        Ich sehe da noch deutlichen Handlungsbedarf

        Ich habe nie behauptet, dass der Artikel fertig ist. Ich sprach von Fortschritten.

        Vollkommen okay, ich wollte auch nie dich persönlich kritisieren. Im Gegenteil, ich bin froh dass du dich darum kümmerst, ich weiß nicht in welcher Verfassung der Artikel vorher war, aber ich kann mir vorstellen, dass du die ein oder andere Falte schon ausgebügelt hast. Ich kann derzeit nicht die Zeit und Motivation aufbringen, mich aktiv im Wiki zu beteiligen, ich bringe stattdessen meine 2 Cent hier im Forum ein und hoffe, dass ich damit bei irgendeinem Freiwilligen auf offene Ohren stoße.

        und ich finde, solange der Artikel in diesem schlechten Zustand verweilt, sollten wir ihn mit einer dicken, fetten Warnung versehen.

        He, halt mal. Du willst warnen? Das ist ein wenig so als würdest Du wegen eines Steinchens auf dem Weg die Wanderer in den Sumpf schicken:

        Ich halte es ehrlichgesagt für selbstverständlich, dass wir unsere Leserschaft vor unfertigen Artikeln mit bekannt gewordenen Defiziten warnen. Ich hätte nicht gedacht, dass wir darüber ernsthaft diskutieren müssen. Was die anderen beiden Artikel angeht, die habe ich nicht gelesen, aber falls diese in einem ähnlichen Zustand sein sollten, dann sollten wir auch davor warnen.

        --
        “All right, then, I'll go to hell.” – Huck Finn
    2. session_regenerate_id(); // erneuert die Session-ID,

      #                         // erschwert Session-Hijacking

        
      
      > Inwiefern sollte es gegen Session-Hijacking nützlich sein, bei jedem Request eine weitere gültige Session zu erzeugen? Das ist geradezu eine Einladung für Angriffe dieser Art.  
        
      Danke für den konstruktiven Hinweis. Ich habe der Funktion session\_regenerate\_id() den Parameter true hinzugefügt (damit wird seit PHP 5.1. die alte Session gekillt) und mir auf den Zettel geschrieben, dass dieses, so die Diskussion hier nichts besseres ergibt,  an die Nicht-Nutzung von https gebunden wird.  
        
      Es ist IMHO durchaus nicht ganz sinnlos. Zumindest wenn der Angreifer versucht, die Session-ID durch Mitschneiden des Netzverkehrs (tcpdump, wireshark, ...) zu "klauen" und dann manuell(!) versucht, diese zu übernehmen, ist es ziemlich wahrscheinlich, dass diese Session-ID auf Grund einer Aktion des berechtigten Benutzers inzwischen nicht mehr gültig ist. Es gibt auch einen Sicherheitsgewinn, weil der Angreifer den Netzverkehr zum Zeitpunkt der Anmeldung mitschneiden muss um an die Login-Daten zu kommen. Irgendwer mag mit Statistiken fummeln und was zu Prozentzahlen sagen.  
        
      Bei der Verwendung von https muss man sich hingegen fragen, ob die dadurch erhöhte Serverlast im Hinblick auf den Rest des noch zu erwartenden Sicherheitsgewinns vertretbar ist. Deshalb wäre ich beim Stand der bisherigen Diskussion für:  
        
      https: keine Umbennnung  
      http: Umbenennen mit session\_regenerate\_id(true)  
        
        
      Jörg Reinholz  
        
        
        
      
      
      1. Hakuna matata!

        Es ist IMHO durchaus nicht ganz sinnlos. Zumindest wenn der Angreifer versucht, die Session-ID durch Mitschneiden des Netzverkehrs (tcpdump, wireshark, ...) zu "klauen" und dann manuell(!) versucht, diese zu übernehmen, ist es ziemlich wahrscheinlich, dass diese Session-ID auf Grund einer Aktion des berechtigten Benutzers inzwischen nicht mehr gültig ist.

        Wenn ein Angreifer den Verkehr wirklich mitschneidet, dann kann man davon ausgehen, dass dieser auch die Server-Antwort zu sehen bekommt, in der dann auch schon die neue Session-ID übermittelt wird. Der Angreifer könnte daraufhin sofort eine neue Anfrage an den Server senden und damit den regulären Nutzer aus seiner eigenen Sitzung aussperren.

        Siehe dazu auch: http://forum.de.selfhtml.org/archiv/2014/3/t216939/#m1489011

        Es gibt auch einen Sicherheitsgewinn, weil der Angreifer den Netzverkehr zum Zeitpunkt der Anmeldung mitschneiden muss um an die Login-Daten zu kommen. Irgendwer mag mit Statistiken fummeln und was zu Prozentzahlen sagen.

        Das hat man doch schon dadruch erreicht, dass die Credentials nur einmal fällig werden und danach auf Session-ID zurückgegriffen wird, um den Nutzer erneut zu identifizieren. Was trägt es da an zusätzlicher Sicherheit bei, die Session-ID ständig zu erneuern?

        Bei der Verwendung von https muss man sich hingegen fragen, ob die dadurch erhöhte Serverlast im Hinblick auf den Rest des noch zu erwartenden Sicherheitsgewinns vertretbar ist.

        Also mir sind keine Perfomance-Bottlenecks von HTTPS bekannt und dem Tradeoff Sicherheit für Performance kann ich auch im Allgemeinen nicht viel abgewinnen.

        Wenn man session_regenerate_id() zudem bei jeder Anfrage ausführt, dann können keine Anfragen des selben Nutzers mehr parallel bearbeitet werden. Denn wenn die zweite Anfrage eintrifft, ist die Session-ID von der ersten Anfrage bereits für ungültig erklärt worden.

        Auch dazu hatte molily schon mal ein paar Worte verloren:
        http://forum.de.selfhtml.org/archiv/2014/4/t217253/#m1491970

        --
        “All right, then, I'll go to hell.” – Huck Finn
        1. Es gibt auch einen Sicherheitsgewinn, weil der Angreifer den Netzverkehr zum Zeitpunkt der Anmeldung mitschneiden muss um an die Login-Daten zu kommen. Irgendwer mag mit Statistiken fummeln und was zu Prozentzahlen sagen.

          Das hat man doch schon dadruch erreicht, dass die Credentials nur einmal fällig werden und danach auf Session-ID zurückgegriffen wird, um den Nutzer erneut zu identifizieren. Was trägt es da an zusätzlicher Sicherheit bei, die Session-ID ständig zu erneuern?

          Man kann mit tcdump bei unverschlüsselten Verbindungen die SESSION-ID mitlesen und die SESSION kapern. Man kann ja das COOKIE mitlesen. Das Problem ist also nicht darauf begrenzt, dass die SESSION über einen Link weiter gegeben wird. Das (ab auf den Zettel damit!) sollte durch ini_set('session.use_only_cookies', 1)  verhindert werden. Könnte ja geändert sein.

          Bei der Verwendung von https muss man sich hingegen fragen, ob die dadurch erhöhte Serverlast im Hinblick auf den Rest des noch zu erwartenden Sicherheitsgewinns vertretbar ist.

          Also mir sind keine Perfomance-Bottlenecks von HTTPS bekannt und dem Tradeoff Sicherheit für Performance kann ich auch im Allgemeinen nicht viel abgewinnen.

          Naja, da hast Du mich falsch verstanden. Ich meinte bei der Verwendung von HTTPS auf die Neuvergabe der SESSION-ID zu verzichten.

          Wenn man session_regenerate_id() zudem bei jeder Anfrage ausführt, dann können keine Anfragen des selben Nutzers mehr parallel bearbeitet werden.

          Das klingt tatsächlich so als könnte das durchaus ein Problem werden. Ich teste das mal aus und denke über Szenarios nach und darüber, wie man das verhindern kann.

          Übrigens. Das "böse" <code>die("Sie sollten")</code>  ... kann theorethisch kein NUTZER der Webseite je zu Gesicht bekommen. Irgendwie müssten die Hashes der Passwörter ja auch erzeugt werden. Und da werde ich unterhalb von crypt() nichts programmieren. Es sei denn natürlich jemand kommt auf die Idee, die Passwörter "manuell" zu hashen  (z.B. auf einem anderen System mit apache 2.4 mit htpasswd -Bbn oder so...) oder aus /etc/shadow zu kopieren...

          Wenn wir gerade davon reden: Eine Bindung an PAM wäre übrigens etwas, was ich mir für später aufhebe... falls mich aber jemand dafür angemessen bezahlen will kann ich es vorziehen. Falls die NSA oder GCHQ die Besteller und Anwender sind verzichte ich da auch gerne auf die Erzwingung von HTTPS.

          Jörg Reinholz

      2. Moin!

        session_regenerate_id(); // erneuert die Session-ID,

        #                         // erschwert Session-Hijacking

        
        >   
        > > Inwiefern sollte es gegen Session-Hijacking nützlich sein, bei jedem Request eine weitere gültige Session zu erzeugen? Das ist geradezu eine Einladung für Angriffe dieser Art.  
        >   
        > Danke für den konstruktiven Hinweis. Ich habe der Funktion session\_regenerate\_id() den Parameter true hinzugefügt (damit wird seit PHP 5.1. die alte Session gekillt) und mir auf den Zettel geschrieben, dass dieses, so die Diskussion hier nichts besseres ergibt,  an die Nicht-Nutzung von https gebunden wird.  
          
        Session-Fixation geht auch mit HTTPS. Es ist eine gute Idee, bei HTTPS ebenso neue Session-IDs zu erzeugen, wenn der User seine Rechte in seiner Session erhöht, d.h. vom unangemeldeten User zum angemeldeten User wird, und von dort evtl. nochmal zum Admin. Jede Erhöhung der Rechte sollte eine neue Session-ID ergeben.  
          
        
        > Es ist IMHO durchaus nicht ganz sinnlos. Zumindest wenn der Angreifer versucht, die Session-ID durch Mitschneiden des Netzverkehrs (tcpdump, wireshark, ...) zu "klauen" und dann manuell(!) versucht, diese zu übernehmen, ist es ziemlich wahrscheinlich, dass diese Session-ID auf Grund einer Aktion des berechtigten Benutzers inzwischen nicht mehr gültig ist. Es gibt auch einen Sicherheitsgewinn, weil der Angreifer den Netzverkehr zum Zeitpunkt der Anmeldung mitschneiden muss um an die Login-Daten zu kommen. Irgendwer mag mit Statistiken fummeln und was zu Prozentzahlen sagen.  
          
        Unverschlüsselte Kommunikation ist sowieso anfällig gegen alles. Der Knackpunkt ist, dass auch Verschlüsselung nicht gegen Angriffe schützt!  
          
        
        > Bei der Verwendung von https muss man sich hingegen fragen, ob die dadurch erhöhte Serverlast im Hinblick auf den Rest des noch zu erwartenden Sicherheitsgewinns vertretbar ist. Deshalb wäre ich beim Stand der bisherigen Diskussion für:  
        >   
        > https: keine Umbennnung  
          
        Falsch.  
          
        
        > http: Umbenennen mit session\_regenerate\_id(true)  
          
        Richtig.  
          
         - Sven Rautenberg
        
    3. Moin!

      Ich hab mir den Artikel gerade das erste mal durchgelesen und bin einigermaßen erschüttert. Vorallem weil der Quelltext selbst Sicherheitslücken aufweist:

      session_regenerate_id(); // erneuert die Session-ID,

      #                         // erschwert Session-Hijacking

      
      >   
      > Inwiefern sollte es gegen Session-Hijacking nützlich sein, bei jedem Request eine weitere gültige Session zu erzeugen? Das ist geradezu eine Einladung für Angriffe dieser Art.  
        
      Das Erzeugen einer neuen Session-ID ist ein probates Mittel gegen Session-Fixation - d.h. wenn der Angreifer einem einen Link schickt, der eine vom Angreifer vorbereitete Session fortführt, dann ist es für diesen trotzdem unmöglich, auf der Session mitzusurfen, wenn durch den Login die Session unter einer neuen ID fortgeführt wird.  
        
      Die alte Session zu verwerfen ist sicherlich schöner, aber man erhält in ihr ja keine weitergehenden Rechte. Der Login ist in der neuen Session.  
        
      
      > ~~~php
      
      if (! function_exists('crypt') ) {  // es gibt auch noch ältere ...  
      
      >    die ("Sorry: Aber Sie sollten Ihr PHP wirklich updaten!");  
      > }
      
      

      Wieso wird hier kein PHP-Fehler produziert, sondern eine Ausgabe an den Endnutzer vorgenommen? Wieso befinden sich diese Zeilen überhaupt irgendwo mitten im Loginskript und nicht ganz am Anfang oder ausgelagert in einem Unterprogramm, das nur die Systemabhängigkeiten prüft?

      Mein Einwand war ja, dass überhaupt keine Alternative zur Passwort-API von PHP (password_hash() etc.) selbstprogrammiert werden sollte. Es gibt die Reimplementierung für PHP 5.3 und 5.4, das sollte reichen.

      - Sven Rautenberg

  8. Ansehen (bitte auch mit Mobilgeräten):

    http://www.fastix.org/test/selfhtml_login/usermin.php (Derzeit ohne Passwort zugänglich)

    Jörg Reinholz

  9. Hallo Jörg,

    ich hätte da einen kleinen Einwand.
    Ich finde es Schade das der Benutzer, welcher sich anmelden soll, gleich bei dem ersten Besuch eine Meldung bekommt "Das kein Benutzername übertragen" wurde.

    Er hat sich zu dieser Zeit ja noch nicht einmal versucht anzumelden. Ich verstehe aber eines noch nicht. Wie kommt es zu dieser Meldung?

      
     if (! $_SERVER['REQUEST_METHOD'] == 'POST') {  
        show_login('', false);  
        exit;  
      }  
    
    

    Hier sollte beim ersten Seitenaufruf Schluss sein und das Formular für den Login angezeigt werden. $explain = false.
    Scheinbar nicht.
    Warum

      
    ...  
      // Simple Eingabeprüfung auf Übertragung des Benutzernamens und des Passwortes:  
      if ( ! isset ($_POST['username']) )   { show_login('', 'Benutzername nicht übertragen.'); exit; }  
    
    

    MfG
    Paul

    1. Hallo Jörg,

      ich hätte da einen kleinen Einwand.
      Ich finde es Schade das der Benutzer, welcher sich anmelden soll, gleich bei dem ersten Besuch eine Meldung bekommt "Das kein Benutzername übertragen" wurde.

      Alles klar. Ich räume das auf.

      Jörg Reinholz

  10. Ich will den Artikel PHP/Anwendung und Praxis/Loginsystem um den Schutz anderer Dateien ergänzen.

    Dazu will ich einen neuen Abschnitt einführen, der dann, neben einer Beschreibung  folgendes enthält:

    Ressource "sendFile.php"

    <?php  
    require_once('auth.php');  
    if ( isset($_GET['file']) && $_GET['file']) {  
       $_GET['file'] = './' . $_GET['file'];  
       $forbidden=array('../', '/..', '/.ht');  
       $_GET['file']= str_replace($forbidden,'', $_GET['file']);  
       if ( is_file($_GET['file']) && is_readable($_GET['file']) ) {  
         if ( function_exists('finfo_open') ) {  
             $finfo = finfo_open(FILEINFO_MIME_TYPE);  
             $mimeType=finfo_file($finfo, $_GET['file']);  
         } elseif ( function_exists('mime_content_type') ) {  
             $mimeType=mime_content_type($_GET['file']);  
         } else {  
             $mimeType="application/unknown";  
         }  
          header('Content-Type:'. $mimeType);  
          readfile($_GET['file']);  
          exit;  
       }  
    }  
    show_forbidden ();  
    exit;  
    
    

    Dazu die .htaccess:

    # keine Prüfung, ob mod_rewrite geladen ist.  
    # Es ist besser, einen 500er Fehler zu haben als die Dateien  
    # unbemerkt ungeschützt auszuliefern  
    RewriteEngine On  
      
    #Zugriffe auf versteckte Dateien (deren Namen  
    # beginnen bei Unixoiden mit einem Punkt)  
    werden verboten  
    RewriteRule "^.*/\."             - [F]  
    RewriteRule "^\."                - [F]  
      
    #Directory Index (ggf. mit Parametern)  
    RewriteRule "^$"                ./index.php [L]  
    RewriteRule "^?(.*$)"           ./index.php?$1 [L]  
      
    #PHP-Dateien kontrollieren sich selbst  
    RewriteRule "^(.*\.php)$"       - [L]  
    RewriteRule "^(.*\.php[?&].*)$" - [L]  
      
    #Ressourcen, die nicht durch sendFile.php kontrolliert werden  
    # z.B. Verzeichnis interior  
    RewriteRule "^interior/(.*)$"   - [L]  
      
    #Alles andere liefert die Datei sendFile.php aus  
    RewriteRule "^(.*)$" ./sendFile.php?file=$1 [L]  
    
    

    * Frage: Habe ich was übersehen?

    * Erster Diskussionspunkt:

    show_forbidden sollte aus meiner Sicht nicht zwischen Error 404 (Datei gibt es nicht) und 403 (Zutritt verboten) unterscheiden, um kein Angriffsziel im Sinne des Untersuchens, ob eine zu schützende Datei vorhanden ist, zu bieten.

    * Zweiter Diskussionspunkt:

    Tja. Was machen wir mit anderen Ressourcen? z.B. könnten Perl bzw. CGI Skripte auch die Session auswerten oder aber - und das ist der Stand des obigen - deren Quelltext ausliefern.

    Jörg Reinholz

    1. Beim Übertragen und Anpassen des Codes aus der funktionierenden Testumgebung sind mir kleine Fehler unterlaufen. Die .htaccess sieht natürlich so aus:

      # keine Prüfung, ob mod_rewrite geladen ist.  
      # Es ist besser, einen 500er Fehler zu haben als die Dateien  
      # unbemerkt ungeschützt auszuliefern:  
      RewriteEngine On  
        
      #Zugriffe auf versteckte Dateien (deren Namen  
      # beginnen bei Unixoiden mit einem Punkt)  
      #werden verboten  
      RewriteRule "^.*/\."             - [F]  
      RewriteRule "^\."                - [F]  
        
      #Directory Index (ggf. mit Parametern)  
      RewriteRule "^$"                ./index.php [L]  
      RewriteRule "^?(.*)$"           ./index.php?$1 [L]  
        
      #PHP-Dateien kontrollieren sich selbst  
      RewriteRule "^(.*\.php)$"       - [L]  
      RewriteRule "^(.*\.php[?&].*)$" - [L]  
        
      #Ressourcen, die nicht durch sendFile.php kontrolliert werden  
      # z.B. Verzeichnis interior  
      RewriteRule "^interior/(.*)$"   - [L]  
        
      #Alles andere liefert die Datei sendFile.php aus  
      RewriteRule "^(.*)$" ./sendFile.php?file=$1 [L]  
      
      

      Jörg Reinholz

  11. * Binden von IP-Adressen an die Session (als höchst simple Erweiterung der bisherigen login.php und auth.php)
    * Gruppen, in Verbindung mit Benutzer-Verwaltung einbauen - mit Gruppen root (darf Benutzer verwalten) und user
    * lastlogin und dazu
    * Möglichkeiten des Zerstören einer Session (und somit sofortigen Sperren und Rauswerfen eines Benutzers)

    Erledigt.

    Dazu: Schutz anderer Ressourcen (Auslieferung mittels sendFile.php).

    Erledigt.

    mit folgenden Verweisen zu Artikeln

    * Benutzerverwaltung und Speicherung
    ** Aufnahme weiterer Informationen
    ** Funktionen:
    *** adduser,
    *** deluser,
    *** moduser, + inklusive Sperren
    *** addgroup,
    *** delgroup,
    *** nodgroup
    *** passwd,

    Ich denke, das wird als Artikel im Wiki viel zu viel. Die Software (PHP-Skripte) zum Verwalten werde ich wohl zum Download anbieten.

    Jörg Reinholz