Du hast wahrscheinlich gelesen, dass Websites dein Passwort als „Hash" statt als echten Wert speichern. Wie also verwandeln Angreifer, die diese Hashes stehlen, sie wieder in Passwörter? Eine der ältesten und cleversten Antworten ist die Rainbow Table - und wenn man sie versteht, erklärt das auch, warum eine kleine Technik, das Salting, sie leise aushebelt.
Was eine Rainbow Table ist
Wenn du ein Konto erstellst, speichert eine gute Website nicht dein tatsächliches Passwort. Sie speichert einen Hash: das Ergebnis einer Einwegfunktion, die das Passwort in eine feste Zeichenkette verwandelt, und zwar so, dass es sich nicht einfach umkehren lässt. Wenn jemand die Datenbank stiehlt, bekommt er die Hashes, nicht die Passwörter - und er muss immer noch herausfinden, welches Passwort jeden Hash erzeugt hat.
Eine Rainbow Table ist ein Weg, das schnell zu erledigen. Sie ist eine riesige, vorberechnete Nachschlagetabelle, die Hashes mit den Passwörtern verknüpft, die sie erzeugt haben. Der Angreifer erledigt die aufwendige Hash-Arbeit im Voraus, speichert sie kompakt und schlägt dann einfach jeden gestohlenen Hash nach. Das ist die ganze Idee: jetzt Speicher aufwenden, um später Zeit zu sparen.
Wie der Angriff funktioniert
Einen Hash per Brute Force zu knacken bedeutet, jeden möglichen Rateversuch live zu hashen, bis einer passt - korrekt, aber im großen Maßstab langsam. Rainbow Tables beschleunigen das mit einem cleveren Speichertrick. Statt jeden Hash zu sichern, bauen sie lange Ketten aus abwechselnden Hash- und Reduktionsschritten auf und speichern nur den Anfang und das Ende jeder Kette. Das hält eine sonst unmöglich große Tabelle klein genug, um nützlich zu sein. Um einen gestohlenen Hash zu knacken, baut der Angreifer die relevante Kette wieder auf und ermittelt das ursprüngliche Passwort.
Warum Salting sie aushebelt
Hier kommt der wichtige Teil und die gute Nachricht. Eine Rainbow Table funktioniert nur, wenn ein bestimmtes Passwort immer denselben Hash erzeugt. Die Verteidigung ist ein Salt: ein eindeutiger, zufälliger Wert, der jedem Passwort vor dem Hashen hinzugefügt wird. Mit Salts pro Nutzer erhalten zwei Personen mit identischem Passwort völlig unterschiedliche Hashes, und eine vorberechnete Tabelle ist wertlos - der Angreifer bräuchte eine eigene Rainbow Table für jeden möglichen Salt, was nicht praktikabel ist.
Moderne Systeme gehen noch weiter und kombinieren Salts mit absichtlich langsamen Hash-Funktionen wie bcrypt, scrypt oder Argon2. Langsames Hashing macht selbst das Live-Raten teuer, und Salting beseitigt die Abkürzung der Vorberechnung. Zusammen machen sie Rainbow Tables zu einer überwiegend historischen Bedrohung - gefährlich gegen alte oder schlecht gebaute Systeme, die ungesalzene Hashes speichern, aber neutralisiert von jedem, der Passwortspeicherung heute korrekt umsetzt.
Wie sie sich mit anderen Angriffen vergleicht
Es hilft, Rainbow Tables neben die Angriffe zu stellen, mit denen sie oft verwechselt werden:
- Brute Force hasht jede mögliche Kombination live, bis eine passt - langsam, ausgehebelt durch lange Passwörter. Siehe was ein Brute-Force-Angriff ist.
- Dictionary Attack probiert eine Liste wahrscheinlicher Passwörter statt aller Kombinationen - schneller, ausgehebelt dadurch, dass man keine gängigen oder wiederverwendeten Passwörter nutzt.
- Credential Stuffing spielt echte geleakte Nutzername-Passwort-Paare erneut ab - ausgehebelt durch eindeutige Passwörter. Siehe was Credential Stuffing ist.
- Rainbow Table berechnet die Hash-Arbeit vor und schlägt sie nach - gezielt ausgehebelt durch Salting.
Was das für dich bedeutet
Du kannst nicht steuern, wie eine Website ihre Hashes speichert, und seriöse Seiten salzen und slow-hashen bereits, was Rainbow Tables sofort stoppt. Was du steuern kannst, ist das Eine, das den Schaden begrenzt, wenn eine Seite es falsch macht: ein eindeutiges, langes Passwort für jedes Konto. Wenn eine Seite Hashes schlecht speichert und ihre Passwörter geknackt werden, legt ein Passwort, das du nirgendwo sonst verwendet hast, nichts über dieses eine Konto hinaus offen. Ein Passwort-Manager macht das Erzeugen und Speichern dieser eindeutigen Passwörter mühelos, was die praktische Erkenntnis hinter jedem einzelnen dieser Angriffe ist.
★ Audit Cure53 2024 · ✓ Plan gratuit · Cross-platform
Sichere deine Konten ab → NordPassStarke, einzigartige Passwörter · Leck-Scanner · Gratis-Tarif→Häufig gestellte Fragen
Was ist eine Rainbow Table?
Eine Rainbow Table ist eine große, vorberechnete Tabelle, die Passwort-Hashes den Passwörtern zuordnet, die sie erzeugt haben. Websites speichern Passwörter als Hash statt im Klartext, sodass ein Angreifer, der die Hash-Datenbank stiehlt, die ursprünglichen Passwörter erst noch ermitteln muss. Statt jeden Rateversuch an Ort und Stelle zu hashen, erledigt eine Rainbow Table diese Arbeit im Voraus und speichert die Ergebnisse in kompakter Form, sodass der Angreifer einen gestohlenen Hash nachschlagen und das passende Passwort schnell finden kann. Es ist ein klassischer Zeit-gegen-Speicher-Tausch: viel Speicher im Voraus im Austausch für schnelles Knacken später.
Wie funktioniert ein Rainbow-Table-Angriff?
Passwörter werden meist als Hash gespeichert - Einweg-Verschlüsselungen, die sich nicht einfach umkehren lassen. Um sie zu knacken, muss ein Angreifer herausfinden, welche Eingabe einen gegebenen Hash erzeugt. Das für Milliarden von Rateversuchen live zu berechnen ist langsam, deshalb berechnen Rainbow Tables lange Ketten aus Hash- und Reduktionsschritten vor und speichern nur die Endpunkte, wodurch die Tabelle klein genug für den praktischen Einsatz bleibt. Bei einem gestohlenen Hash baut der Angreifer die relevante Kette wieder auf, um das ursprüngliche Passwort zu ermitteln. Der Haken: Das funktioniert nur gegen Hashes, die nicht einzeln gesalzen wurden.
Wie schützt man sich gegen Rainbow Tables?
Mit einem Salt. Ein Salt ist ein eindeutiger, zufälliger Wert, der jedem Passwort vor dem Hashen hinzugefügt wird, sodass zwei Nutzer mit demselben Passwort völlig unterschiedliche Hashes erhalten. Weil eine Rainbow Table für ungesalzene Eingaben vorberechnet ist, macht ein Salt pro Nutzer sie nutzlos - ein Angreifer bräuchte eine eigene Tabelle für jeden möglichen Salt, was nicht machbar ist. Moderne Passwortspeicherung kombiniert Salts pro Nutzer mit absichtlich langsamen Hash-Funktionen wie bcrypt, scrypt oder Argon2, die zusammen Rainbow Tables zu einer weitgehend historischen Bedrohung machen und nicht zu einer aktuellen.
Rainbow Table vs. Brute Force vs. Dictionary Attack - was ist der Unterschied?
Alle drei versuchen, Passwörter aus Hashes wiederherzustellen, aber auf unterschiedliche Weise. Eine Brute-Force-Attacke berechnet den Hash jeder möglichen Kombination live, bis eine passt - gründlich, aber langsam. Eine Dictionary Attack probiert eine Liste wahrscheinlicher Passwörter (gängige Wörter und geleakte Passwörter) statt jeder Kombination. Eine Rainbow Table berechnet die Hash-Arbeit im Voraus und schlägt die Antworten nach, tauscht also Speicher gegen Geschwindigkeit. Salting schlägt gezielt Rainbow Tables, weil es die Annahme bricht, dass dasselbe Passwort immer denselben Hash erzeugt.
Sollte ich mir wegen Rainbow Tables noch Sorgen machen?
Für die eigenen Konten indirekt. Du kannst nicht steuern, wie eine Website ihre Hashes speichert, und gut geführte Seiten salzen bereits und nutzen langsame Hashes, was Rainbow Tables neutralisiert. Was du steuern kannst, ist ein eindeutiges, langes Passwort auf jeder Seite, sodass selbst dann, wenn eine Seite Hashes schlecht speichert und geknackt wird, das offengelegte Passwort nichts anderes aufschließt. Ein Passwort-Manager macht das praktikabel.
