nicht angemeldet
Auge
dedlfix
Der Martin
dedlfix
Der Martin
Matthias Apsel
Der Martin
Hallo,
ich habe mich gerade durch diese Anleitung zur Benutzer-Verwaltung gelesen. Dort werden die Nutzerdaten direkt in Dateien auf dem Server abgelegt. Dabei kam die Frage auf, wieso die Daten nicht direkt in die Datenbank geschrieben werden. Gibt es bei der Verwendung von Dateien einen Vorteil gegenüber zwei Tabellen in einer Datenbank, der es rechtfertigt, den Geschwindigkeitsvorteil einer Datenbank zu ignorieren und Dateien zu benutzen?
Vielen Dank
Hallo
ich habe mich gerade durch diese Anleitung zur Benutzer-Verwaltung gelesen. Dort werden die Nutzerdaten direkt in Dateien auf dem Server abgelegt. Dabei kam die Frage auf, wieso die Daten nicht direkt in die Datenbank geschrieben werden. Gibt es bei der Verwendung von Dateien einen Vorteil gegenüber zwei Tabellen in einer Datenbank, der es rechtfertigt, den Geschwindigkeitsvorteil einer Datenbank zu ignorieren und Dateien zu benutzen?
Da auch Datenbanken die Daten in Dateien ablegen und überdies die Zugriffe verwalten müssen, sollte der Geschwindigkeitsvorteil auf Seiten der Dateien liegen. Andererseits vereinfachen Datenbanksysteme den eigenen Aufwand, auf die Daten zuzugreifen, erheblich.
Im angesprochenen Fall hat der Autor halt eine der Datenablagearten gewählt. Es ist die Ablage der Benutzerdaten in Dateien geworden. Das funktioniert halt überall.
Tschö, Auge
Hm. Was war denn daran jetzt falsch?
Ab (willkürliche Zahl:)tausend Benutzern ist die Datenbank zwar womöglich schneller aber im Grunde ist die Aussage von Auge doch zutreffend.
Hm. Was war denn daran jetzt falsch?
Ab (willkürliche Zahl:)tausend Benutzern ist die Datenbank zwar womöglich schneller aber im Grunde ist die Aussage von Auge doch zutreffend.
Ich erhöhe auf 10 Tausend ;)
Tach!
ich habe mich gerade durch diese Anleitung zur Benutzer-Verwaltung gelesen. Dort werden die Nutzerdaten direkt in Dateien auf dem Server abgelegt. Dabei kam die Frage auf, wieso die Daten nicht direkt in die Datenbank geschrieben werden.
Diese Frage wird vom Artikel selbst beantwortet.
"Hier sind sowohl Benutzername als auch Passwort in einer Datei .htpasswd gespeichert - denkbar wäre aber zum Beispiel auch die Abfrage von Benutzerdaten aus einer Datenbank. Deshalb wurde auch das Holen des gehashten Passwortes in einer Funktion untergebracht. Diese ist hierdurch leicht austauschbar."
"Eine Datei mit Benutzernamen und Passwörtern für die hier vorgestellten Skripte sähe (ungefähr) wie folgt aus: [...] und würde, weil diese den gleichen Aufbau hat, auch die native Möglichkeit des Apache (ab 2.4!) für die Authentifizierung mit htaccess unterstützen."
dedlfix.
Es kann dafür Gründe geben: man hat entweder keinen SQL-Server zur Verfügung, oder es ist ein Embeddedsystem mit zu wenig Leistung, oder die Anforderungen sind sehr gering. Aber i.d.R. macht das Rumgehampel mit Dateien wenig Sinn, die Implementierung dauert länger, Wartungsaufwand steigt, keine nennenswerten Features vorhanden, Performance im Keller und man bekommt vorallem schnell Probleme mit ACID. Und sich dann noch selber ein Format ausdenken, statt z.B. JSON zu benutzen halte ich für ziemlichen fail. Im einfachsten Fall kann man wenigstens SQLite einsetzen.
Hi,
ich habe mich gerade durch diese Anleitung zur Benutzer-Verwaltung gelesen.
Dort werden die Nutzerdaten direkt in Dateien auf dem Server abgelegt. Dabei kam die Frage auf, wieso die Daten nicht direkt in die Datenbank geschrieben werden. Gibt es bei der Verwendung von Dateien einen Vorteil gegenüber zwei Tabellen in einer Datenbank, der es rechtfertigt, den Geschwindigkeitsvorteil einer Datenbank zu ignorieren und Dateien zu benutzen?
bist du denn sicher, dass die Verwendung einer Datenbank tatsächlich einen Geschwindigkeitsvorteil bringt? - Ich will das zwar nicht ausschließen, aber ich könnte mir ebensogut vorstellen, dass bei diesem einfachen Beispiel ein eventueller Geschwindigkeitsvorteil beim Zugriff auf die Daten durch administrativen Overhead (Connect zur Datenbank) wieder aufgezehrt wird, zumal ja letzten Endes auch die DB auf Dateien zugreifen muss.
Außerdem ist die Datenmenge bzw. die Anzahl der Zugriffe so gering, dass der Unterschied in der Praxis mit an Sicherheit grenzender Wahrscheinlichkeit nicht auffällt.
So long,
Martin
Hallo,
ich habe mich gerade durch diese Anleitung zur Benutzer-Verwaltung gelesen. Dort werden die Nutzerdaten direkt in Dateien auf dem Server abgelegt. Dabei kam die Frage auf, wieso die Daten nicht direkt in die Datenbank geschrieben werden. Gibt es bei der Verwendung von Dateien einen Vorteil gegenüber zwei Tabellen in einer Datenbank, der es rechtfertigt, den Geschwindigkeitsvorteil einer Datenbank zu ignorieren und Dateien zu benutzen?
Interessanter ist diese überaus zukunftorientierte Frage: Wie schaffe ich eine einheitliche Datenstruktur so, dass es der Anwendung egal ist wo die Daten gespeichert sind?
Tach!
Interessanter ist diese überaus zukunftorientierte Frage: Wie schaffe ich eine einheitliche Datenstruktur so, dass es der Anwendung egal ist wo die Daten gespeichert sind?
Man kann Helfer entwerfen, die bestimmte Datenstrukturen für das Speichern in bestimmten Ablagen passend konvertieren können. Man muss sich bei der Datenstruktur nicht so einschränken, dass sie universell speicherbar ist. Dass der Geschäftslogik die Speicherung egal sein soll, klar, aber dann auch konsequent und nicht eine aufs Speichern optimierte Sozialistische Einheits-Datenstruktur als Zwang voraussetzen.
dedlfix.
Dabei kam die Frage auf, wieso die Daten nicht direkt in die Datenbank geschrieben werden.
Datenbank ist nicht immer schneller als Textdatei. Bei wenigen Nutzern dürfte die Datenbank im Nachteil sein. "Wenige Nutzer" meint "geschätzt unter tausend" - was aber von vielen und sehr verschiedenen, sich aber auf "Dateisystem" und "Speicher" konzentrierenden Umständen abhängt - es können eben so gut 12 wie 12.000 sein.
Wie auch immer. Das bildet die Interessen der Mehrheit derjenige ab, die das wohl lesen. Wer indes mehr als "zehn" Nutzer einrichten will, der hat hoffentlich einen Profi (Damen ohne explizite Nennung inkludiert) der/die den Artikel nicht braucht oder selbst schreiben könntze. Falls nicht sollte der Geschäftsherr im eigenen Interesse was am Arbeitsmarkt tun oder sich einen Profi (sexus wie vor) mieten.
Außerdem hat dedlfix DAS folgende, fast nicht schlagbare Argument gefunden:
"Eine Datei mit Benutzernamen und Passwörtern für die hier vorgestellten Skripte sähe (ungefähr) wie folgt aus: [...] und würde, weil diese den gleichen Aufbau hat, auch die native Möglichkeit des Apache (ab 2.4!) für die Authentifizierung mit htaccess unterstützen."
Bedeutet das man diese Textdatei auch für die Zugang via http-auth verwenden und zwar ohne eine Datenbank benutzen zu müssen, was auf shared Servern regelmäßig nicht möglich ist.
Logisch ist auch, dass eine Lösung beschrieben wird, die zeigbare Ergebnisse aufweist und überall verwendbar ist. Das trifft für Textdateien zu.
ich habe mich gerade durch diese Anleitung zur Benutzer-Verwaltung gelesen.
Vergiss den Artikel schnellst möglich. Lies besser hier weiter http://symfony.com/doc/current/book/security.html oder hier https://framework.zend.com/manual/2.4/en/modules/zend.authentication.intro.html
Es gibt keine Anhaltspunkte dafür, dass das Loginsystem aus unserem Wiki-Artikel nach irgendeinem Maßstab sicher ist. Im Gegenteil, einige Sicherheitslücken sind hier bereits diskutiert worden, mindestens eine davon ist immer noch präsent, wie ich gerade beim Überfliegen gemerkt habe. Wir haben leider keine Ersatz in unserem Wiki. Die Dokumentationen etablierter Frameworks sind hier aber zu empfehlen.
Es gibt keine Anhaltspunkte dafür, dass das Loginsystem aus unserem Wiki-Artikel nach irgendeinem Maßstab sicher ist.
Boah! Pofalla-Style?"
Ich habe mir das angeschaut. Was da "Dokumentation" genannt wird enthält für mich kaum verwertbare Informationen. Oder hast Du die verlinkten Seiten nicht gemeint?
Im Gegenteil, einige Sicherheitslücken sind hier bereits diskutiert worden, mindestens eine davon ist immer noch präsent
Als da wäre? "Butter bei die Fische", Herr Pofalla!
Ich habe mir das angeschaut. Was da "Dokumentation" genannt wird enthält für mich kaum verwertbare Informationen.
Okay, kann man dir da helfen, scheiterst du am Englisch, am Schreibstil, an technischen Hürden oder an etwas ganz anderem? Das sind jedenfalls zwei der prominentesten und technisch am weitesten entwickelten Frameworks im PHP-Kosmos. Wenn man eine Anlaufstelle für PHP-Sicherheit sucht, dann ist man dort schon an einer guten Adresse. Computer-Sicherheit gehört halt zu den schwierigsten Disziplinen in der Informatik und vieles ist eben nicht so einfach und demzufolge auch nicht einfach zu erklären. In der Selfhtml-Community sind unsere Kompetenzen in diesem Bereich leider auch unterrepräsentiert (ich bin da keine Ausnahme). Gerade deshalb sehe ich unsere Pflicht eher darin unsere Leserschaft zu sensibilisieren und ihnen nicht mit eigenen, leider minderwertigen Lösungen zu begegnen.
Im Gegenteil, einige Sicherheitslücken sind hier bereits diskutiert worden, mindestens eine davon ist immer noch präsent
Als da wäre?
Das Loginsystem erkennt nicht, wenn es auf einer PHP-Version kleiner als 5.5 ausgeführt wird. Dabei gibt es für ältere Versionen keine Security-Fixes mehr (für PHP 5.5 fallen sie in 10 Tagen dann auch weg). Im Artikel werden sogar noch angeblich wirkungsvolle Polyfills serviert – das ist, mit Verlaub, Schalatanerei. Und selbst wenn das irgendwann behoben werden sollte, bleibt der fade Beigeschmack eines völlig unerprobten Loginsystems erhalten: Es gibt keinen einzigen Test, keinen offiziellen Maintainer, niemanden der die Abhängigkeiten oder CVE-Listen observiert und den Artikel diesbezüglich aktualisiert. Wirklich niemand will so ein Risiko eingehen.
Ich habe mir das angeschaut. Was da "Dokumentation" genannt wird enthält für mich kaum verwertbare Informationen.
Okay, kann man dir da helfen, scheiterst du am Englisch, am Schreibstil, an technischen Hürden oder an etwas ganz anderem?
Ok. Fangen wir wir mit der "Installationsanleitung" an.
~$ composer require zendframework/zendframework [ENTER]
Der Befehl »composer« wurde nicht gefunden, meinten Sie vielleicht:
Befehl »compose« aus dem Paket »mime-support« (main)
composer: Befehl nicht gefunden.
Unbrauchbarer kann eine Dokumentation wohl kaum sein. Wer sagt mir unter diesen Umständen, dass es sicher ist?
Aber halt! Da ist ja ein Link zu https://getcomposer.org/download/
ok. Dort steht, ich soll:
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php -r "if (hash_file('SHA384', 'composer-setup.php') === 'e115a8dc7871f15d853148a7fbac7da27d6c0030b848d9b3dc09e2a0388afed865e6a3d6b3c0fad45c48e2b5fc1196ae') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
php composer-setup.php
php -r "unlink('composer-setup.php');"
ausführen.
Also cd /tmp, und den Quatsch unter heftigem Protest aber nur mit User-Rechten gemacht (als root kommt nicht Frage und wurde auch nicht gefordert). Läuft durch:
~$ cd /tmp[ENTER]
/tmp$ php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"[ENTER]
/tmp$ php -r "if (hash_file('SHA384', 'composer-setup.php') === 'e115a8dc7871f15d853148a7fbac7da27d6c0030b848d9b3dc09e2a0388afed865e6a3d6b3c0fad45c48e2b5fc1196ae') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"[ENTER]
Installer verified
/tmp$ php composer-setup.php[ENTER]
All settings correct for using Composer
Downloading 1.1.3...
Composer successfully installed to: /tmp/composer.phar
Use it: php composer.phar
/tmp$ php -r "unlink('composer-setup.php');"[ENTER]
Nett, dass für einen Download, die Verifizierung eines Hashes (der vom selben Server auf dem selben Weg kommt...sic: was für eine beschissene Sicherheit bekomme ich hier vom Installer eines angeblich sicheren Frameworks geboten?) und für das Löschen einer Datei PHP benutzt wird...
So! Testen wir jetzt mal den Aufruf:
/tmp$ composer require zendframework/zendframework[ENTER]
Der Befehl »composer« wurde nicht gefunden, meinten Sie vielleicht:
Befehl »compose« aus dem Paket »mime-support« (main)
composer: Befehl nicht gefunden.
Genau so geht "Die Dokumentation ist unbrauchbar." Und ein Framework, welches einen unsicheren Download voraussetzt und mir "Sicherheit" nur vorgaukelt, den eigenen Setup dann definitiv falsch beschreibt - wie sicher kann dieses Framework wohl sein? Und warum sollte ich oder sonstwer annehmen, dass das Framework oder dessen ähnlich unbrauchbar beschriebenes Loginsystem "nach irgendeinem Maßstab sicher ist"?
Hinweis:
Mir ist auf einem Blick bewusst, dass das Setup-Problem mit einem alias composer="php composer.phar" zu beheben ist. Geschätzten 2 Milliarden anderen, eigentlich hinreichend der englischen Sprache mächtigen Menschen nicht...
Du hast Probleme mit der Composer-Installation. Sicherlich nicht schön, aber deine schlechten Erfahrungen nun als Beweisführung für angebliche mangelnde Sicherheitskompetenzen des Zend-Teams anzuführen ist schon ark an den Haaren herbeigezogen.
Btw: Für den Code im Wiki gibt es überhaupt keine Installations-Anleitung. Der Leser ist gezwungen sich die Dateien selbst zusammen zu kopieren und Abhängigkeiten per Hand aufzulösen.
Nett, dass für einen Download, die Verifizierung eines Hashes (der vom selben Server auf dem selben Weg kommt...sic: was für eine beschissene Sicherheit bekomme ich hier vom Installer eines angeblich sicheren Frameworks geboten?) und für das Löschen einer Datei PHP benutzt wird...
Der Weg über den die Daten kommen, kann dir egal sein, die Gegenstelle weist sich ja mit einem SSL-Zertifikat aus. Und ob die Daten vom selben Server kommen, kannst du überhaupt nicht wissen. Du siehst die selbe Domain, aber das verrät dir nichts über die dahinterliegende Infrastruktur. Und auch hier gilt wieder: Der Wiki-Artikel bietet überhaupt kein Prüfsummen-Verfahren an.
Und ein Framework, welches einen unsicheren Download voraussetzt und mir "Sicherheit" nur vorgaukelt, den eigenen Setup dann definitiv falsch beschreibt -
Nein, du hast die Faktenlage nur falsch eingeschätzt. Weder der Download-Prozess noch das Prüfsummenverfahren sind hier von einer Schwachstelle kompromittiert. Wenn du solche Anschuldigen erhebst, sollte da schon eine qualifizierte Beweisführung hinter stecken, und kein flaues Bauchgefühl.
wie sicher kann dieses Framework wohl sein? Und warum sollte ich oder sonstwer annehmen, dass das Framework oder dessen ähnlich unbrauchbar beschriebenes Loginsystem "nach irgendeinem Maßstab sicher ist"?
Zum einen hast du ein renommiertes Entwicklerteam: Zend ist auch offizieller Maintainer des PHP-Interpreters. Wenn du diesem Team nicht zutraust ein sicheres System zu entwickeln, dann solltest du am besten gar kein Loginsystem auf PHP schultern.
Zweites hat das Zend-Framework eine riesige Nutzerbasis (~60.000.000 Installationen nach Hersteller-Angaben). Das ist also ein erprobtes System.
Und du hast Software-Tests, die dir die partielle Korrektheit des Login-System garantieren können. Das Loginsystem aus unserem Wiki ist nicht nur ungetestet, sondern auch untestbar wegen diverser Codesmells, z.B. die exit-Statements.
Außerdem ist das Zend-Team an ernsthaften Sicherheitsbedenken interessiert und pflegt eine offene Diskussionskultur. Dort werden Bedenken nicht einfach dementiert und klein geredet, wie zuletzt leider durch den Autor unseres Artikels geschehen. Diese Kritikunfähigkeit ist ein weiterer Punkt, wieso ich dieser Quelle lieber nicht traue.
Zweites hat das Zend-Framework eine riesige Nutzerbasis (~60.000.000 Installationen nach Hersteller-Angaben).
Au ja. Millionen Fliegen haben Recht. Und deren Zahl wird oft unrealistisch ermittelt. Seit gestern Abend sind der Zählung nach wahrscheinlich 60.000.001 - nur war diese Installation in /tmp ... und wurde beim Neustart gelöscht.
Das ist also ein erprobtes System.
Mit erheblichen Schwächen in der Dokumentation, die dafür sorgen können, dass ein Unwissender bei der Verwendung des Frameworks schwere Fehler macht. Und ich will nicht derjenige sein, der behauptet, dass diese Schwächen womöglich gewollt sein könnten, weil Zend ja auch irgendwas verkaufen muss. Hier wären das wohl Support und Schulungen.
Und du hast Software-Tests, die dir die partielle Korrektheit des Login-System garantieren können.
Software-Tests, die vom Hersteller der Software stammen taugen für mich ebenso viel wie die Abgastests von VW. Das ich bei meinen eigenen Test meiner eigenen Skripte stets was übersehen werde, weil ich z.B. bestimmte Inputs einfach ausschließe weiß ich. Jetzt wüsste ich gern wer behaupten kann, dass er das (auf Grund welcher Methoden?) besser macht.
Das Loginsystem aus unserem Wiki ist nicht nur ungetestet
Den Rückfragen hier zu folge und vor allem der Versionsgeschichte zu folge arbeiten (dazu ist es WIKI) doch einige daran. Irgendwie habe ich den Eindruck, dass Du noch nicht verstanden hast, was der WIKI-Beitrag sein soll und was nicht.
Im Übrigen sind die paar Zeilen Code schnell durchgesehen und auch in höchst unübersichtlicher Weise nicht auch geschätzte 600 Dateien verteilt (ich habe auf dieser Maschine das ZEND-Framework wieder gelöscht und kann die Dateien also nicht zählen.
Und noch was. Du hast Dich darüber aufgeregt, dass "angeblich wirkungsvolle Polyfills" verbaut wären. Gemeint waren damit wohl die im Falle des Fehlens nachgebauten password_* Funktionen.
Du hast offensichtlich übersehen, dass die password_* Funktionen in PHP offensichtlich nur Mäntel sind, welch dem Programmierer die Arbeit erleichtern, weil viele PHP-Benutzer mit dem bcrypt-Zeug nicht zu Rande kamen.
Soll ich das ZEND-Framework mal nach solchen durchsuchen? Ich vermute nämlich, dass gerade in solchen Frameworks auch die Unterschiede zwischen den PHP-Versionen ausgeglichen werden müssen oder dass es sich auf den "kleinsten Nenner", also den Umfang und die Funktion der ältesten als verwendbar angegeben PHP-Version stützt. Was auch nicht immer eine gute Idee ist.
Diese Kritikunfähigkeit ist ein weiterer Punkt, wieso ich dieser Quelle lieber nicht traue.
So wie Du hier angefangen hast kann ich jeden verstehen, der Deine Kritik zurückweist. Zum Kritisieren unfähige meinen nämlich weit überdurchschnittlich häufig, dass andere "kritikunfähig" seien.
Und ich will nicht derjenige sein, der behauptet, dass diese Schwächen womöglich gewollt sein könnten, weil Zend ja auch irgendwas verkaufen muss. Hier wären das wohl Support und Schulungen.
Unsinnige Verschwörungstheorie. Auf dieses Niveau werde ich mich nicht begeben, die Debatte ist für mich beendet.
die Debatte ist für mich beendet.
Guter Beitrag. Danke.
Der Weg über den die Daten kommen, kann dir egal sein, die Gegenstelle weist sich ja mit einem SSL-Zertifikat aus. Und ob die Daten vom selben Server kommen, kannst du überhaupt nicht wissen. Du siehst die selbe Domain, aber das verrät dir nichts über die dahinterliegende Infrastruktur.
1.) Nein, es ist nicht egal. Erfolgreiche Angreifer haben weit überwiegend häufig nicht die Freundlichkeit, gültige SSL-Zertifikate durch ungültige zu ersetzen.
2.) MIR jedenfalls verrät die übereinstimmende HOST-Adresse (Nicht: "DOMAIN") genug über die Infrastruktur um zu wissen, dass derjenige, der die Datei manipulieren konnte, sehr weit überwiegend wahrscheinlich auch den Hash anpassen konnte. Derlei ist oft genug passiert. Das gilt auch dann wenn es die Adresse eines Reverse-Proxys ist oder dahinter ein NFS-Server steht.
Und jetzt mir nicht mit der Nummer, dass der SHA384-Hash nur dazu diene, die Vollständigkeit und Korrektheit des Downloadvorganges zu verifizieren. Dafür hätte md5 oder sha1 völlig gereicht. Mit SHA384 wird hier lediglich PowerPoint&Buzzword-Freunden vorgemacht, wie fürchterlich sicher das doch alles sei... und bei SOWAS bekomme ich dann die von Dir erwähnten Bauschmerzen.
Tach,
Und jetzt mir nicht mit der Nummer, dass der SHA384-Hash nur dazu diene, die Vollständigkeit und Korrektheit des Downloadvorganges zu verifizieren. Dafür hätte md5 oder sha1 völlig gereicht. Mit SHA384 wird hier lediglich PowerPoint&Buzzword-Freunden vorgemacht, wie fürchterlich sicher das doch alles sei... und bei SOWAS bekomme ich dann die von Dir erwähnten Bauschmerzen.
genau, warum nehmen wir nicht Technik, von der wir bereits wissen, dass sie zum Teil gebrochen ist, statt auf Technik zu setzen, die voraussichtlich noch ein paar Jahre an Sicherheit bieten kann. Falls es nur um Buzzwords ginge, würde man vermutlich auf das noch aktuellere SHA-3 setzen.
mfg
Woodfighter
Tach,
Und jetzt mir nicht mit der Nummer, dass der SHA384-Hash nur dazu diene, die Vollständigkeit und Korrektheit des Downloadvorganges zu verifizieren. Dafür hätte md5 oder sha1 völlig gereicht. Mit SHA384 wird hier lediglich PowerPoint&Buzzword-Freunden vorgemacht, wie fürchterlich sicher das doch alles sei... und bei SOWAS bekomme ich dann die von Dir erwähnten Bauschmerzen.
genau, warum nehmen wir nicht Technik, von der wir bereits wissen, dass sie zum Teil gebrochen ist,
So lange es nur darum geht, ob die Datei vollständig heruntergeladen wurde und das auf dem Datentransport kein Bitdreher stattfand, ist es völlig irrelevant, dass md5 und sha1 im Zusammenhang mit dem Speichern gehaschter Passwörter als "gebrochen" angesehen wird. Sogar crc32 (eher eine Art Quersumme) würde für diese Probe reichen. Mehr an Sicherheit wird hier nicht geboten, da der Hash ja aus derselben Quelle und auf dem selben Weg kommt wie die Daten. SHA384 ist hier deshalb völlig daneben.
Wer das Gegenteil zu behaupten wagt, der schaue sich an, warum md5 als broken angesehen wird und überlege bevor er schreibt! Für gehasht gespeicherte Passwörter ist die Verwendung von md5 ebenso wie sha1 oder crc32 natürlich zwischenzeitlich näher am Vorsatz als an einfacher Fahrlässigkeit, also grob fahrlässig.
Tach,
So lange es nur darum geht, ob die Datei vollständig heruntergeladen wurde und das auf dem Datentransport kein Bitdreher stattfand,
darum geht es allerdings nicht; MITM-Attacken sind auch so möglich, entweder wegen Implementationslücken (wie die problematischen Implementierungen von Diffie-Hellmann im letzten Jahr) oder lokaler.
ist es völlig irrelevant, dass md5 und sha1 im Zusammenhang mit dem Speichern gehaschter Passwörter als "gebrochen" angesehen wird.
Es ist unsinnig bei jeder Verwendung darüber nachzudenken, ob der verwendete Hash-Algorithmus für exakt diese Anwendung jetzt gebrochen ist oder nicht, das führt nur zu Fehlern und Nachahmern, die dann nicht darüber nachdenken. Problematische Algorithmen sollten schnellstmöglich durch aktuellere ersetzt werden, überall.
Wer das Gegenteil zu behaupten wagt, der schaue sich an, warum md5 als broken angesehen wird und überlege bevor er schreibt!
Du weißt (wenn du bist, wer ich denke, dass du bist), dass ich mich mit dem Thema auskenne, also versuche nicht mir das Gegenteil zu unterstellen.
mfg
Woodfighter
darum geht es allerdings nicht; MITM-Attacken sind auch so möglich, entweder wegen Implementationslücken (wie die problematischen Implementierungen von Diffie-Hellmann im letzten Jahr) oder lokaler.
Wer eine MITM-Attacke fährt wird vorliegend neben seiner eigenen Version der Downloaddatei auch seinen eigenen und stimmenden Hash anbieten bzw. übertragen - was auf Grund des "identischen" Speicherortes und Transportweges dann nämlich auch sehr leicht möglich ist.
Es sei denn natürlich er will es aus sportlichen Gründen (oder weil er dank zu geringer Erbschaftsteuern mehr Geld als Hirn hat) richtig kompliziert und teuer machen und den ursprünglichen Hash partout beibehalten.
Also taugt der Hash nur dafür um einen teilweisen Download oder aber eben einen - sehr seltenen - Bitdreher auszuschließen. Und auch wenn md5 als Methode zum Haschen von Passwörtern ausgedient hat, so ist es für diesen Zweck sogar mehr gut genug und deshalb keinesfalls so obsolet wie man das bei allzu einseitiger Fixierung auf das Hashen von Passwörtern denken könnte.
Tach,
Wer eine MITM-Attacke fährt wird vorliegend neben seiner eigenen Version der Downloaddatei auch seinen eigenen und stimmenden Hash anbieten bzw. Übertragen - was auf Grund des "identischen" Speicherortes und Transportweges auch möglich ist.
ah und das passiert in alle Fällen? Angreifer machen keine Fehler? Hashes können nicht auf einem anderen Übertragungsweg zum Enduser kommen als die Dateien selber? Es gibt definitiv Use-Cases, wo dieser Hash sinnvoll ist, auch wenn ich dir zustimme, dass er besser wäre, würde er von anderswo ausgeliefert werden.
Also taugt der Hash nur dafür um einen teilweisen Download oder aber eben einen - sehr seltenen - Bitdreher auszuschließen. Und auch wenn md5 als Methode zum Haschen von Passwörtern ausgedient hat, so ist es für diesen Zweck sogar mehr gut genug und deshalb keinesfalls so obsolet wie man das bei allzu einseitiger Fixierung auf das Hashen von Passwörten denken könnte.
Das Wiederholen deines Arguments sorgt nicht dafür, dass meine weniger sinnvoll sind.
mfg
Woodfighter
Das Wiederholen deines Arguments sorgt nicht dafür, dass meine weniger sinnvoll sind.
Nur das ich gute und sachliche Argumente vorbringe, während Du nur stur beharrst.
Passwort-Hashes sollen
Datei-Hashes sollen aber:
Damit bestehen völlig verschiedene Anforderungen an die Hashmethoden. Daraus steht aber fest, dass eine für Passwörter ideale Hashmethode für das Hashen einer Datei suboptimal ist. Aus genau diesem Grund findet man unmittelbar bei Dateidownloads regelmäßig md5 oder sha1-hashes. (Beispiel)
*) Eine andere Geschichte sind indes signierte Hashes wie bei Debian. Die sollen vor allem dann zur Verifizierung dienen wenn der Download aus unsicheren Quellen, nehmen wir das Bittorent-Protokoll erfolgt.
Dann hat man aber auch für Download und signiertem Hash verschiedene Quellen (Was im diskutierten Fall nicht vorliegt.)
Tach,
Das Wiederholen deines Arguments sorgt nicht dafür, dass meine weniger sinnvoll sind.
Nur das ich gute und sachliche Argumente vorbringe, während Du nur stur beharrst.
*gähn*
Passwort-Hashes sollen
- gesalzen werden.
- in mehreren Runden gehasht (unter erneutem Salzen) werden
- nicht zu schnell gehen. (Siehe Diskussion um das schnelle sha1)
Datei-Hashes sollen aber:
- möglichst schnell gehen, schon mal weil die zu verarbeitende Datenmenge sehr groß sein kann. Nehmen wir als Beispiel ein DVD-Image mit 4GB. Abweichung hiervon bei signierten Hashes, was aber dem diskutierten Fall nicht entspricht. Siehe unten.
- deshalb nicht gehasht werden.
- Es werden auch nicht mehrere Runden gedreht.
Damit bestehen völlig verschiedene Anforderungen an die Hashmethoden.
Was hat das mit dem Thema zu tun?
Daraus steht aber fest, dass eine für Passwörter ideale Hashmethode für das Hashen einer Datei suboptimal ist.
SHA2 ist kein guter Hash für Passworte; ich habe auch nirgendwo vorgeschlagen einen Passwort-Hash für Dateien zu verwenden. SHA2 ist ungefähr halb so schnell wie md5, das ist kein ausreichend relevantes Argument in diesem Falle; wer es eilig hat, kann einen schnellen sicheren Hash verwenden wie z.B. BLAKE2. Es gibt keine sinnvollen Einsatzzwecke für md5 mehr und je schneller es verschwindet desto schneller kann niemand es mehr an der falschen Stelle einsetzen.
Aus genau diesem Grund findet man unmittelbar bei Dateidownloads regelmäßig md5 oder sha1-hashes. (Beispiel)
Auch da bin ich dafür, bessere Hashfunktionen zu verwenden, dann muss man nämlich zusätzlich zu meinen bisherigen Argumenten, wenn die Pre-Image-Angriffe auf md5 besser werden, nicht hektisch alles austauschen.
mfg
Woodfighter
Was hat das mit dem Thema zu tun?
Deine Frage erscheint mir idiotisch.
gähn
Dein Verhalten ist inakzeptabel.
Du hast Dich mit dem Stoff nicht ernsthaft genug befasst. Sämtliche bekannten Angriffsvektoren auf MD5 oder sha1 haben nichts und auch gar nichts damit zu tun, dass MD5 nicht geeignet sei, die Verifizierung eines Downloads bezüglich zufälligen Bitfehlern oder (Un)Vollständigkeit zu verneinen. Dazu ist es gut genug.
ich habe auch nirgendwo vorgeschlagen einen Passwort-Hash für Dateien zu verwenden.
Das verwendete SHA384 ist aber einer der "SHA2-Hashalgos". Es geht also die ganze Zeit darum.
Ich schlage vor, du bedenkst den Diskussionsgegenstand erst mal, bevor Du derlei vorträgst und dabei auch noch derart unangemessen unhöflich wirst und mit Deinem (mit allem Verlaub:) Mist - jede vernünftige Diskussion unmöglich machst.
Tach,
Was hat das mit dem Thema zu tun?
Deine Frage erscheint mir idiotisch.
Dann solltest du den Thread vielleicht nochmal lesen; anstatt auch nur einmal auf eines meiner Argumente einzugehen, schlägst du ständig neue Tangenten ein. Du hast dich leider nicht geändert und mit dir zu „diskutieren“ ist leider weiterhin ein unsinniges Unterfangen, da du keinerlei Interesse daran hast deinen Standpunkt zu ändern.
gähn
Dein Verhalten ist inakzeptabel.
Du bist nicht in der Position das zu entscheiden.
Du hast Dich mit dem Stoff nicht ernsthaft genug befasst.
Sorry, aber ich bin mir sicher, dass ich den stoff genauer kenne als du.
Sämtliche bekannten Angriffsvektoren auf MD5 oder sha1 haben nichts und auch gar nichts damit zu tun, dass MD5 nicht geeignet sei, die Verifizierung eines Downloads bezüglich zufälligen Bitfehlern oder (Un)Vollständigkeit zu verneinen. Dazu ist es gut genug.
Und ich habe bereits dargelegt, dass das nicht alles ist, wofür der Hash nutzvoll ist und warum, selbst wenn das der einzige Punkt wäre, es immer noch Gründe dafür gibt diese Algorithmen für nichts mehr zu verwenden.
ich habe auch nirgendwo vorgeschlagen einen Passwort-Hash für Dateien zu verwenden.
Das verwendete SHA384 ist aber einer der "SHA2-Hashalgos". Es geht also die ganze Zeit darum.
SHA2 ist kein speziell für das Hashen von Passworten entwickelter Algorithmus, sondern ein allgemeiner kryptographischer Hash. Einer der Einsatzzwecke von kryptographischen Hashfunktionen war das Hashen von Passworten, heutzutage verwendet man dafür speziellere Funktionen, da eines der Kriterien für einen guten kryptographischen Hash, nämlich die Schnelligkeit, dem Einsatzzweck als Passwort-Hash widerspricht.
mfg
Woodfighter
Dein Verhalten ist inakzeptabel. Du bist nicht in der Position das zu entscheiden.
Du irrst. Ob ich (D)ein Verhalten als "akzeptabel" oder "inakzeptabel" bewerte entscheide ich für mich.
Weitere Hinweise, insbesondere zur Bedeutung des Wortes findest Du im Duden:
Die Bedeutung von "akzeptieren" wird erklärt mit: "annehmen, hinnehmen, billigen; anerkennen; mit jemandem oder etwas einverstanden sein".
Es geht da also per se um eine Meinung und ich werde mir - sehr speziell auch von Dir - die meine nicht verbieten lassen.
Tach,
Dein Verhalten ist inakzeptabel. Du bist nicht in der Position das zu entscheiden.
Du irrst. Ob ich (D)ein Verhalten als "akzeptabel" oder "inakzeptabel" bewerte entscheide ich für mich.
du kannst das für dich bewerten oder finden, aber ob es das hier ist, entscheiden die Moderatoren nicht du.
mfg
Woodfighter
wer es eilig hat, kann einen schnellen sicheren Hash verwenden wie z.B. BLAKE2.
(Gegenwärtig) Nicht für die Öffentlichkeit. Da macht es Sinn sich auf das zu beschränken, was auf den Rechnern der Empfänger voraussichtlich mit vorhandener Software berechenbar ist. Gegenwärtig gehört der BLAKE2-Algo nicht dazu. Oder willst neben der Datei und dem Hash auch noch das Programm für das Bilden des Hashs liefern?
Bedenke, wie weit daneben das wäre.
Tach,
auch wenn ich dir zustimme, dass er besser wäre, würde er von anderswo ausgeliefert werden.
wird er ja auch wie es in der Anleitung auch beschrieben ist: „Verify the installer SHA-384 which you can also cross-check here“
mfg
Woodfighter
wird er ja auch wie es in der Anleitung
Ich schrieb ja: Für mich unbrauchbare Dokumentation.
Tach,
wird er ja auch wie es in der Anleitung
Ich schrieb ja: Für mich unbrauchbare Dokumentation.
die Dokumentation nicht ausreichend zu lesen, bevor man anfängt sie umzusetzen, würde ich nicht der Anleitung vorwerfen.
mfg
Woodfighter
die Dokumentation nicht ausreichend zu lesen, bevor man anfängt sie umzusetzen, würde ich nicht der Anleitung vorwerfen.
Im Hinblick auf Punkt 1 "Erst wird beschrieben, was ich tun soll. Explizit mit Shell-Befehlen." muss man aber den Vorwurf machen.
Dann wäre da noch das hier:
Da steht "Download" nicht "Install". Die Software wird aber mit den angegebenen Befehlen heruntergeladen, der Dowload mit dem völlig überzogenen Hash-Check auf Vollständigkeit und Bitfehler geprüft und dann wird die Installation durchgeführt und der Download gelöscht. Was im Konflikt zu "Download Composer - Run this in your terminal to get the latest Composer version:" steht.
Tach,
die Dokumentation nicht ausreichend zu lesen, bevor man anfängt sie umzusetzen, würde ich nicht der Anleitung vorwerfen.
Im Hinblick auf Punkt 1 "Erst wird beschrieben, was ich tun soll. Explizit mit Shell-Befehlen." muss man aber den Vorwurf machen.
Dann wäre da noch das hier:
Da steht "Download" nicht "Install". Die Software wird aber mit den angegebenen Befehlen heruntergeladen, der Dowload mit dem völlig überzogenen Hash-Check auf Vollständigkeit und Bitfehler geprüft und dann wird die Installation durchgeführt und der Download gelöscht. Was im Konflikt zu "Download Composer - Run this in your terminal to get the latest Composer version:" steht.
das ist ein geschickt ausgewählter Ausschnitt der Seite. Wenn man die nächsten paar Zeilen Text auch noch dazu nimmt:
Dann kann man direkt sehen, dass die Beschreibung der nächsten Schritte insgesamt weitere drei Zeilen darunter beginnt. Und wenn dir das zu unübersichtlich oder zu unverständlich ist, liegt das meiner Meinung nach nicht an der Doku.
mfg
Woodfighter
das ist ein geschickt ausgewählter Ausschnitt der Seite. Wenn man die nächsten paar Zeilen Text auch noch dazu nimmt:
Dann kann man direkt sehen, dass
es die falsche Reihenfolge ist. Es mag Menschen geben, die lesen von rechts nach links, aber wohl nie lateinische Buchstaben. Es mag Menschen geben, die lesen die Zeitung von hinten nach vorn. Aber die Nachrichten in einer Zeitung haben einen weniger engen Zusammenhang als eine Installationsanleitung. (Klar, auch die Börse hat mit Sport und Todesfallanzeigen zu tun).
Aber jemand, der eine Anleitung von unten nach oben liest? So einen habe ich noch nie wahrgenommen.
Hallo,
Es mag Menschen geben, die lesen von rechts nach links, aber wohl nie lateinische Buchstaben.
das wäre wohl eher ungewöhnlich - obwohl ... Spiegelschrift? Der Schriftzug FEUERWEHR oder POLIZEI (oder auch nur ein Firmenname) an der Front von Autos ist oft in Spiegelschrift angebracht. Das ist doppelt verwirrend: Kommt einem so ein Fahrzeug entgegen, ist die Schrift verkehrt herum; sieht man so ein Fahrzeug im Rückspiegel, weiß man, dass man in einen Spiegel schaut und liest daher instinktiv schon von rechts nach links - passt auch wieder nicht. In beiden Fällen lenkt das mehr vom Verkehrsgeswchehen ab, als es eigentlich gut wäre.
Aber jemand, der eine Anleitung von unten nach oben liest? So einen habe ich noch nie wahrgenommen.
Bei Anleitungen ist das wohl weniger üblich. Aber es scheint verblüffend viele Menschen zu geben, die chronologisch organisierte Listen von unten nach oben lesen. Die Liste der Nachrichten ist in einigen Mailclients per Default von unten nach oben sortiert; die Revision History von Softwareprojekten ist oft von unten nach oben sortiert, es soll sogar Nutzer geben, die sich die Beiträge hier im Forum von unten nach oben sortieren lassen.
So long,
Martin
Tach,
Dann kann man direkt sehen, dass
es die falsche Reihenfolge ist.
der Abschnitt ist 12 Zeilen lang, wenn deine Aufmerksamkeitsspanne dafür nicht ausreichend ist, tut mir das leid. Die Erklärung unterhalb des Codes zu haben, ist kein Kardinalfehler sondern nicht unüblich.
mfg Woodfighter
Hallo woodfighter,
die Dokumentation nicht ausreichend zu lesen, bevor man anfängt sie umzusetzen, würde ich nicht der Anleitung vorwerfen.
Aber eine Dokumentation, die man Schritt für Schritt abarbeiten kann, wäre schon von Vorteil. (Dies bezieht sich nicht auf die Dokumentation um die es in diesem Beitrag geht, denn ich habe mir sie nicht angeschaut)
Bis demnächst
Matthias
Hallo,
Ich schrieb ja: Für mich unbrauchbare Dokumentation.
die Dokumentation nicht ausreichend zu lesen, bevor man anfängt sie umzusetzen, würde ich nicht der Anleitung vorwerfen.
da bin ich prinzipiell bei dir, aber: Eine Dokumentation (besser "Anleitung"), die wichtige und entscheidende Aspekte erst zum Schluss oder zumindest erst relativ weit hinten erwähnt, ist auch meiner Ansicht nach dringend verbesserungwürdig.
Ja, ich lese Anleitungen auch erst vollständig durch, bevor ich mit Schritt 1 beginne. Aber ich finde trotzdem, dass die notwendigen Schritte auch in der Reihenfolge beschrieben sein sollten, in der sie auszuführen sind.
Das ist ein bisschen so, als würde in der Aufbau-Anleitung für einen massiven Kleiderschrank erst zum Schluss erklärt, dass man als erstes die Standfüße unter die Bodenplatte hätte schrauben sollen.
So long,
Martin
Hallo Der Martin,
Das ist ein bisschen so, als würde in der Aufbau-Anleitung für einen massiven Kleiderschrank erst zum Schluss erklärt, dass man als erstes die Standfüße unter die Bodenplatte hätte schrauben sollen.
Und ich wollte noch schreiben: „Der Martin findet bestimmt noch einen passenden Vergleich.“
Bis demnächst
Matthias
Hi,
Das ist ein bisschen so, als würde in der Aufbau-Anleitung für einen massiven Kleiderschrank erst zum Schluss erklärt, dass man als erstes die Standfüße unter die Bodenplatte hätte schrauben sollen.
Und ich wollte noch schreiben: „Der Martin findet bestimmt noch einen passenden Vergleich.“
na schön, dann hab ich deine Erwartungen ja nicht enttäuscht. :-)
Schönes Wochenende,
Martin