> Lieber Jörg, Lieber Andreas Mustermann > Und bitte bleibe offen für andere Sichtweisen, die prinzipbedingt Deiner Login-Software keinen [Persilschein](https://de.wiktionary.org/wiki/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](https://forum.selfhtml.org/meta/2016/jun/30/artikel-loginsystem-geloescht/1670108#m1670108)?**

> Lieber Jörg, Lieber Andreas Mustermann > Und bitte bleibe offen für andere Sichtweisen, die prinzipbedingt Deiner Login-Software keinen [Persilschein](https://de.wiktionary.org/wiki/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 Löschmeldung?**

> Lieber Jörg, Lieber Andreas Mustermann > Und bitte bleibe offen für andere Sichtweisen, die prinzipbedingt Deiner Login-Software keinen [Persilschein](https://de.wiktionary.org/wiki/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. **Derart verpackte Friedensangebote bringen nichts. Warum geht die Rücknahme der falschen Behauptung nicht so kurz, prägnant und knackig wie seine Löschmeldung?**

> Lieber Jörg, Lieber Andreas Mustermann > Und bitte bleibe offen für andere Sichtweisen, die prinzipbedingt Deiner Login-Software keinen [Persilschein](https://de.wiktionary.org/wiki/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, dann steht diese recht schnell in der Liste derer, welche über 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 auch noch als _"stark relativierbar"_ (siehe Unittests) erweisen. Das ist, was hier stattfand. **Derart verpackte Friedensangebote bringen nichts. Warum geht die Rücknahme der falschen Behauptung nicht so kurz, prägnant und knackig wie seine Löschmeldung?**

> Lieber Jörg, Lieber Andreas Mustermann > Und bitte bleibe offen für andere Sichtweisen, die prinzipbedingt Deiner Login-Software keinen [Persilschein](https://de.wiktionary.org/wiki/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 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, dann steht diese recht schnell in der Liste derer, welche über 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 auch noch als _"stark relativierbar"_ (siehe Unittests) erweisen. Das ist, was hier stattfand. **Derart verpackte Friedensangebote bringen nichts. Warum geht die Rücknahme der falschen Behauptung nicht so kurz, prägnant und knackig wie seine Löschmeldung?**

> Lieber Jörg, Lieber Andreas Mustermann > Und bitte bleibe offen für andere Sichtweisen, die prinzipbedingt Deiner Login-Software keinen [Persilschein](https://de.wiktionary.org/wiki/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 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 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, dann steht diese recht schnell in der Liste derer, welche über 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 auch noch als _"stark relativierbar"_ (siehe Unittests) erweisen. Das ist, was hier stattfand. **Derart verpackte Friedensangebote bringen nichts. Warum geht die Rücknahme der falschen Behauptung nicht so kurz, prägnant und knackig wie seine Löschmeldung?**