Ankündigung

Einklappen
Keine Ankündigung bisher.

Wie sicher ist MD5 wirklich?

Einklappen

Neue Werbung 2019

Einklappen
Dieses Thema ist geschlossen.
X
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • #16
    Erc, der Punkt ist doch vor allem, wie ich oben ausführlich geschrieben habe: Kriegst du davon was mit oder nicht. Wenn einer den gehashten Wert hat, kann er losgelöst von deiner Webseite aktiv werden. Dann dauerts vielleicht eins zwei Wochen, vielleicht länger, ohne dass du als Admin was merkt und plötzlich hat er ein funktionierendes Passwort.
    Wieso hat Sony es nicht sofort bemerkt? Weil die Hacker erst sehr spät manipulierend aktiv waren. Die Hacker haben sich zuerst sozusagen lesend im System umgesehen, haben versucht, nicht aufzufallen. Damit konnten sie ungestört Daten abziehen.

    Deswegen: Nicht meinen, dass man mit MD5 immer eine bestimmte Art des Angriffs auf die eigene Webseite verbinden muss. Das sollte man niemals zusammen betrachten. Um die Sicherheit von MD5 und Hashes zu beurteilen, immer davon ausgehen: Der Hacker hat bereits über Sicherheitslücken direkten Zugang zur Datenbank.

    Bei den Signaturen, klar, das ist ein weiteres Problem. Wobei es hier aber um Passwörter ging, nicht um Signaturen. Diese haben eine Sonderstellung aufgrund der Tatsache, dass dort das Original verfügbar ist.
    www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
    Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

    Kommentar


    • #17
      Zitat von mepeisen Beitrag anzeigen
      Salts, ob statisch oder dynamisch, können und werden geknackt werden.
      Das lässt sich nicht abstreiten. Wird jedoch für jeden Datensatz ein individueller Salt 1) vergeben, bringt das "Knacken" eines einzelnen Salts wenig bzw. gar nichts.

      1) z.B. mittels md5( uniqid( mt_rand( ), true ) )

      Zitat von mepeisen Beitrag anzeigen
      Erstens fällt es auf, wenn einer wochenlang deine Webseite bombadiert bis er einen Zufallstreffer landet. Wems nicht auffällt, dem gehört der Server abgenommen.
      Diese Perpektive erscheint mir persönlich etwas naiv. Nicht jede Seite wird 24/7 betreut, nicht einmal Grössere und vor allem nicht unbedingt durch Spezialisten.

      Zitat von mepeisen Beitrag anzeigen
      Durch Salts, ob statisch oder dynamisch, verhinderst du lediglich den einfachen Transfer auf andere Webseiten bzw. dass ein stattgefundener Einbruch ohne Probleme auf deiner Webseite Verwendung finden kann.
      Dieser Zusammenhang erschliesst sich mir nicht. Die Verwendung eines Salts hat mit den bereits erwähnten Rainbow-Tables zu tun bzw. damit, die Erstellung der Tables zu erschweren.

      Zitat von mepeisen Beitrag anzeigen
      Ob MD5, ob geslazen, ob dynamisch oder statisch, ob im Klartext, das alles ist solange egal, solange niemand ins System einbricht.
      Passworte sollten prinzipielll nicht im Klartext gespeichert werden. Daten wie diese müssen Personen mit entsprechender Zugriffsmöglichkeit (z.B. System- und Anwendungsadministratoren) nicht auf dem Silbertablett präsentiert werden.

      dr. ?

      Kommentar


      • #18
        Zitat von dr. ? Beitrag anzeigen
        Das lässt sich nicht abstreiten. Wird jedoch für jeden Datensatz ein individueller Salt 1) vergeben, bringt das "Knacken" eines einzelnen Salts wenig bzw. gar nichts.
        Doch, es bringt dann was, wenn es der Admin-Satz ist. Sinnvollerweise knackt man nur den

        Zitat von dr. ? Beitrag anzeigen
        Diese Perpektive erscheint mir persönlich etwas naiv. Nicht jede Seite wird 24/7 betreut, nicht einmal Grössere und vor allem nicht unbedingt durch Spezialisten.
        Das kommt auf die Blickrichtung drauf an und auf den eigenen Anspruch. Natürlich gibt es viele Unbedarfte, die sowas nicht bemerken. Wenn ich einen Webshop betreibe und sei es ein kleiner, fällt es auf, wenn dieser Wochenlang mit Anfragen bombadiert wird und dadurch deutlich langsamer wird. Natürlich. Reden wir von einer privaten Webseite mit 5 Besuchern im Monat, die wird evtl. nicht so sorgsam betreut.
        Aber: Das Potential, dass es aufällt, ist sehr groß. Wenn man sich mit dem Thema Sicherheit beschäftigt, sollte man sich darüber im Klaren sein, wie man solche angriffe rechtzeitig bemerkt. Mehr wollte ich damit nicht ausdrücken. Wenn man sich mit solchen Fragestellungen nicht beschäftigt, handelt man extrem naiv.

        Zitat von dr. ? Beitrag anzeigen
        Dieser Zusammenhang erschliesst sich mir nicht. Die Verwendung eines Salts hat mit den bereits erwähnten Rainbow-Tables zu tun bzw. damit, die Erstellung der Tables zu erschweren.
        Es ist relativ simpel. Die Wahrscheinlichkeit, über Rainbow-Tables das exakt ursprüngliche Passwort herauszufinden, geht gegen 0. Der Clou ist ja, ein Passwort zu finden, was zum selben Hash führt und damit verwendbar ist. Damit die Webseite gar nicht merkt, dass es sich um ein anderes Passwort findet. Eine ganz einfache Beweiskette:
        PWD-A führt bei SALT-A zu HASH-A
        PWD-A2 führt bei SALT-A zu HASH-A

        Passwort A ist das Original.
        Passwort A2 ist das, was der Hacker mittels Bruteforce herausgefunden hat.

        Neue Webseite bei der der gleiche User mit gleichem Bneutzernamen/Passwort aktiv ist.
        PWD-A führt bei SALT-B zu HASH-B
        PWD-A2 führt bei SALT-B zu HASH-C

        Damit ist das mittels Buteforce herausgefundene Passwort für andere Webseiten unbrauchbar. Überlege mal, wieviele ihr bei Sony verwendetes Passwort auch noch bei Facebook und Co. einsetzen.

        Zitat von dr. ? Beitrag anzeigen
        Passworte sollten prinzipielll nicht im Klartext gespeichert werden. Daten wie diese müssen Personen mit entsprechender Zugriffsmöglichkeit (z.B. System- und Anwendungsadministratoren) nicht auf dem Silbertablett präsentiert werden.
        Völlig richtig. Es ging mir darum, aufzuzeigen, dass die Sicherheit der gespeicherten Daten nur bis zu dem Moment geht, ab dem jemand Zugang erlangt. Ob Verschlüsselungen oder Hashes oder sonstwas, ab dem Moment, wo einer Zugriff ins System bekommt, ist es nur noch eine Frage der Zeit bzw. des Rechenaufwandes, diese Daten zu knacken. Das ist eine Grundregel.

        Es geht - ich wiederhole mich - um ein Wettrüsten. Das was heute als 99% sicher gilt, wird in 2 Jahren spielend einfach zu knacken sein. Vor Jahren hat noch jeder gedacht, ach MD5 und schon ist es sicher. Das kann keiner zurück rechnen. Bis einer auf die Idee kam, gar nicht das Original-Passwort herausfinden zu wollen, sondern nur einen "Alias", der funktioniert. Dann kam die Idee mit dem Salz. Bis jemand auf die Idee kam, Rainbow-Tables für diverse Salts zu errechnen...
        www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
        Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

        Kommentar


        • #19
          Zitat von mepeisen Beitrag anzeigen
          Doch, es bringt dann was, wenn es der Admin-Satz ist. Sinnvollerweise knackt man nur den
          Und woher weiss ich, dass es der Admin-Satz ist? Ich sehe da nur 2 Möglichkeiten:

          a) Es ist bekannt bzw. von aussen einsehbar. Wenn bspw. der angezeigte Username Teil der Login-Daten ist wie bei der hiesigen Foren-Software.
          b) Durch Kenntnis der Datenstruktur bzw. Zugriff auf die Datenbank. Der Fall wurde bereits diskutiert - da ist sowieso alles verloren.

          Zitat von mepeisen Beitrag anzeigen
          Wenn man sich mit dem Thema Sicherheit beschäftigt, sollte man sich darüber im Klaren sein, wie man solche angriffe rechtzeitig bemerkt. Mehr wollte ich damit nicht ausdrücken. Wenn man sich mit solchen Fragestellungen nicht beschäftigt, handelt man extrem naiv.
          Selbstverständlich. Die Praxis sieht jedoch häufig anders aus: Technische Pannen, fachliche Unkenntnis, persönliches Desinteresse etc.
          Glaubst Du tatsächlich, der 08/15 Shopbetreiber denkt darüber nach, warum sein Shop (plötzlich) etwas zäher läuft als am Anfang? Lapidar gesprochen: das kennt er doch von Windows...

          Zitat von mepeisen Beitrag anzeigen
          Eine ganz einfache Beweiskette [...]
          Ach, darauf wolltest Du hinaus

          Zitat von mepeisen Beitrag anzeigen
          Ob Verschlüsselungen oder Hashes oder sonstwas, ab dem Moment, wo einer Zugriff ins System bekommt, ist es nur noch eine Frage der Zeit bzw. des Rechenaufwandes, diese Daten zu knacken.
          Die Aussage ist trivial. Dennoch: ein Passwort im Klartext auszulesen und eine MD5-Kollision zu erzeugen, sind 2 Paar Schuhe; Riemchen-Sandale vs. Dr. Martens Stahlkappen-Stiefel.

          Zitat von mepeisen Beitrag anzeigen
          Bis einer auf die Idee kam, gar nicht das Original-Passwort herausfinden zu wollen, sondern nur einen "Alias", der funktioniert. Dann kam die Idee mit dem Salz. Bis jemand auf die Idee kam, Rainbow-Tables für diverse Salts zu errechnen...
          Das sind - mit Verlaub - eher akademische Betrachtungen. Wenn's um die Erstellung einer bombensicher(er)en Webanwendung geht, werden sowieso andere, zusätzliche Masznahmen angewendet.

          dr. ?

          Kommentar


          • #20
            Fall a) ist Humbug, denn dann setzt du voraus, dass du keinen Einblick in die Datenbank hast. Damit kennst du auch den in der DB abgespeicherten Hash nicht. Was bringt es dir? Lediglich eine Eingrenzung der Passwörter von 50 Trillionen Möglichkeiten auf 2^X Möglichkeiten. Dennoch musst du stur die Webseite damit bemühen, diese Möglichkeiten auszutesten.

            Also gibt es realistischerweise nur Fall b), bei allen anderen hilft dir die Erkenntnis nichts, wenn du nicht mal weisst, wie der Hashcode ist, den du mittels Bruteforce knacken willst. Fall b) ist das Extrem, dass du als Webseiten-Betreiber nur schwer merkst, wann dieser Fall eintritt. Die Attacke selbst bleibt für dich weitesgehend unsichtbar. Denn die Webseite wird nur mit wenigen Requests bemüht. Die Berechnung der Rainbow-Table, das Knacken der Passwört, geschieht unsichtbar auf anderen Servern/ dem PC des Hackers.

            Ne, ein 08/15 Shopbetreiber denkt drüber nicht nach. Und wenn ich dann ein Projekt übernehme, den FTP kopiere und mir dabei AntiVir einen Trojaner in einem PHP-Script meldet, schüttele ich mit dem Kopf und freue mich über zusätzliche Arbeit... Es gibt einige einfache Grundregeln. Wer sich damit beschäftigt und einen Experten fragt, der kann auf der sicheren Seite sein (100%ige Sicherheit gibt es eh nie).

            Also. Totale Sicherheit gibt es nie. Sowas zu behaupten, ist pure Augenwischerei. Es gibt aber eine 99%ige Sicherheit, wenn man einige einfache Grundregeln bei der Entwicklung und dem Betrieb beachtet. Es gibt die Sicherheit dadurch, dass man die Hürden für einen Hack so hoch legt, dass er für den 15jährigen, der es in der Freizeit macht, unschaffbar wird und dass Profis das eh von vornherein lassen. Welcher Profi hackt sich in eine vollkommen unbekannte private Webseite ein?
            Mit Wichtigkeit der Seite steigt die Gefahr, dass einer die restlichen 1% der fehlenden Sicherheit versucht zu finden.

            Osama hatte man auch nur über diesen einen Weg über die Kuriere finden können. Kein Internet, kein Telefon, hat sich nicht mal in der Nachbarschaft blicken lassen. Für jeden Normalbürger war es unmöglich, ihn zu finden. Die USA haben ihn gefunden, weil sie a) hartnäckig waren und b) die Mittel hatten, die Kenntnisse, was auch immer, genau diese eine Spur zu finden.

            Mit Sicherheit bei Webseiten ist das genauso. Perfekt ist die nie. Aber gängige Angriffe, die man als Hacker in der Grundschule lernt, lassen sich ebenso leicht abwehren. Ist man sorgsam genug, sind die Lücken geschlossen. Aber es gibt jenseits davon genug Wege, etwas zu hacken, wenn man es nur drauf anlegt.

            Und für alle anderen Fälle gibt es die Phishing-Methode mit all ihren Abarten
            www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
            Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

            Kommentar


            • #21
              Zitat von mepeisen Beitrag anzeigen
              Also gibt es realistischerweise nur Fall b)
              Stimmt, doch der Punkt ist obsolet; ich zitiere Dich:

              Zitat von mepeisen Beitrag anzeigen
              Wer bereits die Datenbank ausgespäht hat, dem ist es eh bereits gelungen, so weit ins System einzudringen, dass man sich um die Sicherheit der Hashes am geringsten Sorgen machen sollte.
              Ja, Fall b) ist das Extrem. Gerade darum glaube ich nicht, dass es ausreichend ist, die Website mit ein paar "wenigen Requests" zu bemühen, um an interessante Daten heranzukommen. Jedenfalls dann nicht, wenn man löchrige Skripte, schlechtes Software-Design oder dergleichen mal aussen vor lässt.

              Zitat von mepeisen Beitrag anzeigen
              Wer sich damit beschäftigt und einen Experten fragt, der kann auf der sicheren Seite sein
              Wie gesagt, in der Praxis sieht's oft anders aus. Hier gibt's zahlreiche Grautöne.

              Zitat von mepeisen Beitrag anzeigen
              Totale Sicherheit gibt es nie [...]
              Das hat doch auch niemand behauptet... warum ist es Dir so wichtig, diesen Punkt immer wieder zu betonen? Ich dachte, wir diskutieren über MD5 und Salts im Speziellen, nicht um das Thema "Sicherheit" im Allgemeinen. Ich glaube, in diesem Unterforum hat diesbezüglich kaum jemand Nachhilfe nötig

              Zitat von mepeisen Beitrag anzeigen
              Und für alle anderen Fälle gibt es die Phishing-Methode mit all ihren Abarten
              Ja, darum sollte man auch das Verhältnis zwischen Aufwand und Nutzen (von Sicherheitsvorkehrungen) im Auge behalten. Das Schöne an dem Ganzen ist: es bleibt stets spannend.

              dr. ?

              Kommentar


              • #22
                Ich betone das deswegen jedesmal, weil ich oft genug gefragt werde, warum es keine totale Sicherheit gibt. Oder warum es aufwändig ist. Und weil ich oft genug erlebe, mit welcher Naivität Menschen heutzutage vorgehen nur um dann laut zu schreien, wenn bereits das Kind in den Brunnen gefallen ist.
                www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
                Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

                Kommentar


                • #23
                  Ich glaube, in diesem Unterforum hat diesbezüglich kaum jemand Nachhilfe nötig ...
                  Dann wäre aber die Frage "Wie sicher ist MD5 wirklich?" hier unpassend, weil MD5 ein Hashing-Algorithmus ist, für dessen sichere Funktion (wie in "safety") so etwas wie "Sicherheit" (wie in "security") vollkommen irrelevant ist.

                  Zitat von mepeisen Beitrag anzeigen
                  Ich betone das deswegen jedesmal, weil ich oft genug gefragt werde, warum es keine totale Sicherheit gibt.
                  Weil Sicherheit ein Prozess ist und kein Zustand. Diesen Unterschied kapieren viele nicht. Bei denen ist Sicherheit so etwa wie ein Vorhängeschloss: Das schnappt zu und damit ist die Sache sicher. Muss sie doch, beim Vorhängeschloss klappt das doch auch ...

                  Und aus betriebswirtschaftlicher Sicht sollte es in den allermeisten Fällen ausreichen, den Aufwand für einen Angreifer so hochzutreiben, dass das Restrisiko von einer Versicherung übernommen wird oder selbst getragen werden kann. Darauf wolltest du mit deiner Prozent- und Private-Website-Argumentation sicher hinaus.

                  Oder warum es aufwändig ist. Und weil ich oft genug erlebe, mit welcher Naivität Menschen heutzutage vorgehen nur um dann laut zu schreien, wenn bereits das Kind in den Brunnen gefallen ist.
                  http://www.ne.anl.gov/capabilities/v...ls/maxims.html
                  (62 bis 67)

                  Zitat von nikosch Beitrag anzeigen
                  Tja, dann hast Du aber immer noch keine passende Rainbowtable. Vor allem nicht, wenn dynamische Salts verwendet worden sind.
                  Die brauche ich nicht. Ich hab mir ja eine Kopie der Festplatte gezogen. Da sind alle Daten unverschlüsselt drauf. Wen interessieren da noch wie auch immer gehashte Passwort-Listen?

                  Ich wollte eigentlich nur darauf hinweisen, dass man (mit PHP-Script-Bastelei) nur für einen Angriff von außen (also über die Website) vorsorgen kann. Da ist ein zufällig gewähltes Salt pro Benutzer ausreichend (und wichtig), weil das den Angreifer dazu zwingt, sich für jeden Benutzer eine neue Rainbowtable bauen zu müssen. Alle weiteren Maßnahmen der Passwortbehandlung dienen höchstens zur Verschleierung ("security by|through obscurity), bieten aber keinen zusätzlichen Schutz.
                  Wenn man die Wurst schräg anschneidet, hält sie länger, weil die Scheiben größer sind.

                  Kommentar


                  • #24
                    Ich wollte eigentlich nur darauf hinweisen, dass man (mit PHP-Script-Bastelei) nur für einen Angriff von außen (also über die Website) vorsorgen kann. Da ist ein zufällig gewähltes Salt pro Benutzer ausreichend (und wichtig), weil das den Angreifer dazu zwingt, sich für jeden Benutzer eine neue Rainbowtable bauen zu müssen. Alle weiteren Maßnahmen der Passwortbehandlung dienen höchstens zur Verschleierung ("security by|through obscurity), bieten aber keinen zusätzlichen Schutz.
                    Den Absatz verstehe ich nicht.
                    Ich hab mir ja eine Kopie der Festplatte gezogen. Da sind alle Daten unverschlüsselt drauf.
                    Den Witz auch nicht. Gerade dagegen hilft es ja, nur md5-gehashte Passwörter in die DB zu legen. Da kann dann auch der Pförtner nichts dran ändern.
                    --

                    „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                    Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


                    --

                    Kommentar


                    • #25
                      Frage am Rand:
                      Kann ich mich mit einer Verschlüsselung wie

                      Client:
                      Übertragener Wert = hash( hash( Passwort ) + Zufälliger Wert )
                      Server
                      hash( Gespeicherter Passworthash + Übertragener Zufallshash ) == Übertragener Wert

                      Sicher wähnen, oder lieber nicht?

                      Kommentar


                      • #26
                        MD5 ist keine Verschlüsselung. Das sollte jetzt langsam mal klar sein.

                        Und der Terminus „sicher“ wurde jetzt hinreichend dargelegt.

                        [MOD: Thread geschlossen]
                        --

                        „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                        Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


                        --

                        Kommentar

                        Lädt...
                        X