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

  • Wie sicher ist MD5 wirklich?

    Hallo,

    wie sicher ist MD5 denn?

    Auf Wikipedia steht folgendes:
    Sie gilt inzwischen nicht mehr als sicher, da es mit überschaubarem Aufwand möglich ist, unterschiedliche Nachrichten zu erzeugen, die dieselbe MD5-Prüfsumme aufweisen.
    Ist ja auch in sofern logisch, da ein MD5 Hash ja nur 32 Zeichen hat und nur Kleinbuchstaben sowie Zahlen enthält.

    Wie verhält es sich mit MD5 + Salt?

    Was ist wenn ich einen eigenen kleinen Algorithmus schreibe?
    Also z.B. zunächst einen String mehrmals durch md5() jage, danach noch 1-2 billig Verschlüsselungsmethoden


  • #2
    MD5 + statischer Salt oder MD5 + dynamischer Salt (Random, User-ID etc.), der beispeilsweise in einem extra Tabellenfeld steht, reicht aus. Mehrfach durch md5 zu jagen ist albern.
    Mit Salt beisst man sich durch pures Ausprobieren bereits die Zähne aus.

    Voraussetzung ist immer: Niemand blickt dir in den Code und niemand in die Datenbank selbst. Wenn einer (wie bei Sony geschehen) die Datenbank kopiert, kann er in aller Ruhe, egal wie "sicher" der Algorithmus ist, eine Rainbow-Table anlegen oder eine finden, ohne dass du das mitbekommst. Es ist nur ne Frage der Rechnerleistung. Mehrfach durch md5 zu jagen ist dabei lediglich eine kleine Erhöhung der Hürde.
    Beides (Ausprobieren und Rückrechnen nach Datenbankkopie) sind zwei unterschiedliche Attacken.

    Ansonsten wurde schon zigfach das Thema hier durchgekaut...
    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


    • #3
      Ist ja auch in sofern logisch, da ein MD5 Hash ja nur 32 Zeichen hat und nur Kleinbuchstaben sowie Zahlen enthält.
      1. Nicht Kleinbuchstaben sondern HEX-Ziffern
      2. entspricht
      16 ^ 32
      = 3,4 * 10^38 theoretischen Kombinationen (340000000000000000000000000000000000000).
      Gewinnwahrscheinlichkeit Lotto 6 Richtige mit Superzahl
      = 1:7,1511 * 10^9 (7151100000)
      So what?
      --

      „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


      • #4
        Generell gilt es immer: MD5 bewirkt, dass man bei einem Trial/Error-Angriff größere Chancen hat als würde das Klartext-Passwort abgespeichert. Klartext-Passwörter sind aber bei einem Einbruch (SQL-Injection, Datenklau etc.) tödlich. Dagegen sind MD5-Hashes bei einem Einbruch etwas sicherer. Dagegen gibt es jedoch Rainbow-Tables, wo man direkt zu einem MD5 ein passendes Passwort hat. Kippt man Salz drüber, ist das wieder etwas sicherer.

        Wenn jedoch jemand ein Passwort knacken, wird er immer einen Weg finden. Deine Aufgabe ist es, die Sicherheit akzeptabel hinzubekommen (was mit gesalzenem MD5 im Hausgebrauch immer ausreicht) und alle gängigen Sicherheitslücken zu schließen (SQL-Injection etc. pp.) und mögliche Angriffe rechtzeitig zu merken (auch hier gibt es Strategien). Werden beispielsweise deine Webseiten durch Robtoer ständig mit komischen Benutzerregistrierungen versehen oder permanent mit komischen kryptischen fehlerhaften Passwortabfragen überhäuft, gilt es aufzupassen.
        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


        • #5
          Zitat von mepeisen Beitrag anzeigen
          Voraussetzung ist immer: Niemand blickt dir in den Code und niemand in die Datenbank selbst.
          Die Sicherheit sollte aber nie darauf beruhen das der Code geheim bleibt! Eigentlich sollte jeder wissen können wie dein Hash berechnet wird. Und ein Salt hilft nicht gegen normale Wörterbuchangriffe/Brute Force Angriffe, vor allem nicht wenn der Angreifer das über das normale Login Formular probiert.

          Salts sind dafür da das ein gegebener Hash nicht durch eine Rainbowtable zurückgerechnet werden kann sondern extra eine neue Rainbowtable erstellt werden müsste (für diesen Salt) DANN aber das ja einem Brute Force Angriff gleicht und der so oder so nicht zu verhindern ist.

          Und ein dynamischer Salt hilft dagegen das der Angreifer für die gesamte Datenbank (falls diese nur nen statischen Salt hat) eine Rainbowtable anlegt und damit dann alle (oder mehrere Passwörter) auf einmal zurückrechnen kann.

          @nikosch: Das Problem ist ja nicht eine zufällige Kollision sondern ob eine gezielte Kollision herstellbar ist. Aber dies ist noch nicht mit MD5 möglich! MD5 ist immer noch schwach kollisionsresistent und daher fürs Speichern von Passwörtern denke ich noch ausreichend genug, man sollte aber eben einen dynamischen Salt gegen Rainbowtables einbauen.

          Kommentar


          • #6
            md5 ist unsicher. Darum wurden derartige Zertifikate eliminiert.
            https://tepin.aiki.de/blog/archives/...t-ersetzt.html
            sha verwenden.

            Kommentar


            • #7
              Um ganz sicherzugehen:

              PHP-Code:
              $speichern=md5($pw) . sha1($pw) . md5($pw $salt) . sha1($pw $salt) . md5($pw $salt $dynsalt) . sha($pw $salt $dynsalt); 
              Wir werden es diesen Hackern schon zeigen!!


              oder mit anderen Worten: Gegen einen Großangriff auf die Userverwaltung des Tischtennisclubs TC Posemuckel ist allemal ein Kraut gewachsen.
              PHP-Code:
              if ($var != 0) {
                
              $var 0;

              Kommentar


              • #8
                PHP-Code:
                $speichern hackWollasDatabaseAndSelectOneHash();

                $hash substr$speichern032 );

                $password MD5RainbowTable$hash );

                echo 
                $password

                Kommentar


                • #9
                  $hash = substr( $speichern, 0, 32 );
                  Boah ey.
                  PHP-Code:
                  if ($var != 0) {
                    
                  $var 0;

                  Kommentar


                  • #10
                    Passend zum Thema: http://www.heise.de/security/meldung...s-1237975.html
                    --

                    „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


                    • #11
                      Zitat von Wolla Beitrag anzeigen
                      Um ganz sicherzugehen:

                      PHP-Code:
                      $speichern=md5($pw) . sha1($pw) . md5($pw $salt) . sha1($pw $salt) . md5($pw $salt $dynsalt) . sha($pw $salt $dynsalt); 
                      Wir werden es diesen Hackern schon zeigen!!

                      oder mit anderen Worten: Gegen einen Großangriff auf die Userverwaltung des Tischtennisclubs TC Posemuckel ist allemal ein Kraut gewachsen.
                      Also ich würde dazu den Pförtner vom Serverzentrum bei <generischer Massenhoster> bestechen. Dann würde ich mir die Daten direkt von der Festplatte ziehen, Hashes und Salts hin oder her.
                      Wenn man die Wurst schräg anschneidet, hält sie länger, weil die Scheiben größer sind.

                      Kommentar


                      • #12
                        Dann würde ich mir die Daten direkt von der Festplatte ziehen, Hashes und Salts hin oder her.
                        Tja, dann hast Du aber immer noch keine passende Rainbowtable. Vor allem nicht, wenn dynamische Salts verwendet worden sind.
                        --

                        „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


                        • #13
                          Zitat von Flor1an Beitrag anzeigen
                          Die Sicherheit sollte aber nie darauf beruhen das der Code geheim bleibt! Eigentlich sollte jeder wissen können wie dein Hash berechnet wird. Und ein Salt hilft nicht gegen normale Wörterbuchangriffe/Brute Force Angriffe, vor allem nicht wenn der Angreifer das über das normale Login Formular probiert.
                          Das habe ich auch nie behauptet. Es ist aber wichtig zu verstehen, welche Formen der Angriffe auf was abzielen und wie man sich gegen was wie wehrt.

                          Also. Hier ist extrem viel Unverständnis unterwegs und viel Naivität um nicht zu sagen fahrlässige Blödheit. Sorry, das soll keine Beleidigung sein, aber wacht bitte mal auf.

                          Zuerst zum Mythos der Rainbow-Tables. Das ist kein Mythos. Und anzunehmen, dass man mit Salts davor geschützt ist, das galt mal vor zehn Jahren. Mittlerweile ist diese Traumblase geplatzt. Wichtig: Salts, ob statisch oder dynamisch, können und werden geknackt werden.

                          Die Frage ist: Wie und wie schnell. Und das ist der Knackpunkt. Du sprichst von Brute-Force. Das ist albern und bestenfalls einem Freizeithacker ohne Ahnung zuzutrauen, dass er anhand von Bruteforce direkt auf dem Webserver versucht, ins System einzubrechen. Das ist lächerlich.
                          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. Zweitens bringt dir dieser Zufallstreffer kaum was. OK, wenns der Admin-Account war, freut man sich. Aber der Preis ist, ob gesalzen oder nicht, zu hoch. Da du den Salt nicht kennst, wird es fast unmöglich sein, seriöse Auswahlen zu treffen, welche 50 Millionen Passwörter ausprobiert werden sollen.

                          Kommen wir zur zweiten Variante: Bruteforce bei Kenntnis von gewissen Konstanten der Gleichung.
                          Du könntest einen eigenen Account anlegen. Das Passwort ist dir bekannt (du hast den Account angelegt). Nun kannst du per Bruteforce hoffen, so viele Zufallstreffer zu landen, dass du die richtige Rainbow-Table und damit den richtigen Salt eingrenzen kannst. Sobald du mal zwei drei Zufallstreffer hast, wird das Eingrenzen sehr schnell gehen. Aber: Bis du die hast, stehst du wieder vorm ersten Problem: Es fällt auf.
                          Und was dann? Was fängst du mit der Info der richtigen Tabelle an?

                          Also dritte Variante: Du kennst das Ergebnis der Gleichung, den Hash. Das ist der Jackpot. Denn wenn du den Hashcode kennst, kannst du ohne dass es der Webseitenbetreiber kennt, über ein Botnetzwerk oder am rechner zuhause (wie auch immer) die Rainbow-Tables durchprobieren. Du streichst damit direkt das Problem, dass der Webseitenbetreiber die Bruteforce-Attacke überhaupt bemerkt.

                          Du merkst also: Ein zuverläössiger Eingriff funktioniert nur, wenn du a) mit dem Brecheisen und extrem auffällig über Wochen die Webseite attackierst oder b) bereits relativ unbemerkt per SQL-Injection o.ä. ein Schlupfloch hast, die Datenbank auszulesen.
                          Wenn du aber bereits soweit Zugriff hattest, wieso dann überhaupt noch die Mühe mit den Rainbow-Tables? Wieso dann nicht über das gleiche Schlupfloch einen Update, wo dem eigenen user Admin-Recte zugestanden werden?
                          Was ich damit sagen will: 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.

                          So. Kommen wir zu einem Spezialfall. Sony. Nehmen wir mal an, die hätten ungesalzene MD5-Hashes verwendet. Nun greifen diese Hacker die Datenbank ab. Das ist der Jackpot. Accounts/Passwörter, die ein User auf einer anderen Webseite, meinetwegen Facebook, verwendet und die ebenfalls ungesalzen gespeichert werden, sind plötzlich hackbar. Ohne dass es jemand mitbekommt.
                          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.

                          Also bitte. Denkt bei MD5 nicht daran, einen Einbruch zu verhindern. Ob MD5, ob geslazen, ob dynamisch oder statisch, ob im Klartext, das alles ist solange egal, solange niemand ins System einbricht. Sobald einer ins System einbricht, ist es nur eine Frage der Zeit und eine Frage, ob der Hacker auffällig wird, bis die Passwörter endgültig geknackt sind.
                          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


                          • #14
                            Sorry, aber das ist mir zu pauschal.
                            --

                            „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


                            • #15
                              Zitat von kidding Beitrag anzeigen
                              Zitat von Wikipedia
                              Sie gilt inzwischen nicht mehr als sicher, da es mit überschaubarem Aufwand möglich ist, unterschiedliche Nachrichten zu erzeugen, die dieselbe MD5-Prüfsumme aufweisen.
                              Ist ja auch in sofern logisch, da ein MD5 Hash ja nur 32 Zeichen hat und nur Kleinbuchstaben sowie Zahlen enthält.
                              Das es Kollisionen gibt ist logisch, dass diese aber mit "überschaubarem Aufwand" gefunden werden können ist ein Problem. Für die Sicherheit von gehashten Passwörtern stellt das kein Problem dar. Um eine Kollision zu berechnen brauchst du den Orginalwert. Also selbst im ungünstigen Fall, ein gehastes Passwort ohne Salt, stellt das noch kein Problem dar. Kommt der Angreifer an den Hash nutzt ihn das Wissen das MD5 unsicher ist nix. Er brauch tortz dem etwas wie Brute Force, Wörterbücher oder Rainbow Tables.

                              Es gibt aber andere Verwendungszwecke und da stellt das ein großes Problem dar. Nimmt man MD5 um den Inhalt einer Nachricht zu verifizieren wirds kritisch. (Digitale Signaturen) Ein Angreifer ist es möglich den Inhalt einer Nachricht zu ändern ohne das die Signatur ihre gültigkeit verliert. Katastrophe!

                              Kommentar

                              Lädt...
                              X