Veröffentlicht 9. November 20186 j Hallo mal eine Frage zu den Hash Werten, Die Theorie sitzt ? Nur habe ich noch ein paar fragen hinsichtlich potentieller "Sicherheitslücken". Nehmen wir den SHA256: hallo -> D3751D33F9CD5049C4AF2B462735457E4D3BAF130BCBB87F389E349FBAEB20B9 Die Zeichenkette "D3751D33F9CD5049C4AF2B462735457E4D3BAF130BCBB87F389E349FBAEB20B9´" ist doch endlich und bei jeden anderen Eingabewert IMMER gleich begrenzt • was macht sie dann nicht zurückentschlüsselbar wenn man mittels bruteForece oder wordList verschiedene Eingabewerte generiert (+Hash) und den Hash einfach vergleicht? • 2. warum kann man mit dem SHA256 Algorithmus den Hash nicht encoden oder BruteForcen? mfg Bearbeitet 9. November 20186 j von derPat18
9. November 20186 j vor 15 Minuten schrieb derPat18: • was macht sie dann nicht zurückentschlüsselbar wenn man mittels bruteForece oder wordList verschiedene Eingabewerte generiert (+Hash) und den Hash einfach vergleicht? Das ist dann kein "entschlüsseln" sondern eben bruteforcen. Je nach Hashing-Algorithmus und Länge der Zeichenkette dauert sowas ewig. Mit Wordlist meinst du Rainbowtables? Wenn es um z.B. Passwörter geht, wird dem Passwort des Users noch etwas angehangen, Salt, um eben die üblichen oder einfachen Passwörter nochmal ein bisschen obskurer zu machen und zu verlängern. Zudem werden Passwörter oft nicht nur einfach gehashed sondern öfter und jedes mal wird noch ein bisschen mehr Zeug drangehangen. Ich hatte auf stackoverflow mal eine sehr ausführliche Antwort zu dem Thema gesehen, finde die aber gerade nicht. vor 18 Minuten schrieb derPat18: warum kann man mit dem SHA256 Algorithmus den Hash nicht encoden oder BruteForcen? Was meinst du damit?
9. November 20186 j vor 28 Minuten schrieb derPat18: • 2. warum kann man mit dem SHA256 Algorithmus den Hash nicht encoden oder BruteForcen? Wenn ich die Frage richtig verstehe: Das ist ja gerade der Sinn von Hashfunktionen. Sie sind Einwegfunktionen, daher kann aus einem vorliegenden Hashwert der Klartext nicht wiederhergestellt werden. "BruteForce" ist grundsätzlich möglich, eben mit RainbowTables o.Ä. Ich empfehle für die Grundlagen bzgl. Funktionsweise und möglichen Angriffen den tatsächlich sehr guten Wikipediaartikel: https://de.wikipedia.org/wiki/Kryptographische_Hashfunktion Wenn du Kollisionsresistenz, Einwegfunktion usw. im Detail verstehen wllst musst du allerdings etwas tiefer in die Mathematik abtauchen
9. November 20186 j Du verwechselst hashen mit verschlüsseln. Das sind zwei unterschiedliche Dinge. Hashs sind One-Way und sollen eigentlich nicht reversibel sein, da sonst eine https://de.wikipedia.org/wiki/Preimage-Angriff möglich ist. Bearbeitet 9. November 20186 j von KeeperOfCoffee
9. November 20186 j vor 43 Minuten schrieb derPat18: was macht sie dann nicht zurückentschlüsselbar Ein Hash lässt sich per Definition nicht auf die Eingabe zurückrechnen. Lässt sich ganz einfach demonstrieren. HASHALGORITHMUS erzeugt bspw. Zeichenketten der Länge 64. Jetzt hast du aber eine Eingabe von Länge 65. Logischerweise musst du also sog. "Kollisionen" haben, d.h., zwei Eingaben, die die gleiche Ausgabe erzeugen. Jetzt ist aber die Menge der Eingaben unendlich (jede beliebige Eingabe) - die Menge der Ausgaben jedoch begrenzt (auf Zeichenketten der Länge 64). Daher kannst du nie sagen, welche Nachricht der Input für den Hashalgorithmus war. Man kann manchmal gut raten, weil manche Eingaben mehr Sinn machen als andere, aber mehr auch nicht. BruteForce geht immer. Dauert nur eben bei starken Algorithmen im Zweifel länger als das Universum noch existiert. Rainbowtables sind auch eine Möglichkeit - best practice ist daher, nie direkt den Input zu hashen, sondern immer einen zufälligen Wert zu ergänzen (genannt "Salt"), der dazu führt, dass das "passwort123" von User1 anders gehasht wird als das "passwort123" von User2. Auf https://crypto.stackexchange.com und https://security.stackexchange.com gibt's einige Fragen und Antworten in deine Richtung, die sicher hilfreich sind. Zu "Salt" bspw: https://crypto.stackexchange.com/questions/1776/can-you-help-me-understand-what-a-cryptographic-salt-is Bearbeitet 9. November 20186 j von arlegermi
9. November 20186 j Autor vor 1 Stunde schrieb deleurme: Ich empfehle für die Grundlagen bzgl. Funktionsweise und möglichen Angriffen den tatsächlich sehr guten Wikipediaartikel: https://de.wikipedia.org/wiki/Kryptographische_Hashfunktion danke! sehr guter artikel vor 1 Stunde schrieb PVoss: Was meinst du damit? ich meinte zwar wenn ich einen alghorithmus habe, kann ich ja logischerweise den alghorithmus "rückabwickeln". vor 1 Stunde schrieb arlegermi: Ein Hash lässt sich per Definition nicht auf die Eingabe zurückrechnen. Lässt sich ganz einfach demonstrieren. HASHALGORITHMUS erzeugt bspw. Zeichenketten der Länge 64. Jetzt hast du aber eine Eingabe von Länge 65. Logischerweise musst du also sog. "Kollisionen" haben, d.h., zwei Eingaben, die die gleiche Ausgabe erzeugen. Jetzt ist aber die Menge der Eingaben unendlich (jede beliebige Eingabe) - die Menge der Ausgaben jedoch begrenzt (auf Zeichenketten der Länge 64). Daher kannst du nie sagen, welche Nachricht der Input für den Hashalgorithmus war. Man kann manchmal gut raten, weil manche Eingaben mehr Sinn machen als andere, aber mehr auch nicht. BruteForce geht immer. Dauert nur eben bei starken Algorithmen im Zweifel länger als das Universum noch existiert. Rainbowtables sind auch eine Möglichkeit - best practice ist daher, nie direkt den Input zu hashen, sondern immer einen zufälligen Wert zu ergänzen (genannt "Salt"), der dazu führt, dass das "passwort123" von User1 anders gehasht wird als das "passwort123" von User2. Auf https://crypto.stackexchange.com und https://security.stackexchange.com gibt's einige Fragen und Antworten in deine Richtung, die sicher hilfreich sind. Zu "Salt" bspw: https://crypto.stackexchange.com/questions/1776/can-you-help-me-understand-what-a-cryptographic-salt-is gut erläutert danke! vor 1 Stunde schrieb KeeperOfCoffee: Du verwechselst hashen mit verschlüsseln. Das sind zwei unterschiedliche Dinge. Hashs sind One-Way und sollen eigentlich nicht reversibel sein, da sonst eine https://de.wikipedia.org/wiki/Preimage-Angriff möglich ist. ja stimmt, habe ich jetzt auch gelesen, wie genau der OneWay funktioniert will ich lieber nicht wissen, da es da glaube ich ZU TIEF geht...
9. November 20186 j vor 4 Minuten schrieb derPat18: ich meinte zwar wenn ich einen alghorithmus habe, kann ich ja logischerweise den alghorithmus "rückabwickeln". Nicht zwingend. Wenn du eine Tasse fallen lässt (was ja auch streng genommen ein Algorithmus ist), kannst du dies auch nicht wieder "rückabwickeln". Auch kannst du bei einer berechneten Zahl (selbst wenn bekannt ist, wie diese berechnet wurde), nicht direkt auf die Werte zurückschließen, aus denen diese berechnet wurde. Wenn der Algorithmus zum Beispiel Zahl1 * Zahl2 ist. Kannst du nicht sicher sagen, dass bei einem Ergebnis von 64 Zahl1=4 und Zahl2=16 war. Und eine Hashfunktion ist um ein vielfaches komplexer.
9. November 20186 j Autor ist es nicht rein theoretisch möglich, den Hash Alghorithmus so abzuändern, das jede mögliche eingabe am rechner für DIESEN (ausgelesenen) Hash wert passt?
9. November 20186 j Autor Gerade eben schrieb Rienne: Nicht zwingend. Wenn du eine Tasse fallen lässt (was ja auch streng genommen ein Algorithmus ist), kannst du dies auch nicht wieder "rückabwickeln". Auch kannst du bei einer berechneten Zahl (selbst wenn bekannt ist, wie diese berechnet wurde), nicht direkt auf die Werte zurückschließen, aus denen diese berechnet wurde. Wenn der Algorithmus zum Beispiel Zahl1 * Zahl2 ist. Kannst du nicht sicher sagen, dass bei einem Ergebnis von 64 Zahl1=4 und Zahl2=16 war. Und eine Hashfunktion ist um ein vielfaches komplexer. ok stimmt da gebe ich dir recht =P ^^
9. November 20186 j vor 1 Minute schrieb derPat18: ist es nicht rein theoretisch möglich, den Hash Alghorithmus so abzuändern, das jede mögliche eingabe am rechner für DIESEN (ausgelesenen) Hash wert passt? Und was wäre der Sinn dahinter einen solchen Hash-Algorithmus zu entwickeln bzw. zu nutzen? Es soll ja eben nicht JEDE Eingabe passen, sondern nur eine bestimmte (z.B. eben das passende Passwort).
9. November 20186 j Autor Gerade eben schrieb Rienne: Und was wäre der Sinn dahinter einen solchen Hash-Algorithmus zu entwickeln bzw. zu nutzen? Es soll ja eben nicht JEDE Eingabe passen, sondern nur eine bestimmte (z.B. eben das passende Passwort). ich weiss was es soll, ich denke jetzt mal "BÖSE" im sinne eines angreifers ... (nicht das ich das mache bzw machen will)
9. November 20186 j vor 15 Minuten schrieb derPat18: ich weiss was es soll, ich denke jetzt mal "BÖSE" im sinne eines angreifers Der "Angreifer" hat aber doch erst einmal gar keine Möglichkeit den genutzten Algorithmus zu ändern.
9. November 20186 j Wenn er die Möglichkeit hätte, könnter er den Alorithmus auch umgehen und den Hashvergleich durch return true; ersetzen. Bearbeitet 9. November 20186 j von PVoss
9. November 20186 j Wunder mich etwas, warum man sich im ersten Jahr mit sowas beschäftigt. Bearbeitet 9. November 20186 j von KeeperOfCoffee
9. November 20186 j vor 11 Stunden schrieb PVoss: Wenn er die Möglichkeit hätte, könnter er den Alorithmus auch umgehen und den Hashvergleich durch return true; ersetzen. Wohl eher im Assemblercode/Bytecode die Sprungmarke ändern. So funktionieren auch einfache Cracks.
12. November 20186 j Am 9.11.2018 um 11:45 schrieb derPat18: ich meinte zwar wenn ich einen alghorithmus habe, kann ich ja logischerweise den alghorithmus "rückabwickeln". Ebenfalls ganz einfaches Beispiel: Dein Algorithmus addiert zwei Zahlen. Wenn da jetzt als Ergebnis die 42 rauskommt kannst du ja nix rückabwickeln und hast keine Möglichkeit zu wissen ob das jetzt 41+1, oder 35+7 oder sont was war
Erstelle ein Konto oder melde dich an, um einen Kommentar zu schreiben.