[HaBo]

ToxicJetzt!

Anzeige

Ich möchte jetzt mal genau wissen wie es damit aussieht. Anbieter von diverser Forensoftware behaupten md5, da es eine one-way-hash Funktion ist, dass es nicht rückzübersetzen ist außer mit Brutforce was ziemlich lange dauert bei einem "guten" Passwort.

Jedoch hat eben jemand in einem Forum behauptet er schafft jeden md5 Hash per Pre-Computing in maximal 9 Stunden zu "entschlüsseln", da md5 mittlerweile nicht mehr "sicher" ist.

Kann da was dran sein. Ich hab dem auf jeden Fall eben mal einen md5 Hash aus 100 Zeichen Müll inkl. Sonderzeichen gegeben

sheepd

Ist nicht mein Gebiet, aber ich würde mal sagen, der Typ hat geprahlt.

ivegotmail

Stichwort: Rainbowcrack tables

ist zwar immer noch brute force, aber wesentlich schneller als "normales" bruteforce.

__________________
http://livehabo.hackerboard.de | http://livebb.sourceforge.net

ToxicJetzt!

Danke erstmal.

Also so wie ich das sehe wird der meinen Hash erstmal nicht knacken

Elderan

Hallo,
Nein das stimmt so nicht.

Und zwar ist das ein "Time-Memory Trade-Off" Angriff.

Dabei werden alle möglichen Strings in eine Table geschrieben und die dazu gehörigen strings.
Möchte man Hash knacken, so wird der Hash in der Table gesucht und der dazugehörige String ausgegeben.
Dies ist natürlich schneller als Brute Force, aber:

Angenommen man nimmt 10 stellen Passwort, alphanumerisch (36 Zeichen), so gibt es 3× 10^15 mögliche Strings.

Jeder String hat 10 Byte und der Hash hat 16 byte, also 26 Byte pro Eintrag.

Das macht eine Tabellengröße von 7.8 × 10^16 Byte bzw. 70 940 Terrabyte.

Bei 12 Zeichen wären es 101 863 407 Terrabyte.

Ich möchte bezweifeln das jmd. schon eine so gigantische Festplatte besitzt.

Ergo wäre es nicht möglich eine Table für eine große Menge an Strings zu speichern. Abgesehen davon es dauert immer noch lange 10^15 Hashs zu überprüfen und eine 3 GB große Table zu generieren dauert über 15 Tage.

Wie du siehst, es hängt immer noch von der länge des Passwortes ab. Sofern das Passwort sicher genug ist, gibt es bisher keine öffentlich bekannte Möglichkeit das Passwort innerhalb eines Menschenlebens zu brechen.

ToxicJetzt!

Dann sollte er es wohl nicht schaffen ein Passwort mit deutschen Umlauten zu knacken

Vielleicht hätte ja jemand Lust so ein Projekt zu starten. Wie sieht das eigentlich rechtlich aus? Darf man so eine Seite betreiben? Schließlich kann man doch nicht kontrollieren ob die Leute ihre eigenen Passwörter oder fremde wiederherstellen. Aber eigentlich sind sie mit dem Hash doch schon in Besitz der Passwörter ?(

Aber ich bezweifle, dass hier jemand einen Server mit einer Festplatte hat, die groß genug ist

silenced

Das Password mit dem der Hash erzeugt wird ist egal.
Hauptsache der Hash ist identisch. Ergo wenn´s dumm läuft kann ich deinen 2000 byte langen Passphrase mit 2 Buchstaben knacken.

NeonZero

Genau. Das ist auch ein stark verbreiteter Denkfehler, den viele machen: Sie halten den Hash für ein verschlüsseltes Passwort.

@ToxicJetzt!

Hier eine kurze Erklärung:

Bei dem theoretischen Modell einer vollständigen Hash-Tabellen-Liste sind diese Strings für die Tabelle uninteressant. Um das zu verstehen, muß zunächst einmal klar sein, was ein Hash überhaupt ist: Ein Hash-Algorithmus bildet aus einem beliebig großen Wert einen Wert mit einer fest vorgegebenen Größe. Im Beispiel von Elderan ist der erzeugte Hash immer 16 byte groß ? egal ob das eingegebene Passwort 10, 100 oder halt nur 2 Zeichen lang ist. Damit eignet sich der Hash-Wert hervorragend als Prüfsumme in einer DB, in der man eine feste Größe pro Eintrag vorgesehen hat.

Niemand kann Anhand des Hash-Wertes den Ursprungswert (in diesem Fall das Passwort) zurückrechnen. Der Grund: Mehrere unterschiedliche Ursprungswerte können ein und denselben Hash-Wert bilden. Das bedeutet, dass es mehrere mögliche Zahlen und Buchstabenkombinationen gibt, die denselben Hash erzeugen und damit als gültiges Passwort erkannt werden. Solche gültigen ?Nebenpassworte? lassen sich gut mit Brute Force ermitteln (ohne Wörterbuch!).

In der Tabelle müssen demzufolge also ?nur? alle möglichen Hashes abgebildet werden, welche in die 16 Bytes hinein passen. Und dahinter benötigt man einfach >>eine<< (möglichst kurze) Zeichenkombination, welches eben diesen Hash erzeugt. So erhält man schnell ein >>gültiges<< Passwort für den Hash, welches sich allerdings mit hoher Wahrscheinlichkeit stark von dem Originalpasswort unterschiedet. Das ist aber egal, denn es ist gültig. Ein Nebenpasswort eben.

Das Problem: "nur" 16 Byte sind alles andere als "nur". Das ist viel zu groß, um mit den heutigen Mitteln eine Tabelle mit sämtlichen Kombinationsmöglichkeiten zu erstellen. Deshalb gibt es zum einen Teiltabellen mit Hashwerten beliebter Passworte (somit muß der Hash dafür nicht mehr berechnet werden) oder aber es gibt, wie Elderan beschrieben hat, Tabellen mit Passworten für eine bestimmte Anzahl von Zeichen. Darin wird für jede gültige Passwortkombination der Hash eingetragen (damit spart man sich ebenfalls die Berechnung). Allerdings hat er in seiner Berechnung die Großbuchstaben und Sonderzeichen unterschlagen. Bei einem 10 Zeichen langen Passwort dürften 70.940 Terrabyte für die Tabelle noch lange nicht reichen.

Zusammengefaßt kann man sagen, daß es nach den heutigen technischen Mitteln nur Hash-Tabellen gibt, welche nach "gut glück" ausgewertet werden können - alle Kombinationen sind dort nicht enthalten. Zumindest nicht für Tabellen ab 5 Zeichen langen Passworten, inkl. Sonderzeichen.

Bye, nz

ToxicJetzt!

Aber bei 100 Stellen mit allen Zeichen bräuchte er für Rainbow doch eine so große Tabelle, die auf keine Festplatte passt, weil es so viele verschiedene Kombinationen gibt und somit ist das Passwort sicher, oder?

Kan00s

sagen wir mal so es ist relativ sicher.

Denn irgendwo gibt es bestimmt einen so großen Speicher allerdings werden die ihn glaube ich nicht für so etwas verwenden

Elderan

Hallo,
Nein das stimmt nicht ganz, das ist Ziel einer Hashfunktion.

Es gibt Hashfunktionen, z.B. md4, für die es eine Rückrechnung gibt.
Zwar muss nicht 100% das richtige PW bekommen, aber innerhalb kurzer Zeit bekommt man einen String der zum Einloggen ausreicht.

Quersummen sind praktisch auch simple Hashfunktionen.
Um die Quersumme 5 zurück zu rechnen kann ich z.B.
11111 als PW benutzen oder: 23 oder 41 etc.

Also es kann sein das man in Zukunft für MD5 sehr schnell Kollisionen für einen String findet => Passwort Hash kann nicht mehr sicher als Identifikation benutzt werden.

Bei md5 gibt es 2^128 mögliche Hashwerte oder 10^38 Hashwerte.

Jeder davon nimmt 16 Byte (oder 128 Bit), das sind also 5,4× 10^39 Byte oder 4.95176016 × 10^27 [b]Tera[b]byte. Das ist eine Zahl mit 28 Stellen!!

Dazu kommt noch der String der auch im durchschnitt wieder 16 Byte wegnimmt, das wären dann 9.90352031 × 10^27 Terabyte

Außerdem neue Computer schaffen ca. 15 bis 20 Mio. Keys/Sek bei Brute Force, die Erstellung würde extrem viel länger dauern, denn bei Brute Force muss er die Hashs nur überprüfen, jetzt muss er noch den Hash+String in die Datei schreiben und natürlich vorher überprüfen ob es den Hash schon gibt.

Egal sagen wir, wir schreiben dennoch 15 Mio Keys/Sek dann würde es 7.19352205 × 10^23 Jahre dauern dieses File zu schreiben.

Das wäre 5.13823003 × 10^13 mal länger als es das Universum (ca. 14 Mrd. Jahre) gibt.

Noch mal zur Speichermenge:

In einem Gramm DNA könnte man den Inhalt von 1 Bio. CD's speichern, also 7 * 10^14 MB.

Diese DNA Festplatte müsste 1.48351339 × 10^19 Gramm oder 1.48351339 × 10^16 kg wiegen.

P.S. Falls ich Fehler in den Berechnungen gemacht habe bitte Melden. Kann momentan nur per Google rechnen


Noch mal ein andere Thread dazu:
Welche Zeichensätze für Passwort verwenden?
Letzter Beitrag ist auch nochmal eine Rechnung dazu.


Hab den Zeichensatz: a-z 0-9 benutzt da dieser Geläufig ist. Falls man 62 Zeichen (a-z A-Z 0-9) benutzt ist das noch gigantischer.

MD5 "kürtzt" beliebig lange Texte auf eine Fest größe, 128 Byte bzw. 16 Byte.

Würde man alle 256 Zeichen benutzen, so würden sich die Passwörter mit einer größe > 16 wiederhohlen, das kann man aber nicht berrechnen.

So etwas nennt man Kollision und kann auch z.B. bei 2 Strings mit einer länge von 5 Zeichen auftreten. Die Wahrscheinlichkeit ist aber 1 zu 10^38 also pratisch "unmöglich".

Benutzt man 36 Striftzeichen (a-z 0-9) so müsste man ca. alle Strings mit 25 Stellen (8.08281277 × 10^3 speichern.
Dann hätte man eine gute Chance, eigentlich jeden Hash in der Table stehen zu haben.

Aber falls jmd. sehr große Tables hat, so dauert es auch wieder lange diese zu durchsuchen, aber längst nicht so lange wie neue zu erstellen.

Deswegen glaub ich sind Alphanumerische (a-z 0-9) Tabellen mit 7 Stellen ca. 20 GB groß, das nimmt dann aber expotentiell zu.

Also bis 7 Stellen kann man solche angelgen wenn man nichts zu tun hat, aber falls der User ein 10 Stellen Passwort mit Zahlen, groß+klein Buchstaben + evt. Sonderzeichen hat, wird es heutzutage unmöglich sein dieses Passwort zu knacken.

Also kann man sagen => die Sicherheit des Logins hängt nicht vom Hashalgorithmus ab, sondern vom Passwort.

Man sollte sich lieber über Fehler im System machen oder über Lauscher in der Leitung.

Dann soll er mal bitte: bd46d53b07bee367aefd7d3e90e61ec9

entschlüsseln. Das ist ein 12 Stellen string mit Zeichensatz: a-z 0 -9

Und als Angreifer weiß man nie wie lange und welchen Zeichen der User benutzt.

n00by

Echt? also ich hab ne 2 Ghz CPU und hab ~20/Sek?!

Elderan

Hallo,
Lol ich denke mal du hast ein Brute Force Angriff per Web auf ein Formular/htaccess/FTP gemacht.

Da wird die Key Rate vorallem durch die Bandbreite gedrosselt.

Aber wenn du den Hash hast, so können Programme versuchen den Hash lokal zu knacken.
Dabei müssen keine Daten per Internet gesendet werden

Ich habe einen 1,5Ghz und liege bei ~5,x Mio Keys/Sec.

P2X-738

womit kann man denn am besten die hashwerte zurück lösen?
ich habe john the ripper, aber das dauert teilweise ewig

SUID:root

Selbst wenn es heute nicht soweit ist, dann doch in absehbarer Zeit.
Wenn ich zurück denke, an eine Zeit, sagen wir mal vor 10 Jahren:
PI, 133 Mhz, 16 MB Ram, 1,7 GB HD.

und das dann mit der heutigen Rechenleistung und der heutigen Speicherkapazität vergleiche, dann wird mir schwindlig.
Ich glaube, dass es nur noch eine Frage von einigen Jahren sein wird, bis wir genügend Rechenleistung besitzen um die Tables in einer vernünfitgen Zeit erstellen und speichern zu können.

root