Rainbow Table

Als Verteidiger: Du machst Rainbow Tables wertlos, indem du Salts benutzt. Wenn du hash(password + salt) speicherst, müsste der Hacker für jedes Salt eine eigene Rainbow Table berechnen. Da jeder User ein anderes Salt hat, ist das unmöglich (Speicherplatz reicht nicht). Deshalb sind "ungesalzene" Hashes (MD5 ohne Salt) heute eine Todsünde.

1. Hash Chains & Reduction Function

Eine einfache Tabelle ("Passwort -> Hash") wäre zu groß (Exabytes). Rainbow Tables nutzen einen Trick:

1. Nimm ein Passwort ("aaaaaa").
2. Hash es.
3. Nimm eine "Reduktionsfunktion" (mach aus dem Hash wieder ein Passwort, z. B. h8d3j2).
4. Hash es wieder.
5. Wiederhole das 10.000 Mal. Man speichert nur den Startpunkt und den Endpunkt der Kette. Wenn man einen Hash sucht, wendet man die Reduktionsfunktion an und schaut, ob man einen bekannten Endpunkt trifft. Dann verfolgt man die Kette vom Startpunkt, um das Passwort zu finden.

2. Erfolgswahrscheinlichkeit

Rainbow Tables decken nicht 100% aller Passwörter ab (Lücken in den Ketten). Man nutzt oft mehrere Tabellen mit unterschiedlichen Reduktionsfunktionen, um 99% Abdeckung zu erreichen.

3. Ophcrack

Ein bekanntes Tool, das Rainbow Tables nutzt, um Windows-Passwörter (LM/NTLM Hashes) in Sekunden zu knacken. Funktioniert nur, weil alte Windows-Versionen Passwörter oft ungesalzen oder schwach speicherten.

Das Oechslin-Prinzip (Time-Memory Trade-off)

Das Geniale, aber Mathematisch hochkomplexe an Philippe Oechslins Rainbow Tables liegt nicht in der reinen Liste, sondern in der Bekämpfung von Kollisionen. Wenn du in Hash-Ketten immer die gleiche Reduktionsfunktion (R) nutzt, enden irgendwann Millionen von Start-Passwörtern zwangsläufig zufällig beim gleichen Folge-Wort ("Merkel-Damgard-Kollision"). Beide Ketten verschmelzen – du rechnest ab da Millionen Hashes sinnlos doppelt und die Tabelle schrumpft drastisch an Wert (Deckungsgleichheit). Der Trick: Man nutzt pro Kettenglied eine völlig andere Reduktionsfunktion (R1 im Takt 1, R2 im Takt 2 etc.). Das fächert die Kettenstruktur wie einen Regenbogen auf. Trifft Kette A auf Kette B im völlig falschen Farb-Takt, kreuzen sich die Pfade nur kurz und verlaufen getrennt weiter. Kollisionsfreiheit steigt um Dimensionen.

Die Vernichtung der Rainbow Tables: Salt & Pepper

Wie bricht man diese gigantische Offline-Vorausberechnung? Durch winzige Manipulation der Input-Mathematik: Salting. Anstatt sha1("Passwort") speichert man sha1("Passwort" + "q8Xz!2_RandomString_Für_Diesen_User"). Der Angreifer müsste nun nicht eine universelle Rainbow-Table erzeugen (die für alle Server der Welt gilt), sondern eine gigantische 100-Terabyte-Matrix für jeden individuellen User in deiner Datenbank berechnen, da der Salt den Hash komplett in einen unberechneten Zahlenraum katapultiert. Es ist physikalisch unmöglich. Ergänzt wird dies im Backend durch Pepper (Pfeffer): Einen globalen, fixen String (geheimen Key), den der Server zusätzlich anfügt sha1(Passwort+Salt+Pepper), der lokal in der App-Config hartcodiert ist, aber nicht (!) in der SQL-Datenbank liegt. Selbst bei einem kompletten DB-Dump scheitert der Hacker, weil ihm der lokale Laufzeit-Server-Key (Pepper) zur Hash-Rekonstruktion fehlt.

Argon2 / Bcrypt: Die RAM-Hölle

Selbst wenn Salting existiert, versuchen Hacker oft brute-force per ASIC-Chips Milliarden Hashes/Sekunde zu werfen ("Mining Hardware"). Modernes Hashing (Bcrypt, Scrypt, Argon2) ist exakt konzipiert, um Rainbow-Tables und Brute-Force hardwareseitig zu foltern. Argon2 ist "Memory-Hard". Eine einzige Hash-Berechnung verlangt künstlich die Allokation von z.H. 1 GB schnellem Server-RAM, der wild durcheinander manipuliert wird. Dies kostet auf CPUs Zeit, ist aber schlichtwegh unmöglich auf GPUs/ASICs abzubilden, wodurch die Hash-Generierungs-Rate für Hacker von "Trillionen pro Sekunde" auf "Zwei pro Sekunde" zusammenbricht.