Ich verstehe nich warum Golem nicht mal richtig forscht...

[VigarLunaris]

Mit ein paar kleinen Suchanfragen gelangt man bereits zu ergebnisse mit FREI verfügbaren Hashed PW Rainbow Tables.

Nehmen wir mal die "halb" offiziellen Seiten: https://project-rainbowcrack.com/table.htm diese bieten direkt und frei Hause 1-10 Stellen am PW an.

Bei : https://freerainbowtables.com/ wird man schnell sehen das PW Tables für bis zu 48 stellige PW Kombination existieren. (MD5)

Wer entsprechend tiefer beginnt zu graben, stolpert dann über die 40-60 TB "Trümmer" welche auch PWs mit Längen bis 88 Chars abdecken und manche auch darüber hinaus.

Der Rest ist nun nur noch die Frage nach:

1) Speicherplatz
2) Entsprechend schnelle such Mechanismen

Das dies in der heutigen Zeit "kein wirkliches" Problem mehr darstellen, sollte jedem inzwischen klar geworden sein.

Also ist die Herausgabe eines hashed PW nichts anderes als das man einen entsprechenden Rechenaufwand für X Minuten erzeugt und entsprechende Kosten für die Vorhaltung der Daten und zugehörigen Suchtools.

Die meisten Datenbank werben ja immer mit ihrer Performance. Bei richtigen Datenmodell, Serverdesign und Netzwerk aufbau, erreicht man entsprechend schnelle Zugriff auf die Datenmengen.

Somit können jenseitz der Terrabyte Grenze, in annehmbaren Zeiten von wenigen Stunden vollständig abgesucht werden und entsprechende Findings genutzt werden um sich am Nutzerkonto anzumelden.

Spezialisierte Programme und Datenbanken, schaffen ggf. den Aufwand von Stunden auf <= 1 Stunde zu reduzieren. Somit ist auch das "knacken" von vielen Benutzerkonten kein Problem mehr, inbesondere deshalb das die meisten PWs <=20 Zeichen sind.

Also bleibt eigentlich nur noch übrig, das man zur Zeit die PW-länge auf unrealistische größen expandiert und darauf wartet das alternative Methoden zur Datenverspeicherung + Verschlüsselung die Daten gegen Fremdzugriff schützen.

Aktuell ist das Knacken von PW + Datenverschlüsselung, bei vorhandensein des Hash, mehr eine Frage von Geld und Hardware, als denn von Methoden.

[ibsi]

Das funktioniert auch mit Salz und Pfeffer so gut und schnell? Wenn nicht, sollte das heute irrelevant sein

[VigarLunaris]

ibsi schrieb:
--------------------------------------------------------------------------------
> Das funktioniert auch mit Salz und Pfeffer so gut und schnell? Wenn nicht,
> sollte das heute irrelevant sein

Ist es leider nicht, da ein großteil der Passwörter immer noch als simpler PW gespeichert werden. Sprich MD5, NTLM, SHA1X/2X.

Da der Bericht auf PW's abzielt, muss man auch diesen Scope betrachten. Also nicht das wir einen Cipher lesen wollen, sondern ZUGANG zu einem Konto erlangen, ohne eben das zugehörige PW zu kennen.

Die Verbreitung von Mechanismen mit asymmetrischen Verfahren, bei der PW Speicherung, ist sehr gering.

PWs werden fast immer als Vergleichsstring (im erweiterten Sinn : symmetrisch) abgelegt. Oftmals werden auch nur Hash erzeugt und dann gespeichert. Bei div. Applikation mit erhöhter Sicherheitsanforderung gibt es noch encapsulation des Passwort.

Dabei wird das hashed PW mit einem asym. Verfahren nachverschlüsselt gespeichert. Der Zugang zum "Plain-Hash" ist dann nur noch auf der entsprechenden Maschine oder bei vorhandensein des entsprechenden privaten Schlüssel möglich.

Dieser ist dann aber fast immer für die Maschine und Administration im zugriff. Also liefert man gleich den Hash aus und danach geht es wieder so schnell.

Das man bei Anbietern von Mail usw. sowas vorfindet kann man getrost oftmals als unrealistisch ansehen, wie auch die meisten PW-Leak der letzten Jahre gezeigt haben.

Salt und Pepper können Sitzungsschlüssel, anmelde Daten usw. sein. Die blähen den "unsicheren" Plaintext "künstlich" auf und erhöhen somit den technischen Aufwand diesen zu knacken.

Aber auch hier gilt, wie beim BitCoin Minern auch, spezielle Hardware und Software halten das ganze im überschaubaren Rahmen. Letzendlich alles eine Frage der Hardware und des Geldes was man reinpacken möchte.

[twothe]

Algorithmen die nicht mit zufälligen Strings (aka Salt) arbeiten und damit anfällig für Rainbow-Table-Angriffe sind gelten in der Kryptografie inzwischen generell als unsicher. Moderne Algorithmen wie bcrypt/scrypt oder Argon2 versalzen dem Angreifer aber explizit die Suppe, so das man mit Datenbanken das Knacken der Passwörter nicht mehr beschleunigen kann.

Die Logik dahinter ist denkbar einfach: wenn bei jedem Nutzer "Passwort" zu "12345" gehashed wird, kann ich das Passwort über ein reverse-lookup (Rainbow-Table) ganz einfach ermitteln. Wenn aber zu jedem Passwort noch mal ein (pro Nutzer!) zufälliger String addiert wird ("Passwort" wird zu "Passwort98äü$4j#483") dann müsste ich theoretisch für jeden einzelnen Nutzer erst mal so eine Rainbow-Table generieren. Das dauert dann aber genau so lange wie jedes Passwort einzeln durch zu probieren, damit bringt mir die Datenbank keinen Zeitvorteil mehr.



1 mal bearbeitet, zuletzt am 01.05.20 13:45 durch twothe.

[hankaaron2]

Für den Inhalt deines Beitrags eine ziemlich freche Überschrift.
Hast du den Artikel überhaupt gelesen?

Ansonsten sind deine Ausführungen nicht falsch, aber eben nur in begrenztem Umfang gültig. Fast alle deine Aussagen stützen sich auf das Vorhandensein von Rainbow-Tables (die im Artikel übrigens erwähnt werden, deshalb meine Frage, ob du ihn überhaupt gelesen hast) und das auch noch in Verbindung mit MD5. Selbiges gilt für dein anderes Posting.

Den Einwand von ibsi hast du entweder nicht verstanden oder gekonnt ignoriert. Salz und Pfeffer machen deine Rainbow-Tables komplett nutzlos, ist dir das klar? Sobald dieser Faktor im Spiel ist, bleibt dir nichts anderes übrig, als Brute-Force anzuwenden, und zwar für jede einzelne User/Password-Kombination individuell. Nichts bereits berechnetes ist später nochmals wiederverwendbar.

Bleibt noch deine Annahme, dass Bruteforce auf Hashes mit vertretbarem Aufwand durchführbar ist und auch kein wirkliches Hindernis darstellt. Das gilt vielleicht für MD5, SHA256 und Co., aber nicht für Password-Hashing-Algorithmen wie bcrypt oder Argon2 (siehe Artikel). Für Bruteforce fallen hier CPUs/GPUs schonmal komplett raus. Bei bcrypt sind FPGAs und ASCISs aufgrund der schwachen Anforderung an Speicher noch attraktiv, bewirken aber keine Wunder (siehe diverse Paper zum Thema bcrypt cracking), und bei Argon2 fällt auch das weg. Je nach gewähltem Kostenfaktor des Algorithmus (der ist ja anpassbar) stellt das auch Sicherheitsbehörden vor Herausforderungen.

Es stimmt, dass Webseiten nach wie vor zu kurze Passwörter zulassen, Leute zu einfache Passwörter wählen, es Dienste gibt, die technologisch nicht auf der Höhe sind (MD5 ohne Salt war im Jahr 2005 schon nicht mehr Stand der Zeit). Aber der generelle Tonus deiner beiden Postings, Hashing erhöhe zwar den Aufwand, stellt aber niemand mit ernsten Absichten vor Probleme, ist falsch.



1 mal bearbeitet, zuletzt am 01.05.20 14:12 durch hankaaron2.

[bentol]

Danke für deine ausführlichen Erläuterungen!

[peter.peter]

Nach neuesten Annahmen, besteht das Universum aus ca. 10^84 bis 10^90 Atomen.

Abspeichern aller Möglichkeiten/HASHES , bis hin zu einer Länge von 88 Zeichen ist daher nicht Möglich (Nur Ziffern = 10^88 Möglichkeiten).

Bevor "Golem weiter richtig forscht", sollte der Kommentator erst einmal seine Mathematik und sein Verständnis für Zahlen auf Vordermann bringen!

Zum Verständnis:
Selbst wenn die gesamte Erde als Datenspeicher zur Verfügung stünde, würde dies nicht ausreichen, um alle HASHES (zb. 128 BIT) abzuspeichern.

Zum Rechnen:
Angenommen die Erde würde vollständig aus Silicon bestehen:

Masse der Erde = ca. 6 * 10^27 Gramm
Bytes = 2^128 * 16 = ca. 10^40
Massenzahl Silicon = 28


Zusätzliche Annahmen: Speicher hat eine Struktur. Speicher muss produziert werden. Speicher benötigt Energie. Speicher muss für das Betriebssystem strukturiert werden usw..

Viel Spaß beim Rechnen!

PS:
Des weiteren; Schon eine Passwortlänge von 20 Zeichen überschreitet MD5 = 2^128
(wraparound).

zb. 90^20 (90 = Zeichensatz und 20 = Länge Passwort)

Selbstverständlich, werden in der Regel nur kürzere Passwörter und daraus schließlich, die
entsprechenden HASHES gebildet. Der Benutzer ist eindeutig das limitierende Element.

Bis zu einer gewissen Länge ist es natürlich möglich, diese zu berechnen und abzuspeichern.

Aber selbst im 64 Bit Zahlenraum bedeutet 10^19, nichts anderes als
ca. 1TB * 18 Millionen.

[blubby666]

eine lookup table enthält soweit ich weiß alle zeichenkombinationen bis zur länge X. Das heißt wenn dein pw und der salt zusammen z.b. 40 zeichen lang sind und es gibt eine lookup table die alle hashes bis 40 zeichen beinhaltet, dann könnte der angreifer ja theoretisch doch auch deinen hash über die lookup table finden, oder nicht?

[blubby666]

Wie ich es verstanden habe enthalten lookup tables alle errechneten passwörter bis zur länge x. Wenn wir nun also einen salt und ein pw zusammen nicht länger als x sind und wir diese hashen, könnte diese kombination bereits in der lookup table stehen, oder irre ich mich da?

[peter.peter]

Ohne Salt wäre der HASH schnell gefunden worden, da sehr wahrscheinlich bei "a" gestartet worden wäre.

Da mit "Salt" das Passwort aber nicht "a", sondern zb. "ABCDEFGH" + "a" ist, erhöhen sich die Kombinantionen je nach Zeichraum auf "Zeichenraum^9" zb. "90^9".

90^9 entspricht ca. 3.8 * 10^17.

Zudem erhöht sich der Speicherplatz, da jeder HASH auch noch gespeichert werden muß, so das zum vollständigen speichern ca. 6 * 10^18 Bytes benötigt würden.

Zusätzlich, muß an die Verwaltungsinformationen gedacht werden, die auf dem Datenträger
benötigt werden.

Gehen wir einfach, von 10^19 Bytes aus.


10^19 Bytes wären aber zb. nichts anderes ca. 10 Millionen 1 TB Datenträger.

Selbst bei einer Erhöhung der Kapazität auf 10TB würden immer noch 1 Millionen Datenträger
erforderlich.

Ich denke, das selbst die großen Dienste in den USA, nur mit Mühe in der Läge wären
derartige Dimensionen zu stemmen.

Arbeit:
Hash berechen und auf 1 Millionen Datenträger a 10TB, speichern! Danach sortieren!

Frage:
Wie lange würde das dauern?
Wie hoch wäre der Energiebedarf?
Wieviel Datenträger gehen pro Tag kaputt?
usw. usw.

FAZIT:
Wie an diesem einfachen Beispiel ersichtlich, ist es unmöglich sehr Lange HASHES vollständig zu berechnen und zu speichern.

Die Kapazität des Universums ist für derartige Zahlen zu niederig ausgelegt!

Vom Zeitfaktor, will ich gar nicht reden!