Von zettberlin am Fr, 14. September 2012 um 09:40 #
Hatten wir doch gerade in der Diskussion zu Symphonie: wer sich ernsthaft mit PHP beschäftigt, kommt beizeiten an Punkte, an denen man es sich irgendwie besser wünscht.
Schön, dass dem PHP-Team das bewusst zu sein scheint
Dem kann ich nun gar nicht zustimmen. Was hier geboten wird ist doch keine neue Funktionalität, sondern nur ein Wrapper auf Funktionen, die schon lange existieren. Der Kasus Knaxus ist doch, dass PHP Entwickler offenbar nicht in der Lage sind, diese Funktionen korrekt einzusetzen, und dass die PHP Community dafür keine bessere Lösung sieht, als die Sprache weiter zu verhackstückeln. Woran es mangelt ist Aufklärung und ein vernünftiges Sprachkonzept, kein "Wir tun mal so, als wären wir noch in den 90ern"-Gehabe.
Von zettberlin am Fr, 14. September 2012 um 14:27 #
> nur ein Wrapper auf Funktionen, die schon lange existieren
Das könnte man auch von while und anderen Alltäglichkeiten sagen. PHP ist eben eine spezialisierte Scriptsprache für einen beschränkten Bereich von Anwendungen, keine LowLevel Sprache, mit der irgendwer Gerätetreiber der dergleichen schreiben will.
Da geht es weniger um Technik und mehr um Logik.
> offenbar nicht in der Lage sind, diese Funktionen korrekt einzusetzen,
Bei PHP ist man eben der Ansicht, dass Verschlüsselung letztlich Low level ist, das nur Sicherheitsexperten im Detail beherrschen müssen. Für einen Anwendungsentwickler sollte es reichen, dass er/ sie weiß, was Verschlüsselung ist und wie man sie im Kontext einer Anwendung benutzt.
Das finde ich durchaus vernünftig.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 14. Sep 2012 um 14:28.
Als Entwickler sollte man sich bewusst sein was es bedeutet einen bestimmten Verschlüsselungsalgorithmus zu wählen. Das hat für mich nichts mit LowLevel zu tun. Natürlich ist es schön wenn einem die Programmiersprache etwas abnimmt. Allerdings sollte es nicht dazu verleiten, dass man sich mit wichtigen Themen nicht oder unzureichend auseinander setzt.
Genau das kann dann nämlich wieder zu Sicherheitslücken führen und der Anwender muss dann wieder unter den Folgen leiden.
Von zettberlin am Fr, 14. September 2012 um 16:55 #
>Als Entwickler sollte man sich bewusst sein was es bedeutet einen bestimmten Verschlüsselungsalgorithmus zu wählen.
Damit hast Du natürlich Recht. Aber das ist dann andererseits auch in der Verantwortung des Entwicklers: die neue Funktion verheimlicht den Algoritmus ja nicht und man kann das ganze nach wie vor auch per Hand machen.
Wer einen Nutzer mit adduser anlegt, hat dabei auch keinen direkten Zugang zur Methode der Passwortverschlüsselung. Und den Admin möchte ich sehen, der nicht normalerweise adduser oder was vergleichbares benutzt, wenn ein neuer Account gebraucht wird.
>Allerdings sollte es nicht dazu verleiten, dass man sich mit wichtigen Themen >nicht oder unzureichend auseinander setzt.
Die Welt ist nunmal nicht perfekt, was auch an beschränkter Zeit liegt. Der Tag hat im gegensatz zur CPU leider einen festen Multiplikator von 24.
Grundsätzlich sehe ich keinen Unterschied zwischen Passwortsicherheit oder etwa CPU Optimierung: Der Entwickler ist besser beraten sich auf den Anwender als auf die Hardware zu konzentrieren. In Sprachen wie C, C++, Java etc... gibt es Bibliotheken die einem eine vernünftige best-effort Sicherheit einfach zur Verfügung stellen, in PHP, einer Sprache mit einem einzigen Anwendungsfall, kann dies durchaus in die Sprache integriert werden. Zieht man die übliche Betriebsweise von PHP in die Betrachtung mit ein, macht das sogar noch viel mehr sinn. Der Nutzer der Anwendung ist als üblicher Schwachpunkt in punkto Updates aussen vor - die Verantwortung trägt der Provider, der damit besser umgehen kann - falls nicht, bereinigt dies der Markt ganz von alleine.
`while` ist doch kein Wrapper sondern ein Schlüsselwort... insofern ist der Vergleich falsch. Zudem ist eine "weitere Funktion" schon ein Problem! Ein sauberes API für Verschlüsselung ist das A und O. Das Sortieren ist doch ein klassisches Beispiel für das miserable API-Design in PHP. Wieso gibt es für jeden Datentypen eine separate Funktion? Wieso wird das nicht wie in jeder gut designten Sprache über FOF / Interfaces oder vergleichbares gelöst?
So sehr ich Python auch mag, aber auch da gab es mit `md5` und `sha` zwei spezialisierte Module, bevor mit `hashlib` endlich eine vereinheitlichte API entstand.
Fairer Weise muss man natürlich zugeben, dass gegen bouncycastle eh alles andere abstinkt... leider gibt es dafür nur Libs für die JVM und die CLR.
Dennoch krankt es bei PHP nach wie vor an einer klaren Linie. Wobei ich dabei eh schon denke: Wenn man PHP so verbesserte, dass die eklatanten Designfehler verschwänden, so würde man eh bei etwas bereits existierenden landen
> Das könnte man auch von while und anderen Alltäglichkeiten sagen.
Das ist grundlegend falsch. Jeder Mensch mit Grundkenntnissen der Berechenbarkeit (also in der Regel jeder, ernsthaft mit Computern beschäftigt) weiß, dass gilt: LOOP ⊆ WHILE = GOTO
> Bei PHP ist man eben der Ansicht, dass Verschlüsselung letztlich Low level ist [...]
Würde mich nicht überraschen, wenn das tatsächlich so wäre. Jedenfalls mach die PHP Entwickler mal wieder alle anstallten, damit sich die Anwender nicht mit der Sicherheit ihrer Anwendungen auseinander setzen müssen. Die Folge kann man fast täglich auf Heise beobachten, wenn es mal wieder heißt: Datenraub bei xy.
Wie man so etwas vernünftig finden kann, ist mir schleierhaft.
"Jedenfalls mach die PHP Entwickler mal wieder alle anstallten, damit sich die Anwender nicht mit der Sicherheit ihrer Anwendungen auseinander setzen müssen. "
Die PHP Entwickler sind Pragmatiker, sie versuchen die Probleme zu lösen, anstatt sie nur zu bedauern. Low-Level Funktionen gibt es in PHP für dieses Thema schon ewig, doch genutzt werden sie nicht. Daran können die PHP Entwickler selbst kaum etwas ändern, der Aufklärungsaufwand für ein solch komplexes Thema ist zu groß, zumal es bereits sehr viele sehr gute Anleitungen zu dem Thema gibt, die dennoch alle ignoriert werden.
Was die Entwickler aber tun können, ist es den Aufwand zur Nutzung dieser Low Level Funktionen zu erleichtern. Ein Wrapper ist eine übliche Lösung hierfür. Das ist in der Macht der Entwickler der Sprache, und diese nutzen sie, um die allgemeine Situation zu verbessern. Gerade WEIL sie das tun, liest man heute deutlich seltener von PHP Problemen. Sie reagieren auf Kritik durchaus. Auch dies hier ist eine solche Reaktion, um die Situation zu entschärfen.
Funktionen zur sicheren Handhabung von Passwörtern anzubieten ist eine absolut sinnvolle Funktion. Wrapper sind normal und kommen in jeder Sprache vor. PHP trennt hier schlicht nur nicht zwischen Sprache und Libs. Das ist aber auch nicht zwingend notwendig, zumal es für den normalen Entwickler, der sich PHP bedient, auch nur selten einen Unterschied macht.
Am Ende zählt: PHP bietet eine spezifische Lösung für ein spezifisches Problem an. Das ist, was PHP schon immer tat, ist PHP doch selbst eine solche spezifische Lösung für ein sehr spezifisches Problem (Webentwicklung). Deswegen nutzen die Menschen PHP. PHP ist praxisorientiert, und damit eben erfolgreich.
By the way, ich siehe Python vor. Nur falls einige jetzt gleich "Fanboy" schreien wollen. Ich sehe nur schlicht, warum andere eben PHP vorziehen.
Von zettberlin am Sa, 15. September 2012 um 17:43 #
> dass gilt: LOOP ⊆ WHILE = GOTO
Danke für den Hinweis, while war sicherlich kein gutes Beispiel. Worauf ich hinaus wollte: man kann das, was man mit while quasi-automatisch bekommt auch mit for machen so in der Art:
for($i=0;$i< $foo;++$i)
statt:
while($i< $length)
Zitat: Die Folge kann man fast täglich auf Heise beobachten, wenn es mal wieder heißt: Datenraub bei xy.
Dass PHP-Seiten häufig gecrackt werden, hat sehr viele Gründe. Zunächst mal den, dass es so viele davon gibt.
Ich behaupte, wenn es PHP gar nicht geben würde und stattdessen Webseiten mit besser designeten Sprachen gemacht werden würden, würde es trotzdem viele erfolgreiche Einbrüche geben. Weil die meisten erfolgreichen Einbrüche wegen absolut hanebüchener Fehler beim *Umgang mit der Technik* gelingen.
6-Zeichen-Passwörter, die in gängigen Wörterbüchern stehen und die Jahrelang unverändert bleiben. Hunderte FTP oder auch SSH Zugänge für Kunden, die keinen blassenSchimmer haben. Krude, aufgeblähte all-in-one Webfrontends zur Serververwaltung. Schlecht bezahltes, überlastetes Personal.
Und was der Preiskampf sonst noch für Colatteralschäden verursacht.
Man kann mit PHP sehr sichere Webanwendungen programmieren, das dauert dann aber zuweilen auch etwas länger und erfordert ein vernünftig ausgedachtes Konzept, für das der Kunde wenigstens sagen können muss, was er denn nun genau haben will.
Wenn nun ein Wrapper es ermöglicht, schneller zu einem akzeptablen Ergebnis zu kommen, dann wird das wahrscheinlich die Situation verbessern helfen. Noch besser wäre ein allgemeines Umdenken besonders bei der Kundschaft und überhaupt im ganzen System: wie wahrscheinlich ist es denn, dass das demnächst stattfindet?
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 15. Sep 2012 um 17:46.
Ich benutze sehr selten ``while``-Schleifen; in Python fast nie. Wozu auch? Sofern man die Anzahl an Elementen kennt, ist eine ``for``-Schleife immer vorzuziehen - und kennt man sie nicht, so bedeutet das auch nicht zwangsweise eine ``while``-Schleife zu benutzen.
Dass es so viele unsicherer PHP-Seiten gibt, liegt schlicht und ergreifen daran, dass es im PHP-Umfeld Usus ist, alles selber zu bauen! Logisch, man kann ja in der Sprache eher schwer mit CLI anfangen und zwingt Einsteiger somit unmittelbar zur Webprogrammierung. Damit können sie aber gängige Frameworks zu Beginn noch nicht benutzen, da ihnen die Grundlagen der Sprache fehlen... somit fängt jedes Tut mit POST-Parameter-Parsing, selbst gebauten Formularen und einer selbstgebauten Anbindung an MySQL an... damit sind sämtlichen gängigen Attacken Tür und Tor geöffnet und der Programmierer wird zu einem NIH-Jünger "erzogen".
Eine universell einsetzbare Sprache ermöglicht es einem Anfänger, *erst* die Grundlagen zu lernen und *dann* mit Hilfe eines Webframeworks eine von Beginn an sicherere Applikation zu bauen.
Naja ... Programmierer müssen erzogen werden. Eine Sprache die sich auch an Anfänger richtet sollte dies automatisch machen. Denkbar wäre z.B. das man keine zusammengebauten Strings an die SQL Funktionen übergeben kann sondern dazu gezwungen wird prepared statements (oder einen Sprach-eigenen SQL-Builder) zu nutzen. Vieles hat sich PHP durch fehlenden initialisierungszwang von Variablen, einstellbaren Error-Leveln, register_globals (schauder) etc.. eingebrockt. Auf der anderen Seite, die Sprache ist der Qualität ihres eigenen Sprachkerns entwachsen - sie war wohl eher als eine art shell-script fürs web gedacht.
Hatten wir doch gerade in der Diskussion zu Symphonie: wer sich ernsthaft mit PHP beschäftigt, kommt beizeiten an Punkte, an denen man es sich irgendwie besser wünscht.
Schön, dass dem PHP-Team das bewusst zu sein scheint
Dem kann ich nun gar nicht zustimmen.
Was hier geboten wird ist doch keine neue Funktionalität, sondern nur ein Wrapper auf Funktionen, die schon lange existieren. Der Kasus Knaxus ist doch, dass PHP Entwickler offenbar nicht in der Lage sind, diese Funktionen korrekt einzusetzen, und dass die PHP Community dafür keine bessere Lösung sieht, als die Sprache weiter zu verhackstückeln.
Woran es mangelt ist Aufklärung und ein vernünftiges Sprachkonzept, kein "Wir tun mal so, als wären wir noch in den 90ern"-Gehabe.
> nur ein Wrapper auf Funktionen, die schon lange existieren
Das könnte man auch von while und anderen Alltäglichkeiten sagen. PHP ist eben eine spezialisierte Scriptsprache für einen beschränkten Bereich von Anwendungen, keine LowLevel Sprache, mit der irgendwer Gerätetreiber der dergleichen schreiben will.
Da geht es weniger um Technik und mehr um Logik.
> offenbar nicht in der Lage sind, diese Funktionen korrekt einzusetzen,
Bei PHP ist man eben der Ansicht, dass Verschlüsselung letztlich Low level ist, das nur Sicherheitsexperten im Detail beherrschen müssen. Für einen Anwendungsentwickler sollte es reichen, dass er/ sie weiß, was Verschlüsselung ist und wie man sie im Kontext einer Anwendung benutzt.
Das finde ich durchaus vernünftig.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 14. Sep 2012 um 14:28.Als Entwickler sollte man sich bewusst sein was es bedeutet einen bestimmten Verschlüsselungsalgorithmus zu wählen.
Das hat für mich nichts mit LowLevel zu tun. Natürlich ist es schön wenn einem die Programmiersprache etwas abnimmt. Allerdings sollte es nicht dazu verleiten, dass man sich mit wichtigen Themen nicht oder unzureichend auseinander setzt.
Genau das kann dann nämlich wieder zu Sicherheitslücken führen und der Anwender muss dann wieder unter den Folgen leiden.
>Als Entwickler sollte man sich bewusst sein was es bedeutet einen bestimmten Verschlüsselungsalgorithmus zu wählen.
Damit hast Du natürlich Recht. Aber das ist dann andererseits auch in der Verantwortung des Entwicklers: die neue Funktion verheimlicht den Algoritmus ja nicht und man kann das ganze nach wie vor auch per Hand machen.
Wer einen Nutzer mit adduser anlegt, hat dabei auch keinen direkten Zugang zur Methode der Passwortverschlüsselung. Und den Admin möchte ich sehen, der nicht normalerweise adduser oder was vergleichbares benutzt, wenn ein neuer Account gebraucht wird.
>Allerdings sollte es nicht dazu verleiten, dass man sich mit wichtigen Themen
>nicht oder unzureichend auseinander setzt.
Die Welt ist nunmal nicht perfekt, was auch an beschränkter Zeit liegt. Der Tag hat im gegensatz zur CPU leider einen festen Multiplikator von 24.
Grundsätzlich sehe ich keinen Unterschied zwischen Passwortsicherheit oder etwa CPU Optimierung: Der Entwickler ist besser beraten sich auf den Anwender als auf die Hardware zu konzentrieren. In Sprachen wie C, C++, Java etc... gibt es Bibliotheken die einem eine vernünftige best-effort Sicherheit einfach zur Verfügung stellen, in PHP, einer Sprache mit einem einzigen Anwendungsfall, kann dies durchaus in die Sprache integriert werden. Zieht man die übliche Betriebsweise von PHP in die Betrachtung mit ein, macht das sogar noch viel mehr sinn. Der Nutzer der Anwendung ist als üblicher Schwachpunkt in punkto Updates aussen vor - die Verantwortung trägt der Provider, der damit besser umgehen kann - falls nicht, bereinigt dies der Markt ganz von alleine.
`while` ist doch kein Wrapper sondern ein Schlüsselwort... insofern ist der Vergleich falsch. Zudem ist eine "weitere Funktion" schon ein Problem! Ein sauberes API für Verschlüsselung ist das A und O. Das Sortieren ist doch ein klassisches Beispiel für das miserable API-Design in PHP. Wieso gibt es für jeden Datentypen eine separate Funktion? Wieso wird das nicht wie in jeder gut designten Sprache über FOF / Interfaces oder vergleichbares gelöst?
So sehr ich Python auch mag, aber auch da gab es mit `md5` und `sha` zwei spezialisierte Module, bevor mit `hashlib` endlich eine vereinheitlichte API entstand.
Fairer Weise muss man natürlich zugeben, dass gegen bouncycastle eh alles andere abstinkt... leider gibt es dafür nur Libs für die JVM und die CLR.
Dennoch krankt es bei PHP nach wie vor an einer klaren Linie. Wobei ich dabei eh schon denke: Wenn man PHP so verbesserte, dass die eklatanten Designfehler verschwänden, so würde man eh bei etwas bereits existierenden landen
> Das könnte man auch von while und anderen Alltäglichkeiten sagen.
Das ist grundlegend falsch. Jeder Mensch mit Grundkenntnissen der Berechenbarkeit (also in der Regel jeder, ernsthaft mit Computern beschäftigt) weiß, dass gilt: LOOP ⊆ WHILE = GOTO
> Bei PHP ist man eben der Ansicht, dass Verschlüsselung letztlich Low level ist [...]
Würde mich nicht überraschen, wenn das tatsächlich so wäre.
Jedenfalls mach die PHP Entwickler mal wieder alle anstallten, damit sich die Anwender nicht mit der Sicherheit ihrer Anwendungen auseinander setzen müssen. Die Folge kann man fast täglich auf Heise beobachten, wenn es mal wieder heißt: Datenraub bei xy.
Wie man so etwas vernünftig finden kann, ist mir schleierhaft.
"Jedenfalls mach die PHP Entwickler mal wieder alle anstallten, damit sich die Anwender nicht mit der Sicherheit ihrer Anwendungen auseinander setzen müssen. "
Die PHP Entwickler sind Pragmatiker, sie versuchen die Probleme zu lösen, anstatt sie nur zu bedauern. Low-Level Funktionen gibt es in PHP für dieses Thema schon ewig, doch genutzt werden sie nicht.
Daran können die PHP Entwickler selbst kaum etwas ändern, der Aufklärungsaufwand für ein solch komplexes Thema ist zu groß, zumal es bereits sehr viele sehr gute Anleitungen zu dem Thema gibt, die dennoch alle ignoriert werden.
Was die Entwickler aber tun können, ist es den Aufwand zur Nutzung dieser Low Level Funktionen zu erleichtern. Ein Wrapper ist eine übliche Lösung hierfür. Das ist in der Macht der Entwickler der Sprache, und diese nutzen sie, um die allgemeine Situation zu verbessern.
Gerade WEIL sie das tun, liest man heute deutlich seltener von PHP Problemen. Sie reagieren auf Kritik durchaus. Auch dies hier ist eine solche Reaktion, um die Situation zu entschärfen.
Funktionen zur sicheren Handhabung von Passwörtern anzubieten ist eine absolut sinnvolle Funktion. Wrapper sind normal und kommen in jeder Sprache vor. PHP trennt hier schlicht nur nicht zwischen Sprache und Libs. Das ist aber auch nicht zwingend notwendig, zumal es für den normalen Entwickler, der sich PHP bedient, auch nur selten einen Unterschied macht.
Am Ende zählt: PHP bietet eine spezifische Lösung für ein spezifisches Problem an. Das ist, was PHP schon immer tat, ist PHP doch selbst eine solche spezifische Lösung für ein sehr spezifisches Problem (Webentwicklung). Deswegen nutzen die Menschen PHP.
PHP ist praxisorientiert, und damit eben erfolgreich.
By the way, ich siehe Python vor. Nur falls einige jetzt gleich "Fanboy" schreien wollen. Ich sehe nur schlicht, warum andere eben PHP vorziehen.
> dass gilt: LOOP ⊆ WHILE = GOTO
Danke für den Hinweis, while war sicherlich kein gutes Beispiel. Worauf ich hinaus wollte: man kann das, was man mit while quasi-automatisch bekommt auch mit for machen so in der Art:
for($i=0;$i< $foo;++$i)
statt:
while($i< $length)
Zitat:
Die Folge kann man fast täglich auf Heise beobachten, wenn es mal wieder heißt: Datenraub bei xy.
Dass PHP-Seiten häufig gecrackt werden, hat sehr viele Gründe. Zunächst mal den, dass es so viele davon gibt.
Ich behaupte, wenn es PHP gar nicht geben würde und stattdessen Webseiten mit besser designeten Sprachen gemacht werden würden, würde es trotzdem viele erfolgreiche Einbrüche geben. Weil die meisten erfolgreichen Einbrüche wegen absolut hanebüchener Fehler beim *Umgang mit der Technik* gelingen.
6-Zeichen-Passwörter, die in gängigen Wörterbüchern stehen und die Jahrelang unverändert bleiben.
Hunderte FTP oder auch SSH Zugänge für Kunden, die keinen blassenSchimmer haben.
Krude, aufgeblähte all-in-one Webfrontends zur Serververwaltung.
Schlecht bezahltes, überlastetes Personal.
Und was der Preiskampf sonst noch für Colatteralschäden verursacht.
Man kann mit PHP sehr sichere Webanwendungen programmieren, das dauert dann aber zuweilen auch etwas länger und erfordert ein vernünftig ausgedachtes Konzept, für das der Kunde wenigstens sagen können muss, was er denn nun genau haben will.
Wenn nun ein Wrapper es ermöglicht, schneller zu einem akzeptablen Ergebnis zu kommen, dann wird das wahrscheinlich die Situation verbessern helfen. Noch besser wäre ein allgemeines Umdenken besonders bei der Kundschaft und überhaupt im ganzen System: wie wahrscheinlich ist es denn, dass das demnächst stattfindet?
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 15. Sep 2012 um 17:46.Ich benutze sehr selten ``while``-Schleifen; in Python fast nie. Wozu auch? Sofern man die Anzahl an Elementen kennt, ist eine ``for``-Schleife immer vorzuziehen - und kennt man sie nicht, so bedeutet das auch nicht zwangsweise eine ``while``-Schleife zu benutzen.
Dass es so viele unsicherer PHP-Seiten gibt, liegt schlicht und ergreifen daran, dass es im PHP-Umfeld Usus ist, alles selber zu bauen! Logisch, man kann ja in der Sprache eher schwer mit CLI anfangen und zwingt Einsteiger somit unmittelbar zur Webprogrammierung. Damit können sie aber gängige Frameworks zu Beginn noch nicht benutzen, da ihnen die Grundlagen der Sprache fehlen... somit fängt jedes Tut mit POST-Parameter-Parsing, selbst gebauten Formularen und einer selbstgebauten Anbindung an MySQL an... damit sind sämtlichen gängigen Attacken Tür und Tor geöffnet und der Programmierer wird zu einem NIH-Jünger "erzogen".
Eine universell einsetzbare Sprache ermöglicht es einem Anfänger, *erst* die Grundlagen zu lernen und *dann* mit Hilfe eines Webframeworks eine von Beginn an sicherere Applikation zu bauen.
Naja ... Programmierer müssen erzogen werden. Eine Sprache die sich auch an Anfänger richtet sollte dies automatisch machen. Denkbar wäre z.B. das man keine zusammengebauten Strings an die SQL Funktionen übergeben kann sondern dazu gezwungen wird prepared statements (oder einen Sprach-eigenen SQL-Builder) zu nutzen. Vieles hat sich PHP durch fehlenden initialisierungszwang von Variablen, einstellbaren Error-Leveln, register_globals (schauder) etc.. eingebrockt. Auf der anderen Seite, die Sprache ist der Qualität ihres eigenen Sprachkerns entwachsen - sie war wohl eher als eine art shell-script fürs web gedacht.