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.