1unitedpower: Artikel "Loginsystem" gelöscht.

088

Artikel "Loginsystem" gelöscht.

  1. 0
    1. 0
      1. 0
        1. 0
          1. 0
            1. 0
              1. 0
                1. 0
                  1. 0
                    1. 0
                      1. 0
  2. 0
    1. 2
      1. 0
        1. 1
        2. 0
    2. 2
      1. 0
        1. 0
  3. -2

    Zusammenfassung der bisherigen Diskussion

  4. 1

    Der Autor sagt selbst: "soll weg"

    1. 7

      Der Autor führt Selbstgespräche?

      1. 0

        Unsinn. (Bildschirmfoto)

      2. 0

        Reicht nicht.

        1. 0
          1. 0
            1. 0
    2. 0
  5. 4
    1. 4
      1. 0
      2. 0
        1. 0
          1. 0
            1. 0
      3. 0
      4. 3
        1. 2
          1. 1
            1. 0
          2. 4
        2. 1
          1. 0
            1. 0

              10. Tag nach Behauptung "bestehender Sicherheitsmängel": Immer noch kein konkreter Angriffsvektor

              1. 0
              2. 0
                1. 0
                  1. 1
                    1. 0
                    2. 0

                      Die Löschmeldung sollte angemessen aktualisiert werden.

                      1. 0
                        1. 0

                          Die Löschmeldung wurde aktualisiert

                          1. 0
                            1. 7

                              Loginsystem - Warnmeldung

                              1. 0

                                Ich wende mich mit Grausen ab.

                                1. 0
                                  1. 0

                                    Aus meiner Sicht zerbricht die Community an Rechtshaberei und Machtspielchen.

                                  2. 0

                                    Ihr habt da ein schönes Forum ... behaltet es!

                              2. 3
                                1. 0
                                2. 0
                                  1. 0
                                    1. 0
                                      1. 1
                                        1. 0
                                          1. 0
                                    2. 0
                                      1. 0
                                        1. 2
                                          1. 0
                                            1. 0
                                              1. 0
                                                1. 0
                                              2. 0

                                                Was ich bezwecke?

                                                1. 0
                                                  1. 0

                                                    "Negativ-Werbung"

                                                    1. 1
                                                      1. 2
              3. 4
                1. 0
                  1. 0
                    1. 0
                  2. 0
                  3. 0

                    Nachtrag

                2. 0
              4. 1
                1. -1

                  "Friedensangebot" oder doch "Rechthaberei"?

Ich habe den Artikel http://wiki.selfhtml.org/wiki/PHP/Anwendung_und_Praxis/Loginsystem mit einem Verweis auf bestehende Sicherheitsmängel gelöscht. Ich habe das in der Vergangenheit mehrfach angesprochen und es hat sich leider keine Besserung eingestellt. Verfechter des Artikels reagieren zudem unreif und verweigern sich einer ernsthaften Debatte.

Folgende Nachrichten verweisen auf diesen Beitrag:

  1. Ich habe den Artikel http://wiki.selfhtml.org/wiki/PHP/Anwendung_und_Praxis/Loginsystem mit einem Verweis auf bestehende Sicherheitsmängel gelöscht. Ich habe das in der Vergangenheit mehrfach angesprochen und es hat sich leider keine Besserung eingestellt. Verfechter des Artikels reagieren zudem unreif und verweigern sich einer ernsthaften Debatte.

    Kleiner Wutanfall oder was ist mit Dir los?

    Du bist es in der, aus Deiner Sicht sicherlich auf reife und sachliche Weise geführten Debatte nämlich schuldig geblieben, konkrete Sicherheitsmängel zu benennen.

    Deine Aussage "Es gibt keine Anhaltspunkte dafür, dass das Loginsystem aus unserem Wiki-Artikel nach irgendeinem Maßstab sicher ist." reicht nämlich nicht aus um die jetzige Behauptung "bestehende Sicherheitsmängel" zu rechtfertigen.

    Insofern solltest Du überlegen, warum Du meinst, derart eigenmächtig handeln zu dürfen. Im Übrigen ist es Sinn eines Wiki, dass Falsches korrigiert wird. Eine Löschung ist immer ein Ausnahmefall.

    Aber wenn Du natürlich alles hier als Deine private Spielwiese betrachtest, dann bist Du natürlich berechtigt. Nur sollte dann irgendwo die Warnung stehen, dass hier der Wladimir Erdogan und der Recip Putin genau handeln wie zu Hause - und also ein Beitrag im Wiki jederzeit Opfer des von Dir offensichtlich geführten Privatkrieges sprechen, werden kann. Bei Tieren würde man übrigens von einem "Wegbeißen von Konkurrenten" sprechen.

    1. Tach,

      Du bist es in der, aus Deiner Sicht sicherlich auf reife und sachliche Weise geführten Debatte nämlich schuldig geblieben, konkrete Sicherheitsmängel zu benennen.

      ich halte es für ausreichend, dass der bisherige Haupt-Autor des Artikels sich aus dem Forum und dem Wiki offiziell zurückgezogen hat; es ist nicht sichergestellt, dass der definitiv sicherheitsrelevante Artikel weiter gepflegt werden wird.

      mfg
      Woodfighter

      1. ich halte es für ausreichend,

        Demnach stimmst Du mir darin zu, dass die von 1unitedpower in der Löschnachricht behaupteten Sicherheitsmängel nicht konkret belegt sind.

        dass der bisherige Haupt-Autor des Artikels sich aus dem Forum und dem Wiki offiziell zurückgezogen hat;

        Ach? Habt ihr den schon "weggebissen"?

        es ist nicht sichergestellt, dass der definitiv sicherheitsrelevante Artikel weiter gepflegt werden wird.

        Hier wage ich sachliches Argument: Der Versionsgeschichte nach ist das ein Artikel, welcher recht häufig und von mehreren Personen über den gesamten Zeitraum seines Bestehens hinweg immer wieder, fast sogar regelmäßíg verändert wurde. Also hatte er noch Pflege.

        Wie sähe denn das Wiki aus, wenn alle Einträge von Autoren, welche sich zurückgezogen haben, gelöscht würden? Wie der Kühlschrank eines Junggesellen? (Wasser und Licht drin?)

        1. Tach,

          ich halte es für ausreichend, dass der bisherige Haupt-Autor des Artikels sich aus dem Forum und dem Wiki offiziell zurückgezogen hat;

          Ach? Habt ihr den schon "weggebissen"?

          soll das witzig sein? Falls du es tatsächlich nicht wissen solltest (wovon ich schwer überrascht wäre), so verschwand er hier: https://forum.selfhtml.org/self/2016/mar/14/das-skript-zum-montag-blocklist-punkt-de-befragen/1663380#m1663380.

          mfg
          Woodfighter

          1. Ach? Habt ihr den schon "weggebissen"?

            soll das witzig sein? Falls du es tatsächlich nicht wissen solltest (wovon ich schwer überrascht wäre), so verschwand er hier: https://forum.selfhtml.org/self/2016/mar/14/das-skript-zum-montag-blocklist-punkt-de-befragen/1663380#m1663380.

            Das führe ich also, jedenfalls in dieser Deutlichkeit ganz unerwartet, unter "Volltreffer". Klarer Fall von "weggebissen".

            Folgende Nachrichten verweisen auf diesen Beitrag:

            1. Tach,

              Das führe ich also, jedenfalls in dieser Deutlichkeit ganz unerwartet, unter "Volltreffer". Klarer Fall von "weggebissen".

              https://www.youtube.com/watch?v=pWdd6_ZxX8c; da die damals bewertenden Mitglieder des Forums, die den Thread (und die mindestens zwei weiteren Threads davor) gesehen haben, das wohl ähnlich wie @1unitedpower und ich sahen, stört mich das auch nicht.

              mfg
              Woodfighter

              1. Tach,

                Das führe ich also, jedenfalls in dieser Deutlichkeit ganz unerwartet, unter "Volltreffer". Klarer Fall von "weggebissen".

                https://www.youtube.com/watch?v=pWdd6_ZxX8c; da die damals bewertenden Mitglieder des Forums, die den Thread (und die mindestens zwei weiteren Threads davor) gesehen haben, das wohl ähnlich wie @1unitedpower und ich sahen, stört mich das auch nicht.

                Dann ist die Sache doch klar: Schämt euch, @woodfighter und @1unitedpower. Denn Ihr habt allen Grund dazu. Frage:

                Wie viele der "damals bewertenden Mitglieder des Forums" waren denn "Sockenpuppen"? Die in mehrerer Hinsicht "hässliche" Art und Weise der Diskussion lässt deren Einsatz erfahrungsgemäß vermuten.

                1. Tach,

                  Das führe ich also, jedenfalls in dieser Deutlichkeit ganz unerwartet, unter "Volltreffer". Klarer Fall von "weggebissen".

                  https://www.youtube.com/watch?v=pWdd6_ZxX8c; da die damals bewertenden Mitglieder des Forums, die den Thread (und die mindestens zwei weiteren Threads davor) gesehen haben, das wohl ähnlich wie @1unitedpower und ich sahen, stört mich das auch nicht.

                  Dann ist die Sache doch klar: Schämt euch, Woodfighter und 1unitedpower. Denn Ihr habt allen Grund dazu.

                  Wie kommst du auf das schmale Brett?

                  Wie viele der "damals bewertenden Mitglieder des Forums" waren denn "Sockenpuppen"? Die Art und Weise der Diskussion lässt deren Einsatz erfahrungsgemäß vermuten.

                  Das kann ich nicht überprüfen, aber die Struktur des Bewertungssystems spricht eher für wenige. In meinem Falle, keine (auch wenn ich weiß, wie sinnlos diese Aussage ist). Falls du das klären willst, kannst du dich aber gerne an die Mods/Admins wenden, die das damals offenbar nicht fragwürdig fanden.

                  Und bevor wir hier sinnlos weiterdiskutieren, hätte ich bitte eine Auskunft zu deiner Identität, denn bisher scheinst du mir eine Sockenpuppe zu sein; User @ist weg hat schließlich schon in der Vergangenheit das Forum mindestens einmal verlassen und ist dann mit einem neuen Namen aufgetreten. Falls dem nicht so sein sollte, entschuldige für die Verdächtigung.

                  mfg
                  Woodfighter

                  1. Dann ist die Sache doch klar: Schämt euch, Woodfighter und 1unitedpower. Denn Ihr habt allen Grund dazu.

                    Wie kommst du auf das schmale Brett?

                    Alternativ-Text Alternativ-Text

                    Und hier der "weggebissene" Konkurrent:

                    Alternativ-Text

                    Danke für die Links zu den Profilen. Die haben mich auf den Trichter grebracht, mal nachzusehen. Das Resultat spricht noch mehr für ein "wegbeissen" eines Konkurrenten.

                    kannst du dich aber gerne an die Mods/Admins wenden

                    Wozu sollte das denn gut sein, wenn die auch handfeste Beleidigungen wie die Links zu Videos mit diesen Dödel (oder wie der Typ heisst) übersehen?

                    Und bevor wir hier sinnlos weiterdiskutieren, hätte ich bitte eine Auskunft zu deiner Identität

                    Im Hinblick auf die mögliche Rufschädigung durch eine ähnliche Aktion bin ich gerade nicht sehr geneigt, meine Identität preiszugeben und würde auch Dritten nicht dazu raten.

                    1. Tach,

                      ich verabschiede mich dann mal aus diesem Thread, sehe mich in meiner Vermutung bestätigt und gehe auf deine Verschwörungstheorien nicht weiter ein; falls du insitieren solltest, dass ich mit @1unitedpower identisch bin: Ich glaube, es gibt Menschen, die sowohl mich als auch ihn schon auf Selftreffen gesehen haben.

                      mfg
                      Woodfighter

                      1. falls du insitieren solltest, dass ich mit @1unitedpower identisch bin

                        Das habe ich gerade nicht behauptet. Die Bildschirmfotos belegen den Punktestand und damit die Konkurrenzsituation und sprechen also für das "Wegbeissen".

                        Ich denke, die Mods/Admins sollten auf Euch beide sehr genau aufpassen.

  2. @@1unitedpower

    Ich habe den Artikel http://wiki.selfhtml.org/wiki/PHP/Anwendung_und_Praxis/Loginsystem mit einem Verweis auf bestehende Sicherheitsmängel gelöscht.

    Da fielen mir noch andere Artikel ein, die in dieser Form nicht im Wiki stehen sollten.

    „Die hier vorgestellte technische Umsetzung schließt manche User davon aus, dieses Tic-Tac-Toe-Spiel zu nutzen. […] Es ist eine ethisch-moralische Frage, ob man es sich erlauben darf, diesen Nutzerkreis auszuschließen, weil eine Lösung ohne Barrieren etwas mehr Entwicklungsaufwand braucht.“

    Diese „Entschuldigung“ geht meilenweit am Problem vorbei.

    Es ist eine ethisch-moralische Frage, ob man es sich erlauben darf, Tutorials anzubieten, die bewusst „Lösungen“ propagieren, die Nutzer ausschließen.

    Von mir dazu ein ganz klares Nein. Woher sollen denn (angehende) Webentwickler lernen, wie man niemanden ausschließt, wenn es ihnen nicht vorgelebt wird?

    Tutorials, die mit unbenutzbaren Beispielen daherkommen, sollten aus dem Web verschwinden. Insbesondere auch aus SELFHTML.

    Außerdem verbreitet diese „Entschuldigung“ die Unwahrheit. Eine Lösung ohne Barrieren braucht kaum mehr Entwicklungsaufwand, sondern vor allem: mehr Wissen.

    Und dies kann nur über gute Tutorials vermittelt werden, die auf benutzbare Beispiele wertlegen.

    Ich habe das in der Vergangenheit mehrfach angesprochen und es hat sich leider keine Besserung eingestellt. Verfechter des Artikels reagieren zudem unreif und verweigern sich einer ernsthaften Debatte.

    Ja, auch das.

    LLAP 🖖

    -- “There’s no such thing as an ‘average’ user, but there is such a thing as an average developer.” —Vitaly Friedman in Accessibility Matters: Meet Our New Book, “Inclusive Design Patterns”
    Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
    1. Hallo Gunnar Bittersmann,

      Tutorials, die mit unbenutzbaren Beispielen daherkommen, sollten aus dem Web verschwinden. Insbesondere auch aus SELFHTML.

      Warum trägst du nichts dazu bei? Deine Beiträge hier im Forum sowie deine dabblett-Beispiele finden leider nicht von selbst ins Wiki. Die Zeit, die du dafür investiert hast, hättest du auch gleich ins Wiki stecken können. Für technische Probleme hättest du jederzeit meine Unterstützung haben können.

      Ich habe das in der Vergangenheit mehrfach angesprochen und es hat sich leider keine Besserung eingestellt. Verfechter des Artikels reagieren zudem unreif und verweigern sich einer ernsthaften Debatte.

      Obwohl ich mich als Verfechter des (Tic-Tac-Toe)-Artikels sehe, fühle ich mich nicht angesprochen.

      Bis demnächst
      Matthias

      -- Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
      1. @@Matthias Apsel

        Tutorials, die mit unbenutzbaren Beispielen daherkommen, sollten aus dem Web verschwinden. Insbesondere auch aus SELFHTML.

        Warum trägst du nichts dazu bei? Deine Beiträge hier im Forum sowie deine dabblett-Beispiele finden leider nicht von selbst ins Wiki.

        Warum fragst du nicht Felix, warum er meine Beiträge nicht in seinen Wiki-Artikel übernommen hat?

        LLAP 🖖

        -- “There’s no such thing as an ‘average’ user, but there is such a thing as an average developer.” —Vitaly Friedman in Accessibility Matters: Meet Our New Book, “Inclusive Design Patterns”
        Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
        1. Lieber Gunnar,

          Warum fragst du nicht Felix, warum er meine Beiträge nicht in seinen Wiki-Artikel übernommen hat?

          und diese Reaktion nennst Du nicht "unreif"? I rest my case.

          Liebe Grüße,

          Felix Riesterer.

        2. Hallo Gunnar Bittersmann,

          Warum trägst du nichts dazu bei? Deine Beiträge hier im Forum sowie deine dabblett-Beispiele finden leider nicht von selbst ins Wiki.

          Warum fragst du nicht Felix, warum er meine Beiträge nicht in seinen Wiki-Artikel übernommen hat?

          Es ist ja nicht sein Artikel, es ist unser, auch dein Artikel. Ich habe den Forumsthread für mich als interessant markiert, damit ich daran erinnert werde, deine Änderungen einzuarbeiten. Bisher bin ich leider noch nicht dazu gekommen.

          Bis demnächst
          Matthias

          -- Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
    2. Lieber Gunnar,

      Von mir dazu ein ganz klares Nein. Woher sollen denn (angehende) Webentwickler lernen, wie man niemanden ausschließt, wenn es ihnen nicht vorgelebt wird?

      Dein "Vorleben" erschöpft sich im Reden.

      Tutorials, die mit unbenutzbaren Beispielen daherkommen, sollten aus dem Web verschwinden. Insbesondere auch aus SELFHTML.

      Du bietest keinen besseren Ersatz, also bleiben sie.

      Außerdem verbreitet diese „Entschuldigung“ die Unwahrheit. Eine Lösung ohne Barrieren braucht kaum mehr Entwicklungsaufwand, sondern vor allem: mehr Wissen.

      Du bist den Beweis noch immer schuldig. Und nein, weitere Verweise und Zitate sind kein Beweis. Gegenbeispiele, sprich ein Handeln (im Wiki) Deinerseits, wäre ein Beweis.

      Ich habe das in der Vergangenheit mehrfach angesprochen und es hat sich leider keine Besserung eingestellt. Verfechter des Artikels reagieren zudem unreif und verweigern sich einer ernsthaften Debatte.

      Da Du Deine Glaubwürdigkeit unverändert weiterhin verspielst, da Du nur in besserwisserischer Art und Weise predigst, wirst Du unverändert weiterhin nichts erreichen. Das habe ich Dir nun auch schon oft genug kommuniziert. Daher solltest Du mit Adjektiven wie "unreif" vorsichtig sein, da Du Deine Hausaufgaben in puncto Kommunikationsmodell noch immer nicht gemacht hast.

      Liebe Grüße,

      Felix Riesterer.

      1. @@Felix Riesterer

        Von mir dazu ein ganz klares Nein. Woher sollen denn (angehende) Webentwickler lernen, wie man niemanden ausschließt, wenn es ihnen nicht vorgelebt wird?

        Dein "Vorleben" erschöpft sich im Reden.

        Beiträge schreiben, Beispiele erstellen, Barcamp-Sessions halten … – das fasst du alles unter „Reden“ zusammen?

        Tutorials, die mit unbenutzbaren Beispielen daherkommen, sollten aus dem Web verschwinden. Insbesondere auch aus SELFHTML.

        Du bietest keinen besseren Ersatz

        Nein!! – Doch!! – Oh!!

        LLAP 🖖

        -- “There’s no such thing as an ‘average’ user, but there is such a thing as an average developer.” —Vitaly Friedman in Accessibility Matters: Meet Our New Book, “Inclusive Design Patterns”
        Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
        1. Hallo Gunnar Bittersmann,

          Beiträge schreiben, Beispiele erstellen, Barcamp-Sessions halten … – das fasst du alles unter „Reden“ zusammen?

          Deine hilf- und umfangreichen Antworten hier sind tatsächlich eine Bereicherung für das Forum und eine wirkliche Hilfe für den Fragenden. Als Beispiel seien hier Markup für Formulare oder eben auch der von dir unten genannte Beitrag zum TicTacToe genannt. Sie sorgen auch bei mir regelmäßig für aha-Effekte. Und ich bin sicher, das gilt auch für den einen oder anderen Stammgast.

          Nein!! – [Doch!!](https://forum.selfhtml.org/meta/2016/jan/2/neues-anfaenger-tutorial-fuer-javascript-tic-tac-toe/1658806#m1658806) – Oh!!

          Wir haben übrigens einen URL-shortener am Start.

          Nein!! – [Doch!!](https://forum.selfhtml.org/m1658806) – Oh!!
          Nein!! – Doch!! – Oh!!

          Wie vorher schon geschrieben. Leider landen diese Beiträge nicht von selbst im Wiki. M1658806 sollte aber unbedingt den Weg dorthin finden.

          Bis demnächst
          Matthias

          -- Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.

          Folgende Nachrichten verweisen auf diesen Beitrag:

  3. @1unitedpower hatte den Wiki-Artikel http://wiki.selfhtml.org/wiki/PHP/Anwendung_und_Praxis/Loginsystem unter der Behauptung bestehender Sicherheitsmängel gelöscht.

    Er hat trotz mehrmaliger Aufforderung keine konkreten Sicherheitsmängel genannt, seine Behauptung also nicht durch Tatsachen erhärtet. In der Debatte und auch schon vorher hatte er nur angeführt, dass Sicherheitsmängel nicht ausgeschlossen seien, was von der Behauptung, es gäbe solche, inakzeptabel weit entfernt ist.

    @woodfighter hat ausgeführt, der Autor hätte sich zurückgezogen und der Artikel hätte keine Pflege mehr. Dieses ist aber laut Versionsgeschichte aber so unzutreffend, wie es nur unzutreffend sein kann.

    Das in Wikis übliche Szenario, dass vor einer Löschung eine Diskussion stattfindet, fand nicht statt.

    [x] Ich bin für wieder herstellen.

  4. Frage:

    Dein Artikel zum Login-System wurde gelöscht. Es gibt eine Diskussion dazu: https://forum.selfhtml.org/meta/2016/jun/30/artikel-loginsystem- geloescht/1670108#m1670108

    Antwort:

    Hallo und Dank für die Nachricht. Und: NEIN, ich werde an der Diskussion nicht teilnehmen. Es ist mir recht, dass der Artikel gelöscht wurde. Ich bekomme hier dazu mindestens 1 Mail pro Woche (zum Glück sind jetzt alle mit Grillen beschäftigt, im Winter, also just als ich ohnehin Stress hatte,waren es deutlich mehr) und natürlich erwartet jeder wegen des Ortes der Veröffentlichung kostenlosen Support. Sogar als ich letzten Herbst in Griechenland war... Für mich stellt sich die Frage nach der Wirtschaftlichkeit und wenn die Werbung schon so teuer wird, dann will ich diese auch für mich selbst machen. Ich habe genug Baustellen und sicherlich bessere Verwendung. Gut zu wissen, dass ich das Theater los bin. Ich möchte dort auch nicht mehr genannt werden.

    Tja. Da war mein Einsatz vergebliche Liebesmüh. Scheinbar hat er es sehr persönlich genommen.

    Folgende Nachrichten verweisen auf diesen Beitrag:

    1. Tach!

      Ach Jörg, wem versuchst du hier eigentlich was vorzumachen? Die virtuelle Handschrift der Postings unter deinem Namen und von "Google weiß alles" gleicht sich schon seit einer Weile dermaßen signifikant, dass es schon ein sehr starker Zufall wäre, wenn ihr zwei Personen sein solltet.

      dedlfix.

      1. Alternativ-Text

        Ich war dafür den Artikel zu behalten, er sagt aber der soll weg. Reicht das nicht?

      2. Reicht nicht.

        Google weiß alles

        So ein Mist.

        Ab 10 positiven Bewertungen hätte ich einen Ausweis, nachfolgend Reisepass und Bankkonto beantragen und eine GmbH gründen können.

        Sollte nicht so sein.

        1. Hallo Google weiß alles,

          Ab 10 positiven Bewertungen hätte ich einen Ausweis, nachfolgend Reisepass und Bankkonto beantragen und eine GmbH gründen können.

          Dem @dedlfix sind seine Punkte so wichtig, dass er sich seinen Punktestand via User-CSS nicht anzeigen lässt.

          Bis demnächst
          Matthias

          -- Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
          1. Reicht nicht.

            Google weiß alles

            Dem @dedlfix sind seine Punkte so wichti

            Himmel! Als gänge es um den dedlfix.

            1. Hallo Google weiß alles,

              Dem @dedlfix sind seine Punkte so wichti

              Himmel! Als gänge es um den dedlfix.

              Naja, du antwortest auf einen seiner Beiträge, der 7 positive Bewertungen erhalten hat.

              Bis demnächst
              Matthias

              -- Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
    2. Lieber Jörg,

      Scheinbar hat er es sehr persönlich genommen.

      nicht scheinbar, sondern anscheinend - aber das auch nicht, sondern offensichtlich.

      Liebe Grüße,

      Felix Riesterer.

  5. Lieber 1unitedpower,

    Ich habe den Artikel http://wiki.selfhtml.org/wiki/PHP/Anwendung_und_Praxis/Loginsystem mit einem Verweis auf bestehende Sicherheitsmängel gelöscht.

    diese Reaktion finde ich sehr harsch, zumal es nach meinem Empfinden nicht ausreichend Kommunikation im Vorfeld gab. Schöner hätte ich es gefunden, wenn Du vor der Löschung ein Ultimatum gestellt hättest, so á la "Wenn sich hier keiner mehr dazu äußert, oder wenn die Sicherheit nachweisbar(!) nicht ausreichend gewährleistet werden kann, lösche ich das Teil!"

    Dass Jörg entsprechend emotional reagiert, finde ich verständlich. Dass die Kommunikationsweise gerade nicht optimal verläuft, liegt sicher an der Schärfe, mit der Du hier relativ unvermittelt(!) vorgehst, zumal es in der Versionshistorie ganz offensichtlich eine aktive Bearbeitung gibt... wie andere vor mir bereits angemerkt haben.

    Vorschlag zur Güte: Könntest Du die tatsächliche Unsicherheit herausarbeiten, damit Du nicht nur "kann nicht gewährleistet werden" als Kritik anführen, sondern ganz speziell den Finger in die Wunde legen kannst, so nach dem Motto "Hier ist die Sache konzeptionell kaputt."?

    Alternativ könnte ich mir ein weniger feature-haltiges Konzept als Neuauflage des Artikels vorstellen, in dem die Sache mit den Sessions, mit dem Hashing von Passwörtern und dem Umgang damit vorgestellt wird. Mehr kann das Wiki meiner Meinung nach nicht leisten, da solche komplexen Themen wie Sicherheit im Erstellen von Web-Applikationen unmöglich erschöpfend abgehandelt werden können. Alleine die neuen Erkenntnisse, die sich in diesem Zusammenhang immer wieder ergeben (das ändern der SID bei jedem Request sei nur ein nicht mehr so taufrisches Beispiel), müssen von Machern solcher Systeme durch Verfolgen der einschlägigen Web-Resourcen im Selbststudium erarbeitet werden.

    Wenn Du einen 100%ig sicheren Software-Vorschlag im Wiki anbieten möchtest, dann ist ein Artikel wie der von Jörg grundsätzlich unmöglich. Das finde ich nicht praktikabel! Zwar müssen wir nicht auf dem (Sicherheits-)Niveau von Youtube-Tutorials vermitteln (z.B. mit $_POST[pass]-artiger Codequalität), aber eine Grenze des sinnvoll Machbaren darf auch nicht (all)zu hoch gehängt werden!

    Liebe Grüße,

    Felix Riesterer.

    1. Ich habe den Artikel http://wiki.selfhtml.org/wiki/PHP/Anwendung_und_Praxis/Loginsystem mit einem Verweis auf bestehende Sicherheitsmängel gelöscht.

      diese Reaktion finde ich sehr harsch, zumal es nach meinem Empfinden nicht ausreichend Kommunikation im Vorfeld gab.

      Das sehe ich anders, die Forensuche belegt, dass der Artikel immer wieder in der Kritik stand und für große Verunsicherung bei der Leserschaft gesorgt hat.

      Schöner hätte ich es gefunden, wenn Du vor der Löschung ein Ultimatum gestellt hättest, so á la "Wenn sich hier keiner mehr dazu äußert, oder wenn die Sicherheit nachweisbar(!) nicht ausreichend gewährleistet werden kann, lösche ich das Teil!"

      Der Artikel hat die Bringschuld auf seiner Seite, er sollte nachweisen, dass das dort vermittelte Loginsystem bestimmte Sicherheitsanforderungen erfüllt und nicht umgekehrt. Das Gegenteil ist imho. auch schon zu oft gezeigt worden. Das ist vergleichbar mit einem Autobesitzer, der dafür Sorge tragen muss, dass sein Auto verkehrssicher ist. Deshalb muss es durch den TÜV, besteht es dort nicht, darf das Auto nicht gefahren werden. In der Informationstechnik sind wir glücklicherweise nicht immer auf externe Zertifizierungsstellen angewiesen, wir haben formale Methoden, die es uns erlauben den Sicherheitsnachweis auf nachvollziehbare Weise zu erbringen.

      Dass Jörg entsprechend emotional reagiert, finde ich verständlich. Dass die Kommunikationsweise gerade nicht optimal verläuft, liegt sicher an der Schärfe, mit der Du hier relativ unvermittelt(!) vorgehst, zumal es in der Versionshistorie ganz offensichtlich eine aktive Bearbeitung gibt... wie andere vor mir bereits angemerkt haben.

      Eine aktive Versionsgeschichte ist kein Qualitätsmerkmal. Einige der Verfechter und Autoren des Artikels haben sich in meinen Augen sowohl fachlich als auch zwischenmenschlich bereits disqualifiziert, um ein derartig sicherheitskritisches Loginsystem technisch und didaktisch zu betreuen.

      Den Vorwurf, ich ginge unvermittelt vor, weise ich ebenfalls zurück. Ich hab mich von Anfang an immer wieder an Diskussionen zu dem Artikel beteiligt. Mit der Schärfe meines Tonfalls hast du vermutlich nicht ganz unrecht. Ich versuche zwar einen sachlichen Ton zu bewahren, was mir angesichts der Beleidigungen und obskuren Anschuldigungen (nicht nur in meine Richtung, sondern auch gegen andere Forenteilnehmer und entfernte Kollegen) bestimmt nicht immer leicht fällt und auch nicht immer gelingt.

      Vorschlag zur Güte: Könntest Du die tatsächliche Unsicherheit herausarbeiten, damit Du nicht nur "kann nicht gewährleistet werden" als Kritik anführen, sondern ganz speziell den Finger in die Wunde legen kannst, so nach dem Motto "Hier ist die Sache konzeptionell kaputt."?

      Gut, ich werde allerdings nicht wiederholen, was ich andernorts schon gesagt habe. Zusätzlich sollte das Loginsystem die folgenden Punkte mindestens erfüllen, um damit noch nicht als sicher, aber zumindest als überprüfbar eingestuft werden zu können:

      • Eine klare Trennung zwischen Schnittstellen- und Anwendungscode. Dazu gehört auch eine formale Schnittstellenbeschreibung. PHP bietet dafür ein inzwischen recht robustes Typsystem und gute Testing-Frameworks. Gluecode, der die Schnittstelle mit der Beispielanwendung koppelt, sollte möglichst bündig ausfallen, wenn er zu lang wird, ist das ein Zeichen dafür, dass die Schnittstelle nicht die richtigen Abstraktionen bietet.
      • Das System muss auf seine Kernaufgaben beschränkt werden. Schichten, die bspw. nur der Abwärtskompatibilität dienen, sollten sich nicht darin wiederfinden.
      • Es muss eine Modularisierung stattfinden, die die große Aufgabe "Loginsystem" seziert, in kleine Unteraufgaben zerteilt und klare Verantwortlichkeiten schafft. Aktuell ist die Autorisierung eng gekoppelt mit der Ausgabelogik. Das stört beim Testen und verkompliziert unnötigerweise das mentale Modell des Codes.
      • Der Kontrollfluss muss vorhersehbar sein, mit eindeutigen Eintritts- und Austrittspunkten. D.h. insbesondere keine exit- oder die-Statements in der Schnittstellen-Implementierung.
      • Der Datenfluss muss definiert sein, möglichst unidirektional mit starker Präferenz für Lokalität gegenüber globalem Zustand und einem verantwortungsbewusstem Einsatz von Nebenwirkungen.
      • Der Code sollte zwecks Lesbarkeit modernen Codingstandards folgen, für PHP ist das am häufigsten der PSR-Standard. Code-Linter können eine reihe an Codesmells entdecken und die Einhaltung gesetzter Standards verifizieren.

      Wenn Du einen 100%ig sicheren Software-Vorschlag im Wiki anbieten möchtest, dann ist ein Artikel wie der von Jörg grundsätzlich unmöglich. Das finde ich nicht praktikabel!

      100%ige Sicherheit ist eine Illusion, aber (in)formelle Überprüfbarkeit ist die Mindestvoraussetzung, die wir schaffen müssen. Können wir das nicht leisten, dann hat unser Wiki an dieser Stelle besser eine Lücke.

      Folgende Nachrichten verweisen auf diesen Beitrag:

      1. Der Artikel hat die Bringschuld auf seiner Seite, er sollte nachweisen, dass das dort vermittelte Loginsystem bestimmte Sicherheitsanforderungen erfüllt und nicht umgekehrt.

        Ich zitiere Dich mal:

        Ich habe den Artikel http://wiki.selfhtml.org/wiki/PHP/Anwendung_und_Praxis/Loginsystem mit einem Verweis auf bestehende Sicherheitsmängel gelöscht.

        An die Stelle des Artikels hast Du u.a. folgende Äußerung gesetzt:

        Über die Jahre sind allerdings diverse Sicherheitslücken im System aufgefallen, teilweise sind sie danach geschlossen worden.

        Damit hast Du mehrfach konkret behauptet, das es eine Vielzahl von konkreten Sicherheitslücken gab, von denen ein Teil nicht geschlossen wurde.

        Und das ist unwahr.

        Du behauptest weiter:

        Ich versuche zwar einen sachlichen Ton zu bewahren, was mir angesichts der Beleidigungen und obskuren Anschuldigungen (nicht nur in meine Richtung, sondern auch gegen andere Forenteilnehmer und entfernte Kollegen) ...

        Damit behauptest Du: Du wurdest beleidigt.

        Auch das ist unwahr.

        Jetzt komme mir nicht mit der Nummer, es sei nicht nachgewiesen, dass Du nicht beleidigt wurdest. Im Übrigen stellt Du damit selbst klar, dass persönliche Gründe für Deinen Entschluss zu Löschen relevant waren.

        Du behauptest weiter:

        die Forensuche belegt, dass der Artikel immer wieder in der Kritik stand und für große Verunsicherung bei der Leserschaft gesorgt hat.

        Bitte weise die Fundstellen nach. Denn ich gehe davon aus, dass es diese - hinsichtlich Deiner Behauptung einer "Verunsicherung bei der Leserschaft" nicht gibt.

        Und bevor Du wieder mit der Nummer kommst, dass das Skript ja nicht mal die PHP-Version prüfe und deshalb angreifbar sei:

        Lieber Freund!

        Wenn ein Unterbleiben einer solchen Prüfung dazu führt, dass Wiki-Einträge diskussionslos gelöscht werden, dann entferne - mit der selben Begründung - alle Artikel im Wiki in denen <?php ... ?> vorkommt. Prüfe dann aber auch, ob das Wiki die zugrunde legende PHP-Version (oder was auch immer) prüft. Und dann aber bitte auch das OS. Vielleicht willst Du ja den ganzen Server löschen?

        Zum Schluss gebe ich erst Dir und nachrangig dem Verein folgendes noch mit: Deine Vorgehensweise kann auch andere davon abschrecken, im Wiki auch nur irgendwas zu veröffentlichen. Wenn das Dein Wunsch ist - wonach es für mich aussieht - dann mach "Deinen Scheiß" doch selbst.

        • Das System sollte ferner isoliert von weiteren, unabhängigen Autorisierungssystemen arbeiten. Das gegenwärtige Loginsystem interferiert mit der Apache Implementierung für HTTP Basic Auth. Die PHP-Anwendung soll ruhig HTTP Basic Auth verwenden dürfen, aber Wechselwirkungen mit der Apache Implementierung müssen ausgeschlossen werden.
          • Das System sollte ferner isoliert von weiteren, unabhängigen Autorisierungssystemen arbeiten. Das gegenwärtige Loginsystem inferiert mit der Apache Implementierung für HTTP Basic Auth.

          Das ist eine Behauptung.

          Könntest Du bitte dieses "inferiert" erst durch Worte ersetzen, die den Sinngehalt verdeutlichen (im Duden fand ich nur: "Inferenz - aufbereitetes Wissen, das aufgrund von logischen Schlussfolgerungen gewonnen wurde")? Die Verwendung von Worten, deren Bedeutung vielen unklar ist, ist geeignet bei vielen Lesern Unsicherheit zu erzeugen.

          Und so liegt der Fall auch hier.

          Soweit Du nämlich damit vorträgst, das gezeigte System überschneide sich mit der Apache Implementierung für HTTP Basic Auth, sollte dazu auch etwas ausgeführt werden. Das es einen Hinweis auf die Kompatibilität der Passwort-Datei im gelöschten Artikel gab dürfte nicht für diese Kritik reichen, denn immerhin lässt sich beim HTTP Basic Auth die Passwort- und die Gruppen-Datei ebenfalls frei bestimmen. Es könnte also stets und bei jedem Skript oder Programm, welches Dateien gleich welcher Art liest oder schreibt zu dem kommen, was Du mit "inferiert" womöglich meinst.

          Das bedeutet jetzt aber, dass Du letztendlich darlegst, das vorgestellte System sei deshalb unsicher, weil die ihm zugrunde liegenden Dateien von anderer Software manipuliert und beschädigt werden können oder weil es Dateien benutzt und deshalb Dateien anderer Software manipulieren und ergo beschädigen kann.

          Das ist aber stets der Fall wenn Software kombiniert wird, die gespeicherte Daten liest und/oder schreibt. Also kein Merkmal oder gar Fehler des gezeigten Loginsystems sondern fast jeden Programms.

          Weshalb diese Kritik dann doch etwas weit her geholt und substanzlos wirkt.

          1. Hi,

            • Das System sollte ferner isoliert von weiteren, unabhängigen Autorisierungssystemen arbeiten. Das gegenwärtige Loginsystem inferiert mit der Apache Implementierung für HTTP Basic Auth.

            Könntest Du bitte dieses "inferiert" erst durch Worte ersetzen, die den Sinngehalt verdeutlichen (im Duden fand ich nur: "Inferenz - aufbereitetes Wissen, das aufgrund von logischen Schlussfolgerungen gewonnen wurde").

            er meinte wohl interferieren, also in Wechselwirkung treten.

            Soweit Du meinst, das gezeigte System überschneide sich ...

            Ja, überschneiden ist vielleicht auch eine gute Umschreibung.

            Ciao,
             Martin

            -- Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
            - Douglas Adams, The Hitchhiker's Guide To The Galaxy
            1. er meinte wohl interferieren, also in Wechselwirkung treten.

              Meinte ich, habe ich korrigiert.

        • Das System muss auf seine Kernaufgaben beschränkt werden. Schichten, die bspw. nur der Abwärtskompatibilität dienen, sollten sich nicht darin wiederfinden.

        Schöne Theorie. Soweit Du das eventuell von einer Drittquelle hast beachte bitte das "sollte nicht". Das "sollte nicht" heißt nicht "darf nicht".

        Und so liegt der Fall auch hier: In der Realität jenseits der Akademien finden sich genügend Kunden irgendwelcher Hoster welche nicht die jeweils aktuellste PHP-Version verwenden (Kunden: können). Und es ist eben so, dass diesen ein Workaround geboten werden muss, wenn - was sinnvoll ist - diesen Mantelfunktionen wie eben password-* zur Benutzung empfohlen werden. Es sei denn man will diese Leser ganz bewusst nicht bedienen.

        Tatsache ist, dass durch zwei oder drei Mantelfunkionen die Sicherheit nicht verletzt wurde, denn diese waren "sauber". Wird eine zu alte PHP-Version benutzt, welche die zugrunde liegenden und als noch vertretbar sicher bewerteten Hash-Algorithmen nicht kennt dann tritt der Fall ein, dass Passwörter nicht gespeichert werden bzw. eine positive Authentifikation definitiv nicht stattfindet. Das ist es, was man - jedenfalls jenseits rein akademischer Betrachtungen - erwartet und als "sicher genug" erachtet.

        • Es muss eine Modularisierung stattfinden, die die große Aufgabe "Loginsystem" seziert, in kleine Unteraufgaben zerteilt und klare Verantwortlichkeiten schafft.

        In einem Wiki-Beitrag mit wie "vielen" Zeilen Code dazu? Ei freilich, man kann jede Aufgabe so lange zerlegen, verteilen und den dann für Teilaufgaben bestimmten dann Verantwortlichkeiten zuweisen und dieses für die Teilaufgaben von neuem beginnen bis die ursprüngliche Aufgabe gar nicht mehr erfüllt wird. Diese Kritik erscheint mir im Hinblick auf die wenigen Zeilen Programmcode als "überzogen akademisch" und vorliegend "völlig deplaziert".

        • Der Kontrollfluss muss vorhersehbar sein, mit eindeutigen Eintritts- und Austrittspunkten. D.h. insbesondere keine exit- oder die-Statements in der Schnittstellen-Implementierung.

        Ebenso: Akademisch, deplaziert. Hier geht es nicht um große Organisationen oder ein großes Programm.

        Überlege mal, was hinsichtlich der verunsicherten Leser passieren würde, wenn der Code Deinen Forderungen gerecht werden würde. Viele würden dann nämlich gar nicht mehr durchsehen und vor lauter "wie schreibe ich Code für große Programme und Organisationen" wäre das eigentliche Anliegen des Wikibeitrags unsichtbar geworden.

        100%ige Sicherheit ist eine Illusion, aber (in)formelle Überprüfbarkeit ist die Mindestvoraussetzung, die wir schaffen müssen.

        Du wolltest an anderer Stelle eine automatisierte Überprüfung. Aber irgendwie erscheint es mir höchst zweifelhaft, ein zuvor übersichtliches und überschaubares Programm zum Zwecke des Ermöglichens der automatisierten Überprüfung aufzublähen. Denn die alte Regel, wonach die Wahrscheinlichkeit von Fehlern mit der Kompliziertheit eines System ansteigt, die von der zweiten Regel, wonach die Wahrscheinlichkeit von unentdeckten Fehlern mit der Anzahl der Fehler überhaupt ansteigt, begleitet wird, wirkt doch gerade in einem solchen Fall.

      2. Lieber 1unitedpower,

        vielen Dank für Deine sachliche Antwort.

        Das sehe ich anders, die Forensuche belegt, dass der Artikel immer wieder in der Kritik stand und für große Verunsicherung bei der Leserschaft gesorgt hat.

        Es sei Dir zugestanden, dass Du das anders siehst. Prinzipiell will ich auch nicht in Abrede stellen, dass der Artikel hier in diesem Forum öfters auch von Dir kritisiert wurde. Jedoch hätte ich mir gewünscht, dass entweder aus einer bestehenden Kritik heraus ein Ultimatum zur Löschung folgt, oder dass, falls die Diskussion bereits ins Archiv gewandert ist, eigens dafür eine neue Kritik mit Ultimatum gestartet würde.

        Vielleicht für die Zukunft, jetzt "isses passiert".

        Der Artikel hat die Bringschuld auf seiner Seite, er sollte nachweisen, dass das dort vermittelte Loginsystem bestimmte Sicherheitsanforderungen erfüllt und nicht umgekehrt.

        Wenn ich mir die Bearbeitungshistorie ansehe, dann wurde offensichtlich bei Bekanntwerden von Mängeln nachgearbeitet. Mehr kann zumindest ich nicht verlangen. Inwiefern ein Artikel in unserem Wiki Deiner Forderung gerecht werden kann, "bestimmte Sicherheitsanforderungen" zu erfüllen, kann ich nicht einschätzen, da mir hierzu schlicht das Wissen und die Erfahrung dazu fehlen. Nach wie vor möchte ich allerdings die Frage stellen, wie hoch man hier die Messlatte für das Wiki wirklich hängen kann und sollte.

        Das Gegenteil ist imho. auch schon zu oft gezeigt worden. Das ist vergleichbar mit einem Autobesitzer, der dafür Sorge tragen muss, dass sein Auto verkehrssicher ist. Deshalb muss es durch den TÜV, besteht es dort nicht, darf das Auto nicht gefahren werden. In der Informationstechnik sind wir glücklicherweise nicht immer auf externe Zertifizierungsstellen angewiesen, wir haben formale Methoden, die es uns erlauben den Sicherheitsnachweis auf nachvollziehbare Weise zu erbringen.

        Vielleicht habe ich die Diskussionen um diesen speziellen Artikel nicht genau genug verfolgt, jedoch sind mir keine Forumshinweise erinnerlich, die mit formalen Methoden sicher belegt hätten, dass der Artikel unzweifelhaft unsichere Vorgehensweisen anböte. Dass die angebotene Vorgehensweise ausreichend sicher sei, konnte er zwar ebenso wenig durch Formalien nachweisen, aber geht das für unser Wiki nicht ein Bisschen zu weit? Wie gesagt: Ich hätte kein Problem damit, wenn es einen formalen Nachweis für eine bestehende Unsicherheit gäbe. Einen formalen Nachweis für die Sicherheit der angebotenen Lösung im Artikel als Bestandteil desselben zu verlangen, halte ich aus meiner Sicht für überzogen!

        Eine aktive Versionsgeschichte ist kein Qualitätsmerkmal.

        Das will ich auch nicht behauptet haben. Es ging mir um menschliche Reaktionen im Kontext von menschlichem Handeln. Wir sind hier alle Menschen und wir frönen hier einem Hobby. Als harsch empfundene Aktionen führen zu einer gewissen Thermik. Das kann manchmal sinnvoll sein, in diesem Falle empfand ich es als vermeidbar. Das sollte auch eine der beiden Quintessenzen meines Postings gewesen sein.

        Einige der Verfechter und Autoren des Artikels haben sich in meinen Augen sowohl fachlich als auch zwischenmenschlich bereits disqualifiziert, um ein derartig sicherheitskritisches Loginsystem technisch und didaktisch zu betreuen.

        Das mit dem Zwischenmenschlichen ist so eine Sache, ja. Aber wie Du ja selbst einräumst, war auf beiden Seiten nicht in allen Fällen optimal reagiert worden. Dass sich jemand durch emotional gefärbtes Schreiben und Handeln immer gleich disqualifizieren muss...! Warum darf niemand hier auch einmal einen schlechten Tag haben?

        Das mit dem Fachlichen ist auch so eine Sache, da unsere Stärken hier ebenso wie unsere Schwächen sehr unterschiedlich verteilt sind. Mir wäre es wichtiger, das Verbindende zu suchen und zu stärken. Würden wir hier alle Reaktionen auf die Goldwaage legen, fachliche wie menschliche, dann hätte unser Wiki keine gedeihliche Zukunft, da dann Fehden und Rechthaberei ausufern würden.

        Den Vorwurf, ich ginge unvermittelt vor, weise ich ebenfalls zurück. Ich hab mich von Anfang an immer wieder an Diskussionen zu dem Artikel beteiligt.

        Es ist und bleibt eine Frage der Wahrnehmung. Dein Handeln hatte eine Vorgeschichte, ja. Aber nicht jeder hatte diese Vorgeschichte vollumfänglich auf dem Radar. Meiner Wahrnehmung nach war die Debatte um die Sicherheitsbedenken zu diesem Artikel eingeschlafen. Irgendwie kamen in der Diskussion keine neuen Impulse. Und dann las ich Dein Posting. Für mich hatte das sehr wohl etwas unvermitteltes.

        Mit der Schärfe meines Tonfalls hast du vermutlich nicht ganz unrecht. Ich versuche zwar einen sachlichen Ton zu bewahren, was mir angesichts der Beleidigungen und obskuren Anschuldigungen (nicht nur in meine Richtung, sondern auch gegen andere Forenteilnehmer und entfernte Kollegen) bestimmt nicht immer leicht fällt und auch nicht immer gelingt.

        Wie ich schon schrieb: Wir sind hier alle nur Menschen. Und Idealisten. Das macht die Sache keineswegs leichter. :-)

        Gut, ich werde allerdings nicht wiederholen, was ich andernorts schon gesagt habe. Zusätzlich sollte das Loginsystem die folgenden Punkte mindestens erfüllen, um damit noch nicht als sicher, aber zumindest als überprüfbar eingestuft werden zu können:

        Und wer führt den formalen Nachweis, dass die Einstufung korrekt ist? Ich kann das nicht, das übersteigt bei weitem meine Fähigkeiten und mein Wissen.

        • Eine klare Trennung zwischen Schnittstellen- und Anwendungscode. Dazu gehört auch eine formale Schnittstellenbeschreibung. PHP bietet dafür ein inzwischen recht robustes Typsystem und gute Testing-Frameworks. Gluecode, der die Schnittstelle mit der Beispielanwendung koppelt, sollte möglichst bündig ausfallen, wenn er zu lang wird, ist das ein Zeichen dafür, dass die Schnittstelle nicht die richtigen Abstraktionen bietet.

        Ich habe gefühlte 37% davon verstanden oder zumindest nachvollziehen können. In meinen Projekten verwende ich PHP ohne jede Art von Framework. Ein Framework kenne ich nur von JavaScript, wo ich mit jQuery gewisse Erfahrungen machen konnte. Allerdings kenne ich das Einbinden von Klassen in PHP. Mit einer eingebundenen Klasse kann man dann Funktionalitäten nutzen, die man sich nicht selbst geschrieben hat.

        Die "klare Trennung zwischen Schnittstellen- und Anwendungscode" halte ich auch für eine Quadratur des Kreises. Ideen wie Smarty verwenden PHP in HTML, um PHP als Template-Sprache zu benutzen. In meinen Projekten verwende ich HTML-Dokumente, die von gewissen Methoden mit gewissen Inhalten befüllt werden. Wie sollte man also trennen? Und das Ganze bitte im Kontext eines Tutorials für Anfänger und Fortgeschrittene - nicht für Profis! Profis sind ohnehin in gewissen Projekten eingebunden, die alle ihre eigenen Vorschriften und Vorgehensweisen haben.

        • Das System muss auf seine Kernaufgaben beschränkt werden. Schichten, die bspw. nur der Abwärtskompatibilität dienen, sollten sich nicht darin wiederfinden.

        Aha... Schichten... Meinst Du Code, der das Fehlen von Funktionalitäten kompensiert, wenn veraltete PHP-Versionen eingesetzt werden? Hmm. Vielleicht kann man ja für den Artikel eine Klasse schreiben, zu der man eine Zusatzklasse oder zumindest ein kleines Script irgendeiner Art laden kann, damit dann Kompatibilität bereitstellt wird, wenn der Bedarf entsteht?

        • Es muss eine Modularisierung stattfinden, die die große Aufgabe "Loginsystem" seziert, in kleine Unteraufgaben zerteilt und klare Verantwortlichkeiten schafft. Aktuell ist die Autorisierung eng gekoppelt mit der Ausgabelogik. Das stört beim Testen und verkompliziert unnötigerweise das mentale Modell des Codes.

        Da wären wir dann wieder bei einer Klasse. Entsprechende Methoden für entsprechende Aufgaben. Schon klar.

        • Der Kontrollfluss muss vorhersehbar sein, mit eindeutigen Eintritts- und Austrittspunkten. D.h. insbesondere keine exit- oder die-Statements in der Schnittstellen-Implementierung.

        Wie machst Du das denn, wenn Du auf einen bestimmten Request nur Header-Daten senden willst, aber garantiert keine Nutzdaten? Ist nach den header()-Aufrufen ein exit nicht gut?

        • Der Datenfluss muss definiert sein, möglichst unidirektional mit starker Präferenz für Lokalität gegenüber globalem Zustand und einem verantwortungsbewusstem Einsatz von Nebenwirkungen.

        Das habe ich nun überhaupt nicht mehr verstanden. Meinst Du, dass alles in einer Klasse mit lokalen Variablen und Eigenschaften der Klasse selbst abgebildet werden soll, ohne sich auf (super-)globale Variablen zu verlassen?

        • Der Code sollte zwecks Lesbarkeit modernen Codingstandards folgen, für PHP ist das am häufigsten der PSR-Standard. Code-Linter können eine reihe an Codesmells entdecken und die Einhaltung gesetzter Standards verifizieren.

        Was sind "moderne Codingstandards"? Vom "PSR-Standard" habe ich noch nichts gelesen. Werde ich nachholen. Was ein Linter ist, kenne ich von jsLint. "Codesmells" habe ich noch nie vorher gelesen. Kann Code einen Geruch haben? Ist das grundsätzlich etwas anderes als "Flavours"? Ja, und "gesetzte Standards" sind dann andere, als die "modernen Standards"?

        100%ige Sicherheit ist eine Illusion, aber (in)formelle Überprüfbarkeit ist die Mindestvoraussetzung, die wir schaffen müssen. Können wir das nicht leisten, dann hat unser Wiki an dieser Stelle besser eine Lücke.

        Da verlangst Du mehr, als ich in der Lage bin. Zwar könnte ich mir überlegen, wie ich eine Klasse schreibe, die einen Login anhand einer Datenlage (Flatfile oder DB-Zugriff) prüfen und im Erfolgsfall eine Session mit passenden Daten bestücken kann, aber automatisierte Tests (Unit-Tests) oder gar formale Überprüfungen auf Sicherheit kann ich nicht leisten. Wie macht man das?

        Liebe Grüße,

        Felix Riesterer.

        Folgende Nachrichten verweisen auf diesen Beitrag:

        1. Der Artikel hat die Bringschuld auf seiner Seite, er sollte nachweisen, dass das dort vermittelte Loginsystem bestimmte Sicherheitsanforderungen erfüllt und nicht umgekehrt.

          Wenn ich mir die Bearbeitungshistorie ansehe, dann wurde offensichtlich bei Bekanntwerden von Mängeln nachgearbeitet. Mehr kann zumindest ich nicht verlangen. Inwiefern ein Artikel in unserem Wiki Deiner Forderung gerecht werden kann, "bestimmte Sicherheitsanforderungen" zu erfüllen, kann ich nicht einschätzen, da mir hierzu schlicht das Wissen und die Erfahrung dazu fehlen. Nach wie vor möchte ich allerdings die Frage stellen, wie hoch man hier die Messlatte für das Wiki wirklich hängen kann und sollte.

          Das ist eine wichtige Kernfrage, die ich gerne vertiefen möchte. Ich verstehe uns als Erstanlaufstelle für angehende EntwicklerInnen, für SchülerInnen, Azubis, Studierende und für den oder die gemeine Hobby- und Amateur-ProgrammiererIn. Wir bekennen uns also ganz klar zu einer unerfahrenen Zielgruppe. Auf der anderen Seite ist Softwaresicherheit ein hochkompliziertes und heikles Thema. Wir können, wie du auch schon sagtest, das Thema nicht erschöpfend in einem Wiki-Artikel ausarbeiten. Die Frage bleibt also, was möchten wir dem Leser mit auf den Weg geben? Für mich sind das die folgenden Schwerpunkte.

          • Wir müssen die Komplexität des Themas eindringlich vermitteln. Ein Loginsystem spielt in einer anderen Liga als ein Tic-Tac-Toe-Spiel. Wir sollten also gleich zu Beginn mit der unbequemen Wahrheit rausrücken, dass der oder die LeserIn am Ende des Artikels unmöglich in der Lage sein wird, ein einsatzbereites Loginsystem zu entwickeln. Es braucht Jahre, dass nötige Know-How dafür anzuhäufen. Wir können aber Alternativen benennen, und das heißt: nicht selber zu machen, sondern ein bereits erprobtes System einzusetzen. Das bringt mich zum nächsten Punkt:
          • Es ist wichtig greifbare und objektiv erfassbare Maßstäbe zu benennen, um die Indizien sicherer bzw. unsicherer Software zu erkennen. Sicherheit ist keine Sache blinden Vertrauens, auch nicht blinden Selbstvertrauens. Man muss sich unabdingbar Vergewissheit verschaffen, dass das Programm das Richtige tut. Joseph Weizenbaum, ehem. MIT-Professor, hat das mal in schöne Worte gefasst:

          A computer will do what you tell it to do, but that may be much different from what you had in mind.

          Vielleicht habe ich die Diskussionen um diesen speziellen Artikel nicht genau genug verfolgt, jedoch sind mir keine Forumshinweise erinnerlich, die mit formalen Methoden sicher belegt hätten, dass der Artikel unzweifelhaft unsichere Vorgehensweisen anböte.

          So funktionieren formale Verfahren auch nicht. Andersherum wird ein Schuh draus: Tests können die Absenz von bestimmten Fehlern nachweisen. Eine Standardvorgehensweise ist zum Beispiel, beim Bekanntwerden eines Bugs, erst einen Test zu entwickeln, der in der betroffenen Software-Version fehlschlägt. Anschließend wird ein Patch entwickelt, welches den Testfall löst. Die Zend-EntwicklerInnen machen das sehr diszipliniert.

          Ich hätte kein Problem damit, wenn es einen formalen Nachweis für eine bestehende Unsicherheit gäbe. Einen formalen Nachweis für die Sicherheit der angebotenen Lösung im Artikel als Bestandteil desselben zu verlangen, halte ich aus meiner Sicht für überzogen!

          Es ist an dieser Stelle auch nicht sinnvoll, dem Leser zu vermitteln, wie er selber solche Formalismen entwickelt. Wichtiger ist es, die Bedeutung dieser Art technischer Verifikation zu betonen und ihn darauf hinzuweisen, dass gebräuchliche Authentifizierungssysteme starken Gebrauch davon machen. Von da aus sollte er zu der Selbsteinsicht gelangen, dass Selbermachen keine Option ist.

          Und wer führt den formalen Nachweis, dass die Einstufung korrekt ist? Ich kann das nicht, das übersteigt bei weitem meine Fähigkeiten und mein Wissen.

          DAS! Das ist genau die Einsicht, zu der ein Leser des Wiki-Artikels gelangen sollte. Damit möchte ich auch die zwischenmenschliche Debatte hier abschließen: Wir müssen eine Kultur etablieren, in der es nichts Schlimmes ist, sich zu fehlenden Fachkenntnissen zu bekennen und Scheitern nicht als etwas rein Negatives empfunden wird. Ich gestehe auch ein, mit meinem Handeln zu Beginn, nicht uneingeschränkt in diesem Sinne gearbeitet zu haben. Das nehme ich aus dieser Diskussion mit und hoffe, dass sich diese Eskalation nicht wiederholen wird.

          • Eine klare Trennung zwischen Schnittstellen- und Anwendungscode. Dazu gehört auch eine formale Schnittstellenbeschreibung. PHP bietet dafür ein inzwischen recht robustes Typsystem und gute Testing-Frameworks. Gluecode, der die Schnittstelle mit der Beispielanwendung koppelt, sollte möglichst bündig ausfallen, wenn er zu lang wird, ist das ein Zeichen dafür, dass die Schnittstelle nicht die richtigen Abstraktionen bietet.

          Ich habe gefühlte 37% davon verstanden oder zumindest nachvollziehen können. In meinen Projekten verwende ich PHP ohne jede Art von Framework. Ein Framework kenne ich nur von JavaScript, wo ich mit jQuery gewisse Erfahrungen machen konnte. Allerdings kenne ich das Einbinden von Klassen in PHP. Mit einer eingebundenen Klasse kann man dann Funktionalitäten nutzen, die man sich nicht selbst geschrieben hat.

          Ein Testing-Framework ist mit jQuery nicht vergleichbar. Es ist ein Entwickler-Werkzeug, ein Meta-Programm, um die Entwicklung von Programmen sicherer zu gestalten und dem Entwickler mehr Gewissheit über die Qualität seines Produkts zu verschaffen. Ein Software-Test stellt eine Behauptung über ein Programm, indem es bestimmte Problem-Instanzen mit bekannten Lösungen definiert. Wird der Test ausgeführt, startet er das Programm mit den bekannten Problem-Instanzen als Eingabe und überprüft, ob die Ausgabe den erwarteten Lösungen entspricht. Nehmen wir zum Beispiel an, dass wir eine squareRoot-Funktion in PHP implementieren wollten:

          // squareRoot.php function squareRoot($x) { return sqrt($x); }

          Nun, wollen wir wissen, ob die Funktion das tut, was wir von ihr erwarten. Wir definieren dafür Unit-Tests:

          // test.php require "squareRoot.php"; $in = 4; $expected = [2,-2]; $actual = squareRoot($in); if ($actual !== $expected) { echo "Test fehlgeschagen. Erwarteter Wert squareRoot($in) entspricht nicht $expected"; } else { echo "Test bestanden: squareRoot($in) entspricht $expected"; }

          Dieser Test schlägt bereits fehl, weil wir bei der Implementierung vergessen haben, dass die Wurzel einer positiven Zahl, mehrere Lösungen hat. Wir können die Implementierung also anpassen:

          function ($x) { return [sqrt($x), -sqrt($x)]; }

          Damit sollte dieser Test nun bestanden werden. Testen wir weiter? Was ist, wenn wir eine negative Zahl als Eingabe übergeben. Die Funktion sollte uns dann eine komplexe Zahl als Lösung liefern, für -1 zum Beispiel die komplexe Zahl i. Angenommen, wir haben eine Datei "ComplexNumber.php", die uns Basis-Funktionalität für das Rechnen mit komplexen Zahlen zur Verfügung stellt, dann können den folgenden Test schreiben:

          // test.php require "squareRoot.php"; require "ComplexNumber.php"; $in = -1; $expected = \ComplexNumber\I; $actual = squareRoot($in); if ($actual !== $expected) { echo "Test fehlgeschagen. Erwarteter Wert squareRoot($in) entspricht nicht $expected"; } else { echo "Test bestanden: squareRoot($in) entspricht $expected"; }

          Der Test wird wieder fehlschlagen. Wir können nun wieder hingehen und die Implementierung entsprechend anpassen. Testing-Frameworks bieten uns konventionelle Methoden, um Testfälle zu definieren und um das Testen in unseren Arbeitsfluss zu integrieren. Viele agile Entwicklerteams nutzen Continuous-Integration-Serivces, um sich Push-Benachrichtigungen einzuholen, falls ein Testcase plötzlich fehlschlägt.

          Die "klare Trennung zwischen Schnittstellen- und Anwendungscode" halte ich auch für eine Quadratur des Kreises. Ideen wie Smarty verwenden PHP in HTML, um PHP als Template-Sprache zu benutzen. In meinen Projekten verwende ich HTML-Dokumente, die von gewissen Methoden mit gewissen Inhalten befüllt werden. Wie sollte man also trennen? Und das Ganze bitte im Kontext eines Tutorials für Anfänger und Fortgeschrittene - nicht für Profis! Profis sind ohnehin in gewissen Projekten eingebunden, die alle ihre eigenen Vorschriften und Vorgehensweisen haben.

          • Das System muss auf seine Kernaufgaben beschränkt werden. Schichten, die bspw. nur der Abwärtskompatibilität dienen, sollten sich nicht darin wiederfinden.

          Aha... Schichten... Meinst Du Code, der das Fehlen von Funktionalitäten kompensiert, wenn veraltete PHP-Versionen eingesetzt werden?

          Genau das meinte ich mit Kompatibilitätsschicht. Die Trennung ist zunächst mal konzeptionell, aber spiegelt sich häufig auch physisch in der Organisation des Codes wieder. Ich meine hier inbesondere die konzeptionelle Unterscheidung von Code nach seinen Aufgabenbereichen. Eine veraltete PHP-Version, die keine Sicherheitsupdates mehr erhält, darf und kann auch gar nicht die Grundlage für ein sicheres Software-System sein. Die Kette ist nur so stark wie ihr schwächstes Glied. Sichere Software-Systeme müssen deshalb ständig überwachen, ob all ihre Abhängigkeiten noch aktuell sind. Dafür benutzt man Paket-Verwaltungsysteme. Mit Composer kann man zum Beispiel mit composer outdated herausfinden, für welche Pakete Updates existieren.

          Ups Schreiblimit erreicht, für den zweiten Teil meiner Antwort hier entlang, bitte.

          Folgende Nachrichten verweisen auf diesen Beitrag:

          1. Hallo 1unitedpower,

            // squareRoot.php function squareRoot($x) { return sqrt($x); }

            Nun, wollen wir wissen, ob die Funktion das tut, was wir von ihr erwarten. Wir definieren dafür Unit-Tests:

            // test.php require "squareRoot.php"; $in = 4; $expected = [2,-2];

            Dieser Test schlägt bereits fehl, weil wir bei der Implementierung vergessen haben, dass die Wurzel einer positiven Zahl, mehrere Lösungen hat.

            Nein, die Quadratwurzel einer Zahl x ist diejenige nicht negative Zahl, die mit sich selbst multipliziert x ergibt.

            function ($x) { return [sqrt($x), -sqrt($x)]; }

            Die Gleichung x² = a hat für postives a zwei Lösungen, nämlich die von dir oben genannten. sqrt(x) ist dabei die positive Zahl, die man mit plus bzw. minus eins multiplizieren muss, um die beiden Lösungen zu erhalten.

            Bis demnächst
            Matthias

            -- Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.

            Folgende Nachrichten verweisen auf diesen Beitrag:

            1. Hallo Matthias Apsel,

              und auch \sqrt[3]{-8} ist nicht definiert. Vielmehr gilt

              \sqrt[n]{-x}; x > 0\\ \begin{align} \sqrt[n]{x} & = \sqrt[n]{(-1) \cdot x}\\ & = \sqrt[n]{-1} \cdot \sqrt[n]{x}\\ & = \sqrt[n]{(-1)^n} \cdot \sqrt[n]{x}\\ & = -1 \cdot \sqrt[n]{x}\\ \end{align}

              Die Tatsache, dass \sqrt[n]{(-1)^n} = -1 sowohl für gerades als auch für ungerades n gilt, zeigt dass Dilemma.

              Einerseits wäre dann

              \sqrt[2]{(-1)^2} = \sqrt[2]{1} = 1

              aber eben auch

              \sqrt[2]{(-1)^2} = (-1)^{2/2} = (-1)^1 = -1

              Bis demnächst
              Matthias

              -- Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
          2. Tach!

            Noch etwas ergänzende Information zu Tests und Test-Driven-Design (TDD): Wenn man es gemäß der Philosophie macht, schreibt man sich zunächst für einen oder mehrere Anwendungsfälle einen oder mehrere Tests. Das zu testende Objekt (im allgemeinen Sinne, nicht nur OOP) existiert zu dem Zeitpunkt lediglich als Dummy. Das heißt, seine Schnittstellen sind gemäß der Planung ausformuliert, aber der Körper fehlt. Die Tests prüfen typische Situationen und müssen zunächst wegen der fehlenden Geschäftslogik fehlschlagen, auch als Nachweis dass beim Fehlschlagen der Test sich die rote Lampe anschalten kann. Nun fügt man seine Geschäftslogik hinzu und die Tests müssen grün werden. Wenn man ganz gut ist, hat man bereits jetzt die möglichen Grenzfälle und die Fälle, in denen der Testkandidat kein positives Ergebnis liefern kann, im Kopf und schreibt dafür entsprechende Tests. Damit ist der Schritt erstmal abgeschlossen.

            Im weiteren Verlauf der Entwicklungstätigkeit stellt sich nun beispielsweise heraus, dass der Testkandidat geändert werden muss. Gründe können unter anderem sein, dass die Geschwindigkeit zu wünschen übrig lässt oder dass der Code ein Refactoring benötigt. Es geht grad nicht darum, dass die Funktionalität aufgrund geänderter Anforderungen geändert werden muss, also lediglich um eine Überarbeitung mit beizubehaltender Funktionalität. Die Tests, die man nun bereits hat, stellen sicher, dass nach außen hin der Testkandidat weiterhin auf dieselbe Art und Weise funktioniert. Bei Abweichungen würden sonst Tests fehlschlagen. Ohne TDD müsste man die Funktionalität zu Fuß prüfen und darf dabei keinen der Testfälle vergessen, um die gleiche Qualität sicherzustellen.

            Natürlich kommt in das ganze Spiel auch noch der Faktor Mensch und das Tellerrandproblem. Nicht immer gelingt es demjenigen, der die Testbedingungen formulieren sollte (Vergangenheit, nicht Konjunktiv), alle möglichen Fälle zu bedenken. So stellt sich mitunter erst im Betrieb heraus, dass es unter bestimmten Umständen zu Fehlfunktionen kommt. Bei TDD schreibt man sich nun zunächst neue Tests für ebendiesen Fehler und korrigiert anschließend den Testkandidaten. Am Ende des Tages müssen alle Tests korrekt durchlaufen, und es ist damit sichergestellt, dass durch die Korrektur nicht an anderer Stelle etwas kaputtgemacht wurde, was man nicht bemerkt hat. Der Fehler stellt sich ja nicht selten erst viel später heraus, so dass man vom Projekt schon wieder viel vergessen hat und garantiert nicht mehr alle möglichen Testfälle im Kopf behalten hat, um sie erneut durchspielen zu können.

            Der Aufwand beim TDD ist zunächst enorm, noch viel größer als der Unterschied zwischen Schön-Wetter-Programmierung und robuster Programmierung mit Reagieren auf Fehlerbedingungen. Das Ergebnis ist jedoch auch eine Qualität, die man jederzeit, vor allem nach jeder Änderung, vollständig nachprüfen/nachweisen kann - natürlich nun in Abhängigkeit von der Qualität der Tests. Nebenbei hat man nun auch eine Art Dokumentation. Die Testfälle dokumentieren, welche Ergebnisse unter welchen Umständen zu erwarten sind. Wenn man sich beim Benennen der Testfälle Mühe gibt, bekommt man sogar leicht lesbare Form hin. Einige Test-Frameworks unterstützen das sogar noch, so dass sich auch der Code nacher eher wie menschliche Sprache liest. Beispielsweise (angelehnt an Tests im AngularJs-Tutorial):

            it('should result in 42 when doing things', function() { var result = testCandidate.doThings(); expect(result).toBe(42); });

            Abschließend sei noch erwähnt, dass TDD auch nicht die Antwort auf alle Probleme ist. So testet man üblicherweise nicht gegen externe Systeme. Diese generell zu überwachen ist Aufgabe von Monitoring-Systeme. Eine Datenbankabfrage in der Entwicklungsumgebung zu testen hat auch wenig Aussagekraft auf die Produktivumgebung. Die Interaktion zwischen Systemen ist auch nicht mehr Aufgabe von Unittests sondern von Integrationstests. Externe Systeme mit Mock-ups (Attrappen) nachzustellen, ist nicht einfach und fehleranfällg, weil man das Verhalten exakt nachbilden müsste.

            dedlfix.

        2. Hmm. Vielleicht kann man ja für den Artikel eine Klasse schreiben, zu der man eine Zusatzklasse oder zumindest ein kleines Script irgendeiner Art laden kann, damit dann Kompatibilität bereitstellt wird, wenn der Bedarf entsteht?

          Nein, Abwärtskompatibilität im Kontext von Software-Sicherheit muss mit ganz besonderer Behutsamkeit behandelt werden. Wenn man nicht in der Lage ist, das veraltete System selber weiter zu warten, sollte man es auf keinen Fall weiter einsetzen. Stattdessen sollte man in ein ständig aktuelles System investieren. Das ist unter Garantie die sehr viel einfachere und günstigere Lösung.

          • Der Kontrollfluss muss vorhersehbar sein, mit eindeutigen Eintritts- und Austrittspunkten. D.h. insbesondere keine exit- oder die-Statements in der Schnittstellen-Implementierung.

          Wie machst Du das denn, wenn Du auf einen bestimmten Request nur Header-Daten senden willst, aber garantiert keine Nutzdaten? Ist nach den header()-Aufrufen ein exit nicht gut?

          Nein, nicht gut. Das garantiert dir zwar, dass nach dem exit-Statement keine Ausgabe mehr stattfinden kann, aber nicht, dass zuvor keine Ausgbabe stattgefunden hat. Darüber hinaus beendet ein exit die Ausführung von jeglichem Code, nicht nur von Solchem, der mit der Ausgabe zusammenhängt. Genau deshalb ist ein vorhersehbarer Kontrollfluss ja so wichtig. Bezugnehmend auf dein Beispiel, wird es eine Stelle im Code geben, da hat noch keine Ausgabe stattgefunden und da weißt du schon, es soll auch zu keine Ausgabe kommen. An dieser Stelle musst du den Kontrollfluss so umleiten, dass keine Ausgabe erzeugt wird, aber andere Funktionen nicht betroffen werden. Wenn man Gewissheit haben will, dann bietet sich wieder Unit-Test an.

          • Der Datenfluss muss definiert sein, möglichst unidirektional mit starker Präferenz für Lokalität gegenüber globalem Zustand und einem verantwortungsbewusstem Einsatz von Nebenwirkungen.

          Das habe ich nun überhaupt nicht mehr verstanden. Meinst Du, dass alles in einer Klasse mit lokalen Variablen und Eigenschaften der Klasse selbst abgebildet werden soll, ohne sich auf (super-)globale Variablen zu verlassen?

          Ich dechiffrier das mal: Unidirektional heißt, dass eine neue Variable möglichst nur von vorherigen Variablen abhängt und das die Änderung einer Variablen nicht dazu führt, dass an anderen Stellen Variablen erneut synchronisiert werden müssen. Lokalität bedeutet, dass der Geltungsbereich von Variablen so klein wie möglich, so groß wie gewählt wird. Große Geltungsbereiche benötigen viel gedanklichen Overhead beim Lesen und Schreiben des Codes. Nebenwirkungen sind Aktionen, bei denen der Programmfluss synchronisiert werden muss. Das heißt, der Entwickler wird gezwungen eine Aussage über die konkreten Ablauf seines Programms zu treffen. Die header-Funktion ist ein gutes Fallbeispiel dafür. Wer kennt nicht die Fehlermeldung "Headers already sent...". Das ist ein bekannter Synchronisierungs-Fehler.

          • Der Code sollte zwecks Lesbarkeit modernen Codingstandards folgen, für PHP ist das am häufigsten der PSR-Standard. Code-Linter können eine reihe an Codesmells entdecken und die Einhaltung gesetzter Standards verifizieren.

          Was sind "moderne Codingstandards"?

          Das sind Richtlinien, die dafür sorgen, dass Code lesbar und wartbar bleibt. Das läuft auf verschiedenen Ebenen ab: Auf der niedrigsten Ebene schreibt ein Codingstandard vor, wie der Code syntaktisch zu entwerfen ist. Soll mit Leerzeichen oder mit Tabulatoren eingerückt werden, wann kommt eine Leerzeile, soll die geschweifte Klammer ans Ende der Zeile oder an den Anfang der nächsten Zeile? Auf höheren Ebenen, werden dann auch Namenskonventionen und der Umgang mit Exceptions etc. festgelegt.

          Vom "PSR-Standard" habe ich noch nichts gelesen. Werde ich nachholen. Was ein Linter ist, kenne ich von jsLint. "Codesmells" habe ich noch nie vorher gelesen. Kann Code einen Geruch haben? Ist das grundsätzlich etwas anderes als "Flavours"? Ja, und "gesetzte Standards" sind dann andere, als die "modernen Standards"?

          Ein "gesetzter" Standard meine einfach einen Standard, den ich mir zum Ziel setze. Mit Codesmells bezeichnet man häufig beobachtete Programmiermuster, die dafür bekannt sind, dass sie Software-Fehler einführen oder für Verwirrung unter Entwicklern sorgen.

          100%ige Sicherheit ist eine Illusion, aber (in)formelle Überprüfbarkeit ist die Mindestvoraussetzung, die wir schaffen müssen. Können wir das nicht leisten, dann hat unser Wiki an dieser Stelle besser eine Lücke.

          Da verlangst Du mehr, als ich in der Lage bin. Zwar könnte ich mir überlegen, wie ich eine Klasse schreibe, die einen Login anhand einer Datenlage (Flatfile oder DB-Zugriff) prüfen und im Erfolgsfall eine Session mit passenden Daten bestücken kann, aber automatisierte Tests (Unit-Tests) oder gar formale Überprüfungen auf Sicherheit kann ich nicht leisten. Wie macht man das?

          Kurze Antwort: Hands-on: https://phpunit.de/getting-started.html

          Folgende Nachrichten verweisen auf diesen Beitrag:

          1. Lieber 1unitedpower,

            danke für Deine sehr ausführliche Antwort. Da muss ich eine Weil dran verdauen.

            Liebe Grüße,

            Felix Riesterer.

            1. Ich stelle wie folgt fest:

              Statt die konkret behaupteten "bestehenden Sicherheitsmängel" darzulegen kamen wieder nur theoretische Überlegungen und fragwürdige Beispiele, welche mit dem konkretem Skript rein gar nichts nichts zu tun haben.

              Wenn ich lese, dass ein PHP-Skript die zugrunde legende PHP-Version überprüfen solle, dann komme ich zu dem Ergebnis, dass wenn man das als richtig erachten wolle, dass man dann aber auch:

              • nach PHP auch das Betriebssystem,
              • nach dem OS auch die BIOS-Version der Hardware,
              • sämtliche parallel installierte Software,
              • ... was immer auch Einfluss nehmen kann ... prüfen muss.

              Mit allem Verlaub dürfte das bei einem Skript, welches den Job hat, ein Login durchzuführen und ein gemeinsames Geheimnis zu teilen sowie also eine Erkennung des Benutzers und seiner Rechte (Gruppen) zu ermöglichen, ein ganz sehr höflich formuliertes "wenig" der Aufgabe vorbei gehen. Derlei gehört allenfalls in ein Setup-Skript, welches im Wiki-Artikel aber nicht beschrieben wurde.

              Die Formulierung "bestehende Sicherheitsmängel" erzeugt die Vermutung, dass ein konkreter Angriff möglich ist. Diesen hat @1unitedpower auch 10 Tage nach seiner Behauptung nicht beschrieben, was die Vermutung erzeugt, dass er also keinen gefunden hat.

              1. Der weitaus größte Teil der von @1unitedpower vorgelegten Überlegungen mag zudem sinnvoll sein, wenn ein großes Programm von mehreren geschrieben wird - das als "einzig richtig" vorgestellte Vorgehen wird aber genau dann immer unsinniger wenn das Programm wie vorliegend ein kleines Skript ist. Und zwar weil dieses Vorgehen selbst zu einer dann nicht unwesentlichen Vermehrung des Codes führt - und zwar ohne jeden Gewinn an Übersichtlichkeit und Sicherheit, auf Grund der Codevermehrung erhöht sich dann sogar die Wahrscheinlichkeit von Fehlern.

                Das ist wie wenn man ein jpeg zippt: Dar Ergebnis ist nicht kleiner, sondern größer. Hauptsache die Daten wurden komprimiert.

                Das Unit-Tests - wie von mir behauptet - nur so viel taugen wie deren Anwendung kann man ja an der Diskussion über Wurzeln und Quadrate sehr schön sehen: @1unitedpower will als Wurzel alle Zahlen ermitteln, deren Quadrat zur Ausgangszahl führt - als Wurzel definiert ist tatsächlich nur die nicht negative.

                Auf deutsch: Sein Unit-Test schlägt fehl, weil er falsch definiert ist: -2 ist eben keine gültige Wurzel von 4.

                Wenn also erfolgreiche Unit-Tests nicht per die Sicherheit eines Programms begründen können, dann kann deren Absence nicht als Begründung für die Behauptung herhalten, dieses habe Sicherheitsmängel. Das ist so falsch wie es nur falsch sein kann. Zumal diese gerade auch wieder nur dann sinnvoll werden, wenn ein ausreichend großes Programm von mehreren geschrieben wird. Was hier nicht vorliegt.

              2. Hallo Google weiß alles,

                Ich stelle wie folgt fest:

                Statt die konkret behaupteten "bestehenden Sicherheitsmängel" darzulegen kamen wieder nur theoretische Überlegungen

                Auch du bist einige Antworten schuldig geblieben. Antworten, die mMn essentiell für die Zukunft des Artikels sind.

                Bis demnächst
                Matthias

                -- Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
                1. Auch du bist einige Antworten schuldig geblieben.

                  Die habe ich mal rausgesucht:

                  • Kannst du fraglichen Artikel uneingeschränkt zur Umsetzung eines Login-Systems empfehlen?

                  Das beginnt doch schon bei der Frage nach dem "Wem". "Uneingeschränkt" kann man gar nichts empfehlen. Nicht mal ein Eis zu essen.

                  • Setzt du ein Login-System, was identisch zu dem im fraglichen Artikel ist, für deine Projekte ein?

                  Was hat das mit der Ausgangsfrage zu tun? Die Antwort ist: Derzeit (noch) nicht "produktiv". Im Gegensatz zu seinem htaccess-Dingens.

                  • Sollte man Dinge wie ein Login-System oder auch ein Verschlüsselungsverfahren selbst stricken / einen Anfänger selbst stricken lassen?

                  Kommt darauf an, wie "blutig" der Anfänger ist. Wer zum ersten Mal "was mit Login" macht ist in dieser Hinsicht ein Anfänger. Und wir sehen, dass hier Fragende aufschlagen, die uralten Code vorstellen, der noch MD5 als Algorithmus benutzt. Will man denen einen besseren Weg zeigen? Offenbar nicht - und das ist noch schlechter. Es ist auch schlechter in einer solchen Frage den Fragenden auf Grund irgendwelcher äußerst theoretischen Überlegungen mit unausgereiften Antworten im Forum zu bedienen statt ihm einen Artikel im Wiki zu zeigen, der anders als die oft falschen oder unvollständigen Forumsbeiträge wenigstens laufend überprüft und gewartet werden konnte und auch wurde.

                  Antworten, die mMn essentiell für die Zukunft des Artikels sind.

                  Zu irgendeinem Termin vor dem Ende des Universums ist jede Zukunft Vergangenheit.

                  1. Hallo Google weiß alles,

                    • Setzt du ein Login-System, was identisch zu dem im fraglichen Artikel ist, für deine Projekte ein?

                    Was hat das mit der Ausgangsfrage zu tun? Die Antwort ist: Derzeit (noch) nicht "produktiv".

                    Wenn deine Antwort „Natürlich nicht.“ gelautet hätte, würde ich mich schon fragen, warum du so für den Artikel gekämpft hast (Ich habe gelesen, dass du nun zukünftige Aktionen vermeiden möchtest), wenn du ihm selbst nicht über den Weg traust.

                    Wäre deine Antwort: „Selbstverständlich, seit zwei Jahren, 1000 Besucher täglich, keine Probleme aufgetreten“, hätte ich den Artikel sofort wiederhergestellt.

                    Bis demnächst
                    Matthias

                    -- Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
                    1. Wäre deine Antwort: „Selbstverständlich, seit zwei Jahren, 1000 Besucher täglich, keine Probleme aufgetreten“, hätte ich den Artikel sofort wiederhergestellt.

                      Dazu braucht man aber erst mal ein Projekt, welches genau das vorgestellte Login-System erfordert. Erfordert dieses etwas anderes, dann muss man seine Skripte natürlich anpassen...

                      Im Übrigen hätte man ja mal den Autor fragen können. Der hatte doch einen, sogar um eine Verwaltung erweiterten Test online gestellt. Die Bezugnahme auf (Funktions-)Probleme einer frühen - und geänderten - Version bei Strato lässt erkennen, dass er sich mit der konkreten Anwendung durch Dritte auch befasst und das Skript bzw. den Wiki-Eintrag bei neuen Erkenntnissen tatsächlich gepflegt hat.

                      Also auch die Behauptung, der Artikel habe keine Pflege erfahren, erweist sich, wenn man nur einfach mal hinschaut, als unwahr.

                    2. @Matthias Apsel

                      Wäre deine Antwort: „Selbstverständlich, seit zwei Jahren, 1000 Besucher täglich, keine Probleme aufgetreten“, hätte ich den Artikel sofort wiederhergestellt.

                      Zwischenzeitlich hat @1unitedpower mehr oder weniger konkret eingeräumt, dass es die behaupteten "bestehenden Sicherheitsmängel" nicht gibt.

                      Allerdings ist der frühere Autor nach den insoweit falschen Anschuldigungen (Sicherheitslöcher, nicht gekümmert) nunmehr nicht mehr dazu bereit, den Artikel zu pflegen, und will im Hinblick auf die Möglichkeit ähnlich ehrenrühriger Behauptungen auch seinen Name nicht mehr mit SelfHTML in Verbindung gebracht sehen.

                      Andere haben im Hinblick darauf, dass Anfänger bei der Realisierung der Lösung Fehler machen könnten, Bedenken, dass der Artikel nicht mit den Intentionen von SelfHTML übereinstimmt.

                      Die Löschmeldung sollte angemessen aktualisiert werden.

                      1. Hallo Google weiß alles,

                        Die Löschmeldung sollte angemessen aktualisiert werden.

                        Ich stimme zu.

                        Bis demnächst
                        Matthias

                        -- Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
                        1. Die Löschmeldung sollte angemessen aktualisiert werden.

                          Ich stimme zu.

                          Getan.

                          Was 1ups kann kann ich auch.

                          1. Lieber Jörg,

                            Getan.

                            Was 1ups kann kann ich auch.

                            seufz

                            Leider habe ich nicht genügend Zeit übrig, die Grundzüge eines Loginsystems in einem neu aufgelegten Artikel zu beschreiben, sonst könnte ich diesem Wahnsinn endlich ein Ende machen. Vielleicht schaffe ich wenigstens die rudimentären Teile einer Neuauflage, um sie hier zur Diskussion zu stellen, um dann darüber zu beraten, ob man die unrühmliche Meldung mit dieser Neuauflage ersetzen kann.

                            Liebe Grüße,

                            Felix Riesterer.

                            1. Servus!

                              Ich habe den Warnhinweis angepasst und geschützt.

                              Mir wäre sehr daran gelegen, wenn wir unsere Kraft in das Weiterentwickeln des Wiki, z.B bei einer Neufassung des Artikels, stecken würden, anstelle uns in Edit Wars und gegenseitigen Beschuldigungen zu verzetteln.

                              Herzliche Grüße

                              Matthias Scharwies

                              -- Es gibt viel zu tun - packen wir's an: ToDo-Liste gewünschte Seiten
                              1. Ich habe den Warnhinweis angepasst und geschützt.

                                Ich zitiere mal Deinen Warnhinweis:

                                Der ursprüngliche Artikel Sessionbasiertes Loginsystem

                                Dort (gleich am Anfang und als ersten Link) finde ich, genau wie die Anfänger (bei denen Ihr ja angeblich Angst habt, dass die was falsches abschreiben), folgende Katastrophe:

                                $username = $_POST['username']; $passwort = $_POST['passwort']; if ($username == 'benjamin' && $passwort == 'geheim') {

                                Ich gebe mal den Hinweis, das die Löschung mit "präsenten Sicherheitsproblemen" begründet wurde, Auch die aktuelle Fassung enthält "Über die Jahre sind allerdings diverse Sicherheitslücken im System aufgefallen, teilweise sind sie danach geschlossen worden." - also erneut die mangels Nachweises einer bestehenden Lücke als unwahr geltende Behauptung, dass ungeschlossene Sicherheitslücken enthalten seien.

                                Mit allem Verlaub erscheint es mir mehr als nur "unpassend" gerade in diesem Kontext einen Link zu präsentieren, der dann zu einer Quelle führt, in welcher

                                • das Passwort gleich mal im KLARTEXT gespeichert wird,
                                • Programm und Daten vermischt werden.

                                Ohne die Sperrung hätte ich das als Satire eines Scherzboldes verstehen können. So aber gilt mit allem Verlaub:

                                Macht einfach weiter, denn Ihr macht ja immer alles richtig. Auch das "Scheiße bauen"!

                                Die Anzahl der Fliegen, die da meinen, dass Scheiße gut schmeckt, halte ich allenfalls für bezeichnend - und zwar für den Zustand der SelfHTML-Community.

                                1. Servus!

                                  Ich habe den Warnhinweis angepasst und geschützt.

                                  Ich zitiere mal Deinen Warnhinweis:

                                  Der ursprüngliche Artikel Sessionbasiertes Loginsystem

                                  Dort finde ich folgende Katastrophe:

                                  ...

                                  Mit allem Verlaub erscheint es mir mehr als nur unpassend gerade in diesem Kontext einen Link zu präsentieren, der dann zu einer Quelle führt, in welcher

                                  • das Passwort gleich mal im KLARTEXT gespeichert wird,
                                  • Programm und Daten vermischt werden.

                                  Auch dieser Artikel soll nicht als Beispiel verwendet werden, sondern es soll nur aufgezeigt werden, dass es schon einen Vorläufer gab, der ja auch depubliziert wurde.

                                  Ohne die Sperrung hätte ich das als Satire eines Scherzboldes verstehen können.

                                  Man kann auch alles falsch verstehen wollen. Schade, Du warst über Jahre eine Bereicherung für's Forum mit vielen guten Tipps. So versuchst Du aber nur jedem das Wort im Munde herunzudrehen.

                                  So aber gilt mit allem Verlaub:

                                  Macht einfach weiter, denn Ihr macht ja immer alles richtig. Auch das "Scheiße bauen"!

                                  Nein, ich habe auch schon eigene Artikel gelöscht, bzw. nach einem Jahr völlig umgeschrieben, ein weiteres Beispiel ist Felix' Tic-Tac-Toe-Tutorial, dass von ihm völlig neu gegliedert wurde.

                                  Herzliche Grüße

                                  Matthias Scharwies

                                  -- Es gibt viel zu tun - packen wir's an: ToDo-Liste gewünschte Seiten
                                  1. Auch dieser Artikel soll nicht als Beispiel verwendet werden, sondern es soll nur aufgezeigt werden, dass es schon einen Vorläufer gab, der ja auch depubliziert wurde.

                                    ... Und nunmehr einen Link von "prominenter" Stelle bekommt, wo gerade den Anfängern genau das gezeigt wird, was diese NICHT tun sollen.

                                    Genau so geht "völlig unüberlegt".

                                    So versuchst Du aber nur jedem das Wort im Munde herunzudrehen.

                                    Die vorherige Fassung der Löschmeldung war a) neutral und b) im Gegensatz zur aktuellen in allen Punkten wahr. Immerhin hatte selbst @1unitedpower eingeräumt, dass seine Löschung in unangemessener Weise erfolgte. Ich weiß jetzt nicht aus welchen Gründen heraus diese geändert werden musste.

                                    Immerhin hatte ja niemand sachliche Argumente dagegen vorgebracht.

                                    Nur damit jeder weiß, worüber wir diskutieren: Du hast Folgendes gelöscht:

                                    An dieser Stelle war in der Vergangenheit eine Anleitung für ein PHP-Loginsystem zu finden. Diese Anleitung wurde zunächst ohne die angemessene vorherige Diskussion von einem Community-Mitglied unter der Behauptung "präsenter Sicherheitsmängel" und ungenügender Pflege gelöscht. Diese Behauptungen haben sich dann aber als "nicht verifizierbar" erwiesen. Allerdings ist der frühere Autor infolge dieses von ihm nicht grundlos als "ungerechtfertigt rufschädlich" empfundenen Vorkommnisses nicht mehr dazu bereit den Artikel zu pflegen und hat selbst angeregt die Löschung auch beim negativen Beweis der ursprünglich behaupteten Gründe beizubehalten.

                                    Andere Community-Mitglieder haben im Hinblick darauf, dass Anfänger bei der Realisierung der Lösung Fehler mit schweren Folgen machen könnten, Bedenken, dass der Artikel nicht mit den Intentionen von SelfHTML übereinstimmt. Deshalb hat sich trotz der Abwesenheit der behaupteten "präsenten Sicherheitsmängel" der allseitige Konsens herausgebildet diese Anleitung nicht weiter zu veröffentlichen.

                                    Ich finde nicht, dass die Löschung mit "Mir wäre sehr daran gelegen, wenn wir unsere Kraft in das Weiterentwickeln des Wiki, z.B bei einer Neufassung des Artikels, stecken würden, anstelle uns in Edit Wars und gegenseitigen Beschuldigungen zu verzetteln." begründen lässt, denn just Deine Fassung enthält ja wieder die unwahre Beschuldigung, dass Sicherheitslücken offen geblieben seien.

                                    Auch so geht "völlig unüberlegt". Aus meiner Sicht zerbricht die Community an Rechtshaberei und Machtspielchen.

                                    Folgende Nachrichten verweisen auf diesen Beitrag:

                                  2. Schade, Du warst über Jahre eine Bereicherung für's Forum mit vielen guten Tipps.

                                    Du meinst @ist weg. Nun ja. Wer seinen Weggang nicht bisher nicht nachvollziehen konnte, der kann es spätestens jetzt, wo die widerlegte und ehrenrührige Beschuldigung nunmehr von einem "Mod" wiederholt und sein brauchbares Zeug mit einem Link zu einem völlig unbrauchbaren, extrem unsicheren Skript ersetzt wurde.

                                    Wobei, um den Teufel zu krönen, auch noch jede Möglichkeit der Entgegnung genommen wurde.

                                    Mir ist das nach dieser Eskalation zu blöd. Ihr habt schon wieder "gewonnen" - denn man kann bestimmte Typen nicht mit Argumenten überzeugen - und wenn die "doofen" die Macht haben, dann üben die diese auch aus.

                              2. Lieber Matthias,

                                Mir wäre sehr daran gelegen, wenn wir unsere Kraft in das Weiterentwickeln des Wiki, z.B bei einer Neufassung des Artikels, stecken würden, anstelle uns in Edit Wars und gegenseitigen Beschuldigungen zu verzetteln.

                                [x] done.

                                Liebe Grüße,

                                Felix Riesterer.

                                1. Servus!

                                  Mir wäre sehr daran gelegen, wenn wir unsere Kraft in das Weiterentwickeln des Wiki, z.B bei einer Neufassung des Artikels, stecken würden, anstelle uns in Edit Wars und gegenseitigen Beschuldigungen zu verzetteln.

                                  [x] done.

                                  Vielen Dank.

                                  Interessant, dass es selbst im Blog schon Artikel zum Passwort-Verschlüsseln gab.

                                  Herzliche Grüße

                                  Matthias Scharwies

                                  -- Es gibt viel zu tun - packen wir's an: ToDo-Liste gewünschte Seiten
                                2. Erst einmal: Dir sollten so mancher hier sehr viel dankbarer sein als er es kann. Das schon, weil Du konstruktiv statt destruktiv - und im vollen Gegensatz zu @1unitedpower: nach bestem Wissen - gehandelt hast.

                                  [x] done.

                                  Nein, nicht. Nicht ganz. Passwörter werden nicht "verschlüsselt", man sollte das Wort nicht benutzen, weil es die Leser verwirrt. Insofern ist auch das Negativ-Beispiel falsch, denn bei der 100-Euro-Wette geht es um einen Versuch einer tatsächlich umkehrbaren Verschlüsselung.

                                  1. Lieber Jörg,

                                    Erst einmal: Dir sollten so mancher hier sehr viel dankbarer sein als er es kann.

                                    Dein Lob tut gut. Vielen Dank dafür.

                                    Passwörter werden nicht "verschlüsselt", man sollte das Wort nicht benutzen, weil es die Leser verwirrt.

                                    Du hast insofern recht, als dass es technisch betrachtet einen Unterschied zwischen Verschlüsselung und Hashing gibt. Erstere ist umkehrbar, zweiteres nicht. Wenn ich Dich richtig verstanden habe, ist nur eine umkehrbare Verarbeitung als Verschlüsselung zu vergleichen.

                                    Insofern ist auch das Negativ-Beispiel falsch, denn bei der 100-Euro-Wette geht es um einen Versuch einer tatsächlich umkehrbaren Verschlüsselung.

                                    Jetzt haben wir das Problem der technisch korrekten Sprache, und des landläufigen Sprachgebrauchs derer, die den technischen Unterschied nicht kennen. Soll der Artikel sich auch wieder an Anfänger richten? Dann wäre der landläufige Sprachgebrauch sinnvoll, wenn auch technisch falsch.

                                    Vielleicht finden wir einen Kompromiss, indem ich zu Anfang den landläufigen Sprachgebrauch als technisch falsch darlege, um im weiteren Verlauf dann den technisch richtigen Sprachgebrauch zu verwenden?

                                    Liebe Grüße,

                                    Felix Riesterer.

                                    1. Vielleicht finden wir einen Kompromiss, indem ich zu Anfang den landläufigen Sprachgebrauch als technisch falsch darlege, um im weiteren Verlauf dann den technisch richtigen Sprachgebrauch zu verwenden?

                                      [x] done (korrigierte Version des Artikels)

                                      Liebe Grüße,

                                      Felix Riesterer.

                                      1. Vorschlag. Ändere:

                                        Wenn Passwörter "verschlüsselt" werden, dann spricht man technisch gesehen meist nicht von Verschlüsselung, sondern von einer kryptologischen Hash-Funktion. Das Ergebnis einer solchen Funktion nennt man Passwort-Hash, oder kurz Hash. Der Unterschied besteht darin, dass man ein verschlüsseltes Passwort wieder entschlüsseln kann, einen Hash aber nicht, da er mittels einer Einwegfunktion erzeugt wurde.

                                        zu:

                                        Wenn (was regelmäßig der Fall ist) Passwörter nicht im Klartext gespeichert werden sollen, dann verwendet man keine Verschlüsselung sondern eine kryptologischen Hash-Funktion. Das Ergebnis einer solchen Funktion nennt man Passwort-Hash, oder kurz Hash. Der Unterschied besteht darin, dass man ein verschlüsseltes Passwort wieder entschlüsseln kann, einen Hash aber nicht, da er mittels einer Einwegfunktion erzeugt wurde.

                                        1. Lieber Jörg,

                                          Vorschlag. Ändere:

                                          [x] done

                                          Liebe Grüße,

                                          Felix Riesterer.

                                          1. [x] done

                                            Fein gemacht.

                                    2. Jetzt haben wir das Problem der technisch korrekten Sprache, und des landläufigen Sprachgebrauchs derer, die den technischen Unterschied nicht kennen.

                                      Das sehe ich auch. Um ein wenig Theorie wird man nicht herumkommen:

                                      1.)

                                      "Vorbetrachtungen/Begriffsdefinitionen: "Hash" / "hashen"

                                      An manchen Stellen kann man nachlesen, Passwörter würden "verschlüsselt" gespeichert. Das ist aber nicht richtig, weil eine "Verschlüsselung" stets umkehrbar ist. Das würde aber bedeuten, dass ein Angreifer der sich in den Besitz der Daten und des Programms bringen kann, ebenso wie das Programm alle Passwörter entschlüsseln könnte. Die Passwörter werden deshalb einem Verfahren unterzogen, welches man "hashen" nennt. Was dabei entsteht ist ein "Hash". Aus diesem kann man das ursprüngliche Passwort nicht mehr "entschlüsseln". Moderne Verfahren führen dieses "hashen" mehrfach durch (man spricht bei der Anzahl von "Runden") und fügen außerdem noch einen "Salt" hinzu. Das ist eine bestimmte Anzahl zufällig gewählter Zeichen."

                                      2.)

                                      "password_verfify() benötigt zwei Parameter: Zum einen das bei der Anmeldung eingegebene Klartextpasswort und zum anderen den Hash des Passwortes, welcher übrigens Informationen zum intern verwendeten Hash-Verfahren, die Anzahl der "Runden" und den "Salt" enthält. Im Wesentlichen wird das Klartextpasswort mit dem gleichen Verfahren, der gleichen Anzahl von "Runden" und dem gleichen "Salt" erneut gehascht. Stimmt das Ergebnis überein, dann stimmt das Klartextpasswort mit dem überein, dessen hash gespeichert wurde. Die Funktion password_verfify() gibt dann true zurück. password_verfify() funktioniert auch dann, wenn der Hash mit einem veralteten Verfahren erzeugt wurde, also insbesondere nach einem Update."

                                      3.)

                                      "password_needs_rehash() benötigt den gespeicherten Hash und prüft ob das übergebene Passwort mit dem modernsten Verfahren gehasht wurde. Es gibt true zurück, wenn dieses nicht der Fall ist. In dem Fall sollte man nach dem erfolgreichem Login das Klartextpasswort mit password_hash() neu hashen und dann den alten, potentiell unsicheren Hash überschreiben. password_needs_rehash() muss nur wenige Zeichen aus dem Hash mit einer internen Liste vergleichen, braucht kaum Speicher und ist deshalb sehr schnell. Es lohnt sich deshalb diese Prüfung bei bzw. nach jeder Anmeldung vorzunehmen."

                                      1. @Felix Riesterer

                                        Aber verrate @1unitedpower und @woodfighter nicht, dass Du das von mir hast. Sonst ist es auch nach Beweis des Gegenteils "schlecht und falsch".

                                        1. Hallo Google weiß alles,

                                          Aber verrate @1unitedpower und @woodfighter nicht, dass Du das von mir hast. Sonst ist es auch nach Beweis des Gegenteils "schlecht und falsch".

                                          Und was soll der Quatsch?

                                          Bis demnächst
                                          Matthias

                                          -- Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
                                          1. Aber verrate @1unitedpower und @woodfighter nicht, dass Du das von mir hast. Sonst ist es auch nach Beweis des Gegenteils "schlecht und falsch".

                                            Und was soll der Quatsch?

                                            Bezug zum Urpungsposting. Die wahren Gründe der Löschung.

                                            1. Hallo Google weiß alles,

                                              Aber verrate @1unitedpower und @woodfighter nicht, dass Du das von mir hast. Sonst ist es auch nach Beweis des Gegenteils "schlecht und falsch".

                                              Und was soll der Quatsch?

                                              Bezug zum Urpungsposting. Die wahren Gründe der Löschung.

                                              Die aus deiner Sicht wahren Gründe der Löschung. Aber was bezweckst du damit?

                                              Bis demnächst
                                              Matthias

                                              -- Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
                                              1. Hallo Matthias,

                                                ... Aber was bezweckst du damit?

                                                wahrscheinlich hat zurzeit keine Anwaltskanzlei und keine Webagentur Lust, sich mit ihm zu streiten.

                                                Gruß
                                                Jürgen

                                                1. wahrscheinlich hat zurzeit keine Anwaltskanzlei und keine Webagentur Lust, sich mit ihm zu streiten.

                                                  Ich bin mir nicht sicher, ob das eine angemessene Äußerung ist. Du scheinst Dich auf den Autor des gelöschten Wiki-Artikels zu beziehen. Wenn es so ist, dann weißt Du auch, dass er sich mit Pack befasst, welches durch Betrug, Abzocke und mieser Qualität der Leistung das Ansehen der Branche in den Dreck zieht. Wenn Du dann noch in der Branche bist, dann müsstest Du eigentlich wissen, dass das auch für Dich gut ist. Und wenn jetzt "keine Anwaltskanzlei und keine Webagentur Lust (hat), sich mit ihm zu streiten", dann ist das also auch gut für Dich.

                                                  Oder arbeitest Du für einen Hungerlohn bei der Webagentur mit der er sich streitet?

                                              2. Hallo Google weiß alles,

                                                Aber verrate @1unitedpower und @woodfighter nicht, dass Du das von mir hast. Sonst ist es auch nach Beweis des Gegenteils "schlecht und falsch".

                                                Und was soll der Quatsch?

                                                Bezug zum Urpungsposting. Die wahren Gründe der Löschung.

                                                Die aus deiner Sicht wahren Gründe der Löschung. Aber was bezweckst du damit?

                                                Nun, das Motiv ist ja im Hinblick auf die zwar angeführten aber unzutreffenden "Gründe" ziemlich klar im persönlichen Bereich zu suchen. "Präsente Sicherheitsmängel" kann man nämlich immer klar benennen. Ich zitiere ihn mal: "Im Gegenteil, einige Sicherheitslücken sind hier bereits diskutiert worden, mindestens eine davon ist immer noch präsent, wie ich gerade beim Überfliegen gemerkt habe." - Dann muss er aber klar benennen können, worin die Sicherheitslücke besteht. Kann er das nicht - und er hat diese "präsente Sicherheitslücke" nunmehr 2 Wochen lang nicht benannt, dann gibt es wenig Anlass dazu, zu glauben,

                                                1. dass es sich bei der Behauptung von Sicherheitslücken um etwas anderes als eine sehr gezielte Verleumdung handeln könnte und
                                                2. dass sein tatsächliches Motiv etwas anderes als "Unwille" gegenüber dem ehemaligen Autor ist.

                                                Für die, denen das zu kompliziert ist, stark vereinfacht: "Der wahre Grund für die Löschung war Hass."

                                                Aber was bezweckst du damit?

                                                Ich will klar sagen, was hier schief läuft und an @1unitedpower die Nachricht schicken, dass er so nicht weiter machen kann und dass es nicht reicht wenn man nach einem so groben Verstoß gegen die guten Sitten seinen viel zu späten Rückzieher in derart viele "ich habe aber doch Recht" verpackt, dass 12288 Zeichen nicht reichten.

                                                Zudem hätte es - jedenfalls mit DER vorgeschobenen Begründung - andere Löschkandidaten mit noch gröberen Fehlern gegeben. Wenn es @1unitedpower tatsächlich um die von ihm behaupteten Motive gänge, dann hätte er auch diesen Artikel sperren - oder konstruktiver: reparieren müssen. Ich werde es jedenfalls nicht tun weil ich im Hinblick auf das Ausbleiben von Anzeichen ausreichender Einsicht befürchten muss, dass er "dahergeht" und aus den selben, sehr wohl sehr persönlichen Gründen, also nur um mich zu ärgern, mit einem bequemen Mausklick meine Arbeit zu Nichte macht.

                                                Im übrigen sehe ich auch, dass @1unitedpower "nicht wirklich viel Konstruktives" vorträgt. Ich meine, bei seinen Beiträgen besteht ein Missverhältnis zwischen Kritik an gezeigtem Vorgehen und konstruktiver Hilfe.

                                                Ich finde hier kann nur eine richtige Entschuldigung gerade wegen der damit verbundenen Scham eine Vermutung bewirken, dass er sich bessert und das derlei nicht nochmal stattfindet. Das wäre auch zum Wohl der SelfHTML-Community.

                                                By the way: Anfänger gerade in einer sicherheitsrelevanten Frage auf Frameworks zu verweisen, deren Dokumentation irgendwo zwischen "dürftig", "schwierig zu lesen", "auf deutsch nicht verfügbar" und "wendet sich nicht an Anfänger" zu sehen ist, halte ich für fragwürdig. Damit verbunden noch zu behaupten, dass nur etablierte Frameworks die Sicherheit gewährleisten würden halte ich bestenfalls für Ironie. "Anfänger" kriegen das nämlich nicht mal zum Laufen.

                                                Folgende Nachrichten verweisen auf diesen Beitrag:

                                                1. Hallo Google weiß alles,

                                                  Nun, das Motiv ist ja im Hinblick auf die zwar angeführten aber unzutreffenden "Gründe" ziemlich klar im persönlichen Bereich zu suchen.

                                                  Für die, denen das zu kompliziert ist, stark vereinfacht: "Der wahre Grund für Löschung war Hass."

                                                  Nun, das ist deine Wahrnehmung. Da ich aber 1UnitedPower persönlich kenne, kann ich dir sagen, dass meiner Meinung nach Hass dabei keine Rolle spielt, zudem 1UnitedPower den Jörg nicht persönlich kennt und auch nicht davon auszugehen ist, dass sie anderweitig aneinander geraten wären.

                                                  Aber was bezweckst du damit?

                                                  Ich will klar sagen, was hier schief läuft und an @1unitedpower die Nachricht schicken, dass er so nicht weiter machen kann

                                                  Das ist, denke ich, a) berechtigt und b) angekommen - kein Grund also, das wieder und wieder zu wiederholen.

                                                  By the way: Anfänger gerade in einer sicherheitsrelevanten Frage auf Frameworks zu verweisen, deren Dokumentation irgendwo zwischen "dürftig", "schwierig zu lesen", "auf deutsch nicht verfügbar" und "wendet sich nicht an Anfänger" zu sehen ist, halte ich für fragwürdig. Damit verbunden noch zu behaupten, dass nur etablierte Frameworks die Sicherheit gewährleisten würden halte ich bestenfalls für Ironie. "Anfänger" kriegen das nämlich nicht mal zum Laufen.

                                                  Das ist ebenfalls ein Argument der ersten Stunde, dem ich zustimme. Deshalb auch meine Fragen, (kann man den Artikel empfehlen, setzt du ein Loginsystem beruhend auf diesem Artikel ein), die du bereits beantwortet hast. Ich hätte den Artikel durchaus auch wiederhergestellt, mit einem entsprechenden Hinweis versehen.

                                                  Du hast sicher Verständnis dafür, dass ein Hinweis, der SELFHTML in einem schlechten Licht erscheinen lässt, ja als Negativ-Werbung betrachtet werden kann, (nein du brauchst nicht zu schreiben, dass du die Löschung als eigentlichen Auslöser siehst) nicht auf einer unserer eigenen Wikiseiten stehen bleibt.

                                                  Insgesamt ist die ganze Aktion nicht optimal verlaufen. Es bleibt zu überlegen, was man anders machen muss. (Ein einfaches und zeitnahes Zurücksetzen der Löschung schien mir ebenfalls nicht zielführend zu sein, zumal 1UnitedPower auf diesem Gebiet wesentlich mehr Ahnung hat als ich.) Ebenso sehe ich die Verlinkung auf Uralt-Versionen aus archive.org kritisch. Auch darüber wird zu sprechen sein.

                                                  Die öffentliche Mitgliederversammlung des Vereins SELFHTML e.V. findet am 1. Oktober 2016 in Erfurt statt. Du bist herzlich eingeladen.

                                                  Bis demnächst
                                                  Matthias

                                                  -- Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
                                                  1. Du hast sicher Verständnis dafür, dass ein Hinweis, der SELFHTML in einem schlechten Licht erscheinen lässt, ja als Negativ-Werbung betrachtet werden kann,

                                                    Geschriebener Text:

                                                    An dieser Stelle war in der Vergangenheit eine Anleitung für ein PHP-Loginsystem zu finden. Über die Jahre sind allerdings diverse Sicherheitslücken im System aufgefallen, teilweise sind sie danach geschlossen worden.

                                                    Empfangene Nachricht:

                                                    "Oi! Die hatten hier jahrelang ein Login-System mit schweren Sicherheitslücken, haben das gewusst und den Kackmist nicht gändert? Wat kann dat taugen?"

                                                    Ich weiß bis jetzt nicht, welchen Grund es gab,

                                                    An dieser Stelle war in der Vergangenheit eine Anleitung für ein PHP-Loginsystem zu finden. Diese Anleitung wurde zunächst ohne die angemessene vorherige Diskussion von einem Community-Mitglied unter der Behauptung "präsenter Sicherheitsmängel" und ungenügender Pflege gelöscht. Diese Behauptungen haben sich dann aber als "nicht verifizierbar" erwiesen. Allerdings ist der frühere Autor infolge dieses von ihm nicht grundlos als "ungerechtfertigt rufschädlich" empfundenen Vorkommnisses nicht mehr dazu bereit den Artikel zu pflegen und hat selbst angeregt die Löschung auch beim negativen Beweis der ursprünglich behaupteten Gründe beizubehalten.

                                                    Andere Community-Mitglieder haben im Hinblick darauf, dass Anfänger bei der Realisierung der Lösung Fehler mit schweren Folgen machen könnten, Bedenken, dass der Artikel nicht mit den Intentionen von SelfHTML übereinstimmt. Deshalb hat sich trotz der Abwesenheit der behaupteten "präsenten Sicherheitsmängel" der allseitige Konsens herausgebildet diese Anleitung nicht weiter zu veröffentlichen.

                                                    Da der ursprüngliche Autor nun nicht mehr mit SelfHTML in Verbindung gebracht werden will können wir leider keinen Link zu einer externen Ressource anbieten.

                                                    zu entfernen und unter Behaupten eines "Edit-War" durch das, aus dem oben gezeigten Grund nicht werbende (und wegen der impliziten Behauptung erkannter und nicht geschlossener Sicherheitslücken sogar unwahre)

                                                    Achtung!

                                                    Über die Jahre sind allerdings diverse Sicherheitslücken im System aufgefallen, teilweise sind sie danach geschlossen worden.

                                                    zu ersetzen. Wenn das 6 Teilnehmer (inklusive mutmaßlicher Sockenpuppen) auch noch gut finden, dann bin ich allerdings sehr enttäuscht.

                                                    Alternativ-Text

                                                    Mist. Ist ja so passiert. Dass sich (außer mir) dann nur zwei fanden, die den konstruktiv handelnden und sich trotz besten Badewetters eine Menge Mühe machenden Felix lobten, trägt zu meiner geradezu maßlosen Enttäuschung über die Community bei.

                                                    1. Aloha ;)

                                                      Ich weiß bis jetzt nicht, welchen Grund es gab,

                                                      [...]

                                                      zu entfernen und unter Behaupten eines "Edit-War" durch das, aus dem oben gezeigten Grund nicht werbende (und wegen der impliziten Behauptung erkannter und nicht geschlossener Sicherheitslücken sogar unwahre)

                                                      [...]

                                                      zu ersetzen.

                                                      Sowohl die ursprüngliche Löschmeldung sowie die von Matthias eingesetzte treffen - wie du zu Recht sagst - den Kern des Problems akkurat; es ist dein gutes Recht, diese zu kritisieren. Allerdings trifft auch deine Löschmeldung nicht den Kern des Problems, da sie sich darin verliert, deine eigene, persönliche Sicht auf die Umstände der Löschung zu schildern, statt den Grund der Löschung präzise und neutral - in einer dem Wiki angemessenen Form - zu umreißen.

                                                      Wenn das 6 Teilnehmer (inklusive mutmaßlicher Sockenpuppen) auch noch gut finden, dann bin ich allerdings sehr enttäuscht.

                                                      Alternativ-Text

                                                      Dir sollte sehr wohl bewusst sein, dass der (nach wie vor zu der Zeit sachlich nicht korrekte) konkrete Text des Löschhinweises nicht direkt Gegenstand des Postings war - sondern vor allem die Kritik daran, dass im Verlauf dieser gesamten Geschichte mehr Arbeit in destruktive als in konstruktive Auseinandersetzung geflossen ist. Das - und nur das - war Gegenstand des Postings und damit auch der Bewertungen. Jede Interpretation, die das verkennt, ist exakt genauso destruktiv wie das von Matthias bemängelt wurde.

                                                      Dass sich (außer mir) dann nur zwei fanden, die den konstruktiv handelnden und sich trotz besten Badewetters eine Menge Mühe machenden Felix lobten, trägt zu meiner geradezu maßlosen Enttäuschung über die Community bei.

                                                      Das Bewertungs-Feature ist ausschließlich dazu geeignet, Tendenzen festzustellen. Bewertungen unterschiedlicher Postings sind nicht direkt vergleichbar, drücken keine absolute Wertigkeit aus und die Gründe für eine Bewertung oder Nicht-Bewertung sind nicht eindeutig interpretierbar. Das Bewertungs-Feature hat alleine den Sinn und Zweck, dass ein Leser, dem ein Beitrag aus nicht näher benannten Gründen gefällt oder nicht gefällt, dem Autor und weiteren Lesern gegenüber diese subjektive Empfindung näher bringen kann. Insbesondere ist eine +2-Bewertung nicht schlechter als eine +7-Bewertung, sondern ausschließlich Ausdruck dessen, dass mehr oder weniger Benutzer ihr Gefallen auch ausdrücklich zeigen. Eine durch Bewertungen bestimmte Differenzierung lässt sich nur zwischen in Summe negativ und in Summe positiv bewertete Beiträge sicher ausmachen.

                                                      Ich bin sicher, dass @Felix Riesterer sehr genau weiß, wie sehr ich ihn und seine konstruktive Arbeit hier wertschätze - selbst, wenn meine Maus den Weg zum +-Button nicht finden sollte.

                                                      Grüße,

                                                      RIDER

                                                      -- Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller

                                                      # Facebook # Twitter # Steam # YouTube # Self-Wiki #

                                                      Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
                                                      1. Lieber Camping_RIDER,

                                                        Ich bin sicher, dass @Felix Riesterer sehr genau weiß, wie sehr ich ihn und seine konstruktive Arbeit hier wertschätze - selbst, wenn meine Maus den Weg zum +-Button nicht finden sollte.

                                                        stimmt. Trotzdem tut ein solcher Art indirekt erteiltes Lob auch gut.

                                                        Liebe Grüße,

                                                        Felix Riesterer.

              3. Hallo

                ich glaube, du willst es nicht verstehen. Es geht 1unitedpower darum, dass nur jemand, der Erfahrung im Erstellen von narrensicheren Loginsystemen hat, einen Artikel hierzu für Anfänger schreiben sollte. Bist du Experte darin? Hast du schon solche Systeme erstellt? Kannst du den Artikel immer und zeitnah aktuell halten? Sollte ein Anfänger überhaupt ein selbst erstelltes Logensystem verwenden?

                Wenn mein Tabellensortierter mal nicht funktionieren sollte, ist das zwar ärgerlich, aber kein Beinbruch. Bei einem Shop, der wegen eines unsicheren Logensystems geplündert wird, sieht das schon ganz anders aus.

                Gruß
                Jürgen

                1. Es geht 1unitedpower darum, dass nur jemand, der Erfahrung im Erstellen von narrensicheren Loginsystemen hat, einen Artikel hierzu für Anfänger schreiben sollte.

                  Auf Grund des äußerst engen zeitlichen Zusammenhangs mit anderen Nickligkeiten und den Formulierungen in seiner Nachricht und im Wiki ist aber hinsichtlich des Motivs etwas ganz anderes sehr viel naheliegender.

                  Bist du Experte darin? Hast du schon solche Systeme erstellt? Kannst du den Artikel immer und zeitnah aktuell halten?

                  Wieso ich?

                  Sollte ein Anfänger überhaupt ein selbst erstelltes Logensystem verwenden?

                  Ein blutiger Anfänger sollte gar nichts (unüberprüft) ins Web stellen. Wenn jemand wüsste, was er ins Web stellen kann und was nicht, dann wäre er kein Anfänger mehr weil schon diese bloße Unterscheidung eine ganze Menge Wissen erfordert. Das wir eine andere Realität sehen und das sogar große Organisationen, denen man Intelligenz zutrauen möchte, da Mist bauen steht auf einem anderen Blatt.

                  1. Hallo,

                    Bist du Experte darin? Hast du schon solche Systeme erstellt? Kannst du den Artikel immer und zeitnah aktuell halten?

                    Wieso ich?

                    so wie du für den Artikel kämpfst, dachte ich, du wärst der Autor.

                    Gruß
                    Jürgen

                    1. so wie du für den Artikel kämpfst, dachte ich, du wärst der Autor.

                      Nein. Hier geht es ganz eindeutig dass der Artikel nach einem vorherigen Streit auf Ent- und Beschluss einer einzelnen Person und dann auch unter dem inzwischen offensichtlich (und also wahrscheinlich: wissentlich) unwahren Behaupten "präsenter Sicherheitslücken" gelöscht wurde. Es ist also, gerade auch im Hinblick auf den fehlenden Nachweis der angeblich präsenten Sicherheitslücken, naheliegend, dass der eigenmächtigen Löschung ganz andere als die behaupteten, nämlich höchst persönliche und ergo sehr sachfremde Motive zugrunde liegen.

                      Des weiteren bieten übrigens die ausgerechnet die +/- Bewertungen in der Diskussion einen Anhaltspunkt dafür, dass Vorfälle dieser Art von einem relevanten Personenkreis unkritisch hingenommen werden. Daraus kann man aber schließen, dass hier kulturisierte persönliche Beziehungsgeflechte über den Sachfragen stehen.

                      Da der Autor - wohl inzwischen auch auf Grund der Art der Löschung und der weitgehend unbeanstandet gebliebenen, unwahren Begründung - kein Interesse mehr an dem Artikel hat und jetzt der Fall eingetreten ist, dass sich niemand um selbigen kümmert, "kämpfe" ich nicht um den Artikel. Der Artikel ist weg und der bleibt aus den mit und nach der Löschung eingetretenen oder ersichtlich gewordenen Umständen, die mit dem Artikel selbst nichts zu tun haben, (wohl) weg.

                      Es kann nur noch darum gehen, solche Vorfälle für die Zukunft auszuschließen und dazu kam bezeichnenderweise "nicht wirklich viel" in der Diskussion.

                  2. Ich erinnere nochmal an die Äußerung von @1unitedpower:

                    "Im Gegenteil, einige Sicherheitslücken sind hier bereits diskutiert worden, mindestens eine davon ist immer noch präsent"

                    Wo ist denn jetzt bitte diese als "präsent" behauptete "Sicherheitslücke"?

                    Seit dem bringt @1unitedpower nur Theorien, wie zukünftig(!) vielleicht(!) Sicherheitslücken entstehen könnten(!) und was ihm, rein vom Stil her, am Skript nicht gefällt. Die behauptete "präsente Sicherheitslücke" hat er nicht vorgestellt.

                  3. Es geht 1unitedpower darum, dass nur jemand, der Erfahrung im Erstellen von narrensicheren Loginsystemen hat, einen Artikel hierzu für Anfänger schreiben sollte. Bist du Experte darin? Hast du schon solche Systeme erstellt? Kannst du den Artikel immer und zeitnah aktuell halten?

                    Also wenn ich seine htpasswd-Geschichte und das hier strittige Login-System betrachte, dann sind beide durchaus "narrensicher". Ich fand keinen Fehler und habe keine Bedenken. Die Anwendung zusammen mit selbst geschriebenen anderen Skripten ist sehr einfach (Berechtigte Benutzer und Gruppen definieren, Skript auth.php einbinden reicht im einfachsten Fall ja aus...) - wer überhaupt was zum Laufen bekommt wird daran nicht scheitern.

                    Wie soll denn "narrensicher" sonst noch gehen?

                2. Ich komprimiere mal Deine Aussagen:

                  Artikel für Anfänger ... Bei einem Shop, der wegen eines unsicheren Logensystems...

                  Ich sehe das so: Wenn ein Anfänger einen Shop schreibt, dann "hinkt" nicht der Vergleich sondern die Idee.

              4. Lieber Jörg,

                Statt die konkret behaupteten "bestehenden Sicherheitsmängel" darzulegen kamen wieder nur theoretische Überlegungen und fragwürdige Beispiele, welche mit dem konkretem Skript rein gar nichts nichts zu tun haben.

                das sehe ich in Teilen anders. Ja, ein konkreter Sicherheitsmangel wurde nicht aufgezeigt. Da gebe ich Dir Recht.

                Aber: Dass man seine Software testet, ist sinnvoll. Dass man solche Tests automatisiert, scheint sinnvoll. Wenn ich das konkrete Beispiel für die Berechnung einer Quadratwurzel betrachte, dann entsteht bei mir der Eindruck eines Wettlaufs zwischen Hase ("Da! Eine Möhre aka Sicherheitsloch!") und Igel ("Ich beweise Dir, dass der Code das tut, was Du von ihm erwartest."), von dem man nur sagen kann, wer von den beiden Läufern gerade vorne liegt. Das sagt aber nichts über die tatsächliche Sicherheit der Software aus, sondern nur darüber, inwieweit man die Funktionalität der Software mit dem aktuellen Erkenntnisstand nachweisen kann.

                Und da haben wir ein prinzipielles Problem: Bei den Unit-Tests muss ich mit kreativer Phantasie ein Programm schreiben, das versucht, meine zu testende Software auszuhebeln. Vielleicht gelingt mir das nicht, aber vielleicht jemand anderem. In diesem Fall attestiere ich der Software, dass sie genau das tut, was ich von ihr erwarte, aber ein anderer könnte mir beweisen, dass sie das nicht tut.

                Wenn ich lese, dass ein PHP-Skript die zugrunde legende PHP-Version überprüfen solle, dann komme ich zu dem Ergebnis, dass wenn man das als richtig erachten wolle, dass man dann aber auch:

                • nach PHP auch das Betriebssystem,
                • nach dem OS auch die BIOS-Version der Hardware,
                • sämtliche parallel installierte Software,
                • ... was immer auch Einfluss nehmen kann ... prüfen muss.

                Bitte bleibe bei den Verhältnissen, sonst muss man Dir Polemik vorwerfen!

                Die Prüfung auf die aktuelle PHP-Version kann einen Sinn haben, wenn man Feature-Detection vereinfachen will. Bei JavaScript muss man das sehr ausführlich tun, bei PHP gibt es Erkenntnisse darüber, welche PHP-Version welche Features wie bereitstellt.

                Das OS zu überprüfen hat aus meiner Sicht keinen Sinn mehr, da Du Sicherheitsprobleme des OS in Deinem PHP-Script nicht kompensieren kannst. Was Du allenfalls anführen könntest, wäre das Argument, dass unter gewissen OS gewisse Verschlüsselungsalgorithmen nicht verfügbar sind und stattdessen schwächere als Ersatz genommen werden müssten. Aber auch hier gilt wieder: Du kannst das mit Deinem PHP-Script nicht kompensieren! Wenn PHP die notwendigen Bibliotheken nicht bereitstellt, sondern sich auf Schnittstellen zu den jeweiligen Plattformen verlässt, dann bist Du als Autor von PHP-Scripten eben verlassen.

                Mit allem Verlaub dürfte das bei einem Skript, welches den Job hat, ein Login durchzuführen und ein gemeinsames Geheimnis zu teilen sowie also eine Erkennung des Benutzers und seiner Rechte (Gruppen) zu ermöglichen, ein ganz sehr höflich formuliertes "wenig" der Aufgabe vorbei gehen. Derlei gehört allenfalls in ein Setup-Skript, welches im Wiki-Artikel aber nicht beschrieben wurde.

                Nunja. Da würde ich gerne einen Mittelweg gehen. Auf der einen Seite würde ich schon gerne vorstellen, wie man dieses "ein gemeinsames Geheimnis teilen" sinnvoll umsetzen kann. Dabei darf man auch gleich auf die Problematik der Verschlüsselung eingehen. Aber man sollte vielleicht kein Beispiel geben, das Unbedarfte "out-of-the-box" einsetzen können. Niemand verlangt von einem Tutorial, dass am Ende copy&paste-fähiger Ergebniscode steht!

                Selbstverständlich darf man an dieser Stelle die Praxis der Unit-Tests auch vorführen (vielleicht dazu einen eigenen Basis-Artikel, auf den man dann für eine Vertiefung verweisen kann?), aber man sollte auch die Grenzen dieser Praxis und ihre Bedeutung für die Abschätzung der Sicherheit des eigenen Codes diskutieren.

                Die Formulierung "bestehende Sicherheitsmängel" erzeugt die Vermutung, dass ein konkreter Angriff möglich ist. Diesen hat @1unitedpower auch 10 Tage nach seiner Behauptung nicht beschrieben, was die Vermutung erzeugt, dass er also keinen gefunden hat.

                Dass ein konkret vorliegender Sicherheitsmangel nicht aufgezeigt wurde, ist richtig. Deine Schlussfolgerung nicht ganz. Meiner Wahrnehmung nach wollte @1unitedpower darauf hinweisen, dass die Sicherheit nicht formal bewiesen werden konnte und daher im Umkehrschluss (ob Du diesen jetzt so erlaubst oder strikt ablehnst) das Verfahren im Artikel als unsicher einzuschätzen ist.

                Zum Schluss möchte ich Dich auf eine Formulierung von @1unitedpower aufmerksam machen (Hervorhebungen von mir), die Deiner Position eine ganze Menge entgegen kommt:

                Wir müssen eine Kultur etablieren, in der es nichts Schlimmes ist, sich zu fehlenden Fachkenntnissen zu bekennen und Scheitern nicht als etwas rein Negatives empfunden wird. Ich gestehe auch ein, mit meinem Handeln zu Beginn, nicht uneingeschränkt in diesem Sinne gearbeitet zu haben. Das nehme ich aus dieser Diskussion mit und hoffe, dass sich diese Eskalation nicht wiederholen wird.

                Bitte unterschätze dieses Friedensangebot nicht! Und bitte bleibe offen für andere Sichtweisen, die prinzipbedingt Deiner Login-Software keinen Persilschein geben können. Dass die Kommunikation in dieser Angelegenheit im Vorfeld versagt hat, haben wir ja an anderer Stelle schon erörtert.

                Liebe Grüße,

                Felix Riesterer.

                1. Lieber Jörg,

                  Lieber Andreas Mustermann

                  Und bitte bleibe offen für andere Sichtweisen, die prinzipbedingt Deiner Login-Software keinen Persilschein geben können.

                  Wieso soll sich denn nicht feststellen lassen ob das Skript die behaupteten Sicherheitsmängel hat?

                  Im übrigen stellte ja @1unitedpower selbst klar, dass die Entwickler bei Zend bei gefundenen Sicherheitsmängeln einen Unittest entwickeln der den bekannten Fehler verifizierbar macht und dann hingehen und die gefixte Version gegen diesen Unittest prüfen.

                  Das bedeutet aber: Eine allgemeine Behauptung, (erst recht: nur) durch Unit-Tests könne man per se Fehler ausschließen ist schlicht unwahr, denn der Fehler muss bekannt sein. Also kann man nur bereits bekannte Fehler ausschließen. Das ist aber eine ganz andere Aussage als die getätigte, nämlich dass nur durch die Unit-Tests die Fehlerfreiheit nachgewiesen werde könne. Ich kann nämlich auch die 3,5 kurzen Funktionen aus dem Skript nehmen und durch bloßes Lesen feststellen, dass die sicher sind.

                  Wie schon gesagt: Bein großen Programmen, die von mehreren Programmieren geschrieben werden (und in mehreren Versionen mit Bugfixes zu versorgen sind) mag das sinnvoll sein, bei Skripten, die aus ein paar Dutzend Zeilen bestehen, eher nicht.

                  Auch die Kritik von @1unitedpower an den exits kann ich nicht nachvollziehen, denn diese machen die Geschichte doch sicher: Keine gültige Session? Login-Formular anzeigen - und Ende. Ungültige Anmeldedaten? Login-Formular anzeigen - und Ende. Gruppe stimmt nicht? "Das darfst Du nicht anzeigen" und Ende.

                  Das ist einfacher als die Frage auf die Antwort nach dem gültigen Login durch ein weiteres Gewusel von ifs und thens und elses oder Objekten zu schleppen und im Zweifelsfall in diesem Gewusel einen Fehler zu machen. Ist es aber einfacherer, dann ist es per se auch sicherer.

                  Die Aussage, das das Skript am Beginn einzubauen sei war ja auch klar. Insofern ist auch bei den Headern der Fall klar. Auch hat der Autor keineswegs versucht, eigene Hash-Algorithmen zu verbauen, sondern die password*_Funktionen benutzt. Wo es diese nicht gibt hat er lediglich den Mantel nachgebaut mit dem password_hash() um crypt() herum den salt aus Zufallswerten (die korrekt, nämlich anhand der Definition gewählt wurden) baut (und auch hier fand ich nichts Falsches) und dann mehrfach hascht.

                  Bitte unterschätze dieses Friedensangebot nicht!

                  Irgendwo in ellenlangen Ausführungen versteckt, welche die später nachgeschobenen und sehr theorielastigen Vorhaltungen nochmals enthalten und die Aussage, es habe konkrete Sicherheitsmängel gehabt, nicht einmal zurücknehmen? Da ist mir viel zu viel "Und ich hab doch recht!" an der Stelle wo "Ich hab Mist gebaut!" stehen sollte.

                  Anders ausgedrückt: Wenn @1unitedpower mal in einer Firma Mitarbeiterverantwortung trägt und dieses Verhalten nicht gründlich ändert, dann steht diese Firma recht schnell in der Liste derer, welche über einen "Fachkräftemangel" klagen. Die laufen nämlich weg wenn diese, so wie hier geschehen, erst mit unwahren Vorhaltungen ("konkrete Sicherheitsmängel") konfrontiert werden, denen nachfolgend allerhand Theoriegeschwurbel folgt - dessen Aussagen sich dann bei hartnäckigem Hinterfragen auch noch als "stark relativierbar" (siehe Unittests) erweisen. Das ist es, was hier stattfand und jeder der den Unsinn von @1unitedpower noch gut fand darf sich mitschämen.

                  Derart verpackte "Friedensangebote" bringen nichts. Warum geht die Rücknahme der falschen Behauptung nicht so kurz, prägnant und knackig wie seine unwahr begründete Löschmeldung?