Kann man einen Hash zurückrechnen?
Eine der häufigsten Fragen zu Hashfunktionen lautet:
Kann man einen Hash zurückrechnen?
Die kurze Antwort lautet:
Nicht auf die gleiche Weise, wie man verschlüsselte Daten entschlüsseln kann.
Aber die häufig gehörte Aussage:
„Hashes können nicht zurückgerechnet werden.“
ist als absolute Aussage zu ungenau.
Denn ein Angreifer muss einen Hash häufig überhaupt nicht mathematisch umkehren.
Er kann mögliche Eingaben ausprobieren.
Eine Hashfunktion besitzt keine Entschlüsselungsfunktion
Bei Verschlüsselung gibt es eine vorgesehene Rückrichtung:
Klartext
↓
Verschlüsselung + Schlüssel
↓
Ciphertext
↓
Entschlüsselung + Schlüssel
↓
Klartext
Bei einer Hashfunktion sieht das anders aus:
Eingabe
↓
Hashfunktion
↓
Hashwert
Es gibt keinen entsprechenden geheimen Schlüssel und keinen vorgesehenen Entschlüsselungsalgorithmus:
Hashwert
↓
Entschlüsselung?
↓
ursprüngliche Eingabe
Deshalb ist Hashing keine Verschlüsselung.
Was diese Verfahren grundsätzlich unterscheidet, erkläre ich im Artikel Was ist eine Hashfunktion?.
Warum kann der ursprüngliche Wert nicht eindeutig im Hash stecken?
SHA-256 erzeugt immer 256 Bit Ausgabe.
Dabei spielt es keine Rolle, ob die Eingabe wenige Zeichen oder eine sehr große Datei enthält.
Damit gibt es nur:
2²⁵⁶
mögliche SHA-256-Hashwerte.
Der mögliche Eingaberaum ist dagegen größer.
Deshalb müssen unterschiedliche Eingaben existieren, die denselben Hashwert erzeugen.
Aus einem Hashwert kann deshalb nicht allgemein eindeutig bestimmt werden, welche von möglicherweise mehreren passenden Eingaben ursprünglich verwendet wurde.
Das ist eng mit dem Thema Hash Collisions verbunden.
Was bedeutet Preimage Resistance?
Die kryptografisch präzisere Frage lautet deshalb nicht:
Kann ich den Hash zurückrechnen?
Sondern:
Kann ich zu einem vorgegebenen Hashwert eine passende Eingabe finden?
Genau diese Sicherheitseigenschaft nennt man Preimage Resistance.
Gegeben ist:
H
Gesucht wird:
x
mit:
Hash(x) = H
Für SHA-256 führt NIST eine Preimage-Resistance-Stärke von 256 Bit.
Für eine generische Suche bedeutet das eine Größenordnung von:
2²⁵⁶
Operationen.
Was dahinter steckt, erkläre ich ausführlich im Artikel Was ist Preimage Resistance?. Wie sich solche Sicherheitsstärken einordnen lassen, zeige ich im Artikel Wie sicher sind 128, 256 und 512 Bit?.
Aber warum werden dann Passwörter aus Hashes gefunden?
Weil ein Angreifer den Hash nicht rückwärts berechnen muss.
Angenommen, ein Angreifer besitzt einen Hash und vermutet, dass die Eingabe ein menschliches Passwort war.
Dann kann er Kandidaten ausprobieren:
"password"
↓
Hash
↓
kein Treffer
"123456"
↓
Hash
↓
kein Treffer
"sommer2026"
↓
Hash
↓
Treffer
Wenn der erzeugte Hash dem gesuchten Hash entspricht, hat der Angreifer eine passende Eingabe gefunden.
Er hat die Hashfunktion dabei zu keinem Zeitpunkt umgekehrt.
Er hat sie immer in der normalen Richtung berechnet.
Brute Force
Bei einem Brute-Force-Angriff werden mögliche Eingaben systematisch ausprobiert.
Wenn der mögliche Eingaberaum klein genug ist, kann das sehr effektiv sein.
Nehmen wir eine vierstellige PIN:
0000
0001
0002
...
9999
Es gibt nur:
10.000
Möglichkeiten.
Selbst wenn jede PIN mit SHA-256 gehasht wird, muss ein Angreifer nicht 2²⁵⁶ Möglichkeiten ausprobieren.
Er muss lediglich den tatsächlichen Eingaberaum durchsuchen.
Das ist ein entscheidender Unterschied.
Dictionary Attacks
Bei Passwörtern ist es oft noch effizienter, nicht alle theoretisch möglichen Zeichenkombinationen zu testen.
Stattdessen können wahrscheinliche Kandidaten ausprobiert werden:
password
123456
qwertz
letmein
...
sowie Varianten davon.
Das funktioniert, weil von Menschen gewählte Passwörter nicht gleichmäßig zufällig über einen riesigen Eingaberaum verteilt sind.
Die Sicherheit eines Hashwerts hängt deshalb in solchen Szenarien nicht nur von der kryptografischen Hashfunktion ab.
Was ist mit Rainbow Tables?
Vorberechnete Tabellen können Hashwerte bekannten Eingaben zuordnen.
Das Prinzip lautet vereinfacht:
bekannte Eingabe
↓
Hash berechnen
↓
Ergebnis vorberechnen und später wiederverwenden
Ein Angreifer muss dann bestimmte Berechnungen nicht für jedes Ziel erneut durchführen.
Individuelle zufällige Salts erschweren solche vorab berechneten Angriffe erheblich, weil dieselbe Passworteingabe für unterschiedliche Salts unterschiedliche gespeicherte Ergebnisse erzeugt und vorberechnete Arbeit nicht einfach über viele Accounts wiederverwendet werden kann.
Das ist einer der Gründe, warum moderne Passwortspeicherung Salts verwendet.
NIST verlangt in SP 800-63B für zentral gespeicherte Passwörter ein geeignetes Password-Hashing-Schema mit Salt und Kostenfaktor.
Warum reicht SHA-256 für Passwörter trotzdem nicht?
SHA-256 wurde als allgemeine kryptografische Hashfunktion entwickelt und ist sehr schnell berechenbar.
Bei Passwortangriffen ist Geschwindigkeit für den Angreifer ein Vorteil.
Geeignete Password-Hashing-Verfahren verwenden deshalb unter anderem einen Kostenfaktor, um einzelne Rateversuche absichtlich teurer zu machen.
NIST fordert für Passwortverifier ein geeignetes Password-Hashing-Schema mit Salt und Kostenfaktor; der Kostenfaktor soll so hoch gewählt werden, wie es praktisch vertretbar ist.
Das Thema behandle ich ausführlich im späteren Artikel „Warum ist SHA-256 nicht für Passwörter geeignet?“.
Probier es selbst aus
Dieses Problem lässt sich hervorragend demonstrieren.
Die folgende Hash Guessing Demo erzeugt den SHA-256-Hash einer zufälligen PIN – oder einer PIN, die du selbst wählst.
Anschließend probiert das Tool der Reihe nach:
0000
0001
0002
...
hasht jeden Kandidaten und vergleicht das Ergebnis mit dem Zielhash, bis der passende Kandidat gefunden wurde.
Hash Guessing Demo
Starte das Experiment: Aus einer PIN wird ein SHA-256-Hashwert erzeugt – anschließend wird die PIN allein durch Ausprobieren wiedergefunden.
Der SHA-256-Hash wird nicht entschlüsselt. Das Tool probiert mögliche Eingaben aus, hasht sie und vergleicht das Ergebnis mit dem Zielhash.
Merke: Ein kleiner Eingaberaum lässt sich vollständig durchprobieren – egal, wie stark die Hashfunktion ist. Preimage Resistance schützt nur, wenn die Eingabe schwer zu erraten ist.
Du findest dieses Tool auch im Tools-Bereich.
Damit wird sofort sichtbar:
Der Hash wurde nicht entschlüsselt.
Stattdessen wurde der kleine Eingaberaum durchsucht.
Das ist vermutlich die anschaulichste Antwort auf die Frage dieses Artikels.
Kann man also einen Hash zurückrechnen?
Wenn mit „zurückrechnen“ gemeint ist:
Gibt es eine allgemeine Entschlüsselungsfunktion, die aus einem Hashwert die ursprüngliche Eingabe wiederherstellt?
Dann lautet die Antwort:
Nein.
Wenn damit aber gemeint ist:
Kann ich eine Eingabe finden, die einen bekannten Hashwert erzeugt?
dann lautet die Antwort:
Unter bestimmten Umständen ja.
Entscheidend sind unter anderem:
- Größe und Vorhersagbarkeit des Eingaberaums,
- verwendeter Hashalgorithmus,
- bekannte kryptanalytische Schwächen,
- und bei Passwörtern die verwendete Password-Hashing-Konstruktion.
Deshalb ist die Aussage:
„Hashes kann man nicht zurückrechnen.“
zwar als erste Intuition brauchbar, aber kryptografisch nicht präzise genug.
Das Wichtigste in Kürze
- Hashing besitzt keinen vorgesehenen Entschlüsselungsschritt.
- Ein Hashwert enthält nicht eindeutig die ursprüngliche Eingabe.
- Kryptografisch entscheidend ist die Preimage Resistance.
- SHA-256 besitzt laut NIST 256 Bit Preimage Resistance.
- Ein Angreifer muss einen Hash nicht umkehren, um eine passende Eingabe zu finden.
- Kleine Eingaberäume können vollständig ausprobiert werden.
- Bei Passwörtern können wahrscheinliche Kandidaten gezielt getestet werden.
- Salts erschweren die Wiederverwendung vorberechneter Angriffe.
- Geeignetes Password Hashing verteuert einzelne Rateversuche.
- „Nicht entschlüsselbar“ bedeutet deshalb nicht automatisch „die Eingabe kann niemals gefunden werden“.
Wie geht es weiter?
Damit ist der Bereich „Sicherheit verstehen“ abgeschlossen.
Die vier Artikel verbinden die theoretischen Sicherheitseigenschaften aus den Grundlagen mit ihrer praktischen Bedeutung:
Birthday Paradox
↓
Birthday Attack
↓
Security Strength
↓
Hash zurückrechnen?
Von hier aus können einzelne Hashalgorithmen, Passwort-Hashing und konkrete Angriffe deutlich tiefer behandelt werden.
Quellen und weiterführende Standards
Die folgenden Primär- und Normquellen bilden die Grundlage für die technischen Aussagen dieses Artikels:
-
National Institute of Standards and Technology (NIST), Hash Functions Preimage- und Collision-Resistance-Stärken der zugelassenen Hashfunktionen.
-
National Institute of Standards and Technology (NIST), CSRC Glossary – Security Strength Definition kryptografischer Sicherheitsstärke.
-
National Institute of Standards and Technology (NIST), SP 800-63B – Authentication and Lifecycle Management Anforderungen an Passwort-Hashing, Salt und Kostenfaktor.