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.