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.