Warum SHA-256 sicherer ist als MD5

Hash-Algorithmen sind das stille Arbeitspferd hinter Datei-Integrität, Passwort-Speicherung, digitalen Signaturen und Blockchains. Doch nicht alle Hash-Verfahren sind gleich sicher: MD5, jahrzehntelang allgegenwärtig, gilt heute als gebrochen. Dieser Artikel erklärt warum — und wann SHA-256 (oder noch stärker SHA-512) die richtige Wahl ist.

Was ist eine Hash-Funktion?

Eine kryptographische Hash-Funktion bildet eine beliebig lange Eingabe (Datei, Text, Datenstrom) auf eine Ausgabe fester Länge ab — z. B. 128 Bit bei MD5 oder 256 Bit bei SHA-256. Das Ergebnis nennt man Hash oder Digest. Die Funktion ist deterministisch (gleiche Eingabe ergibt immer denselben Hash), aber praktisch nicht umkehrbar.

Drei Eigenschaften sind dabei kritisch: Preimage-Resistenz (zu einem Hash darf man die Eingabe nicht rekonstruieren können), Second-Preimage-Resistenz (zu einer Eingabe darf man keine zweite mit demselben Hash finden) und Kollisionsresistenz (es darf praktisch unmöglich sein, irgendein Paar von Eingaben mit demselben Hash zu finden). Sobald eine dieser Eigenschaften fällt, gilt der Algorithmus für Sicherheitsanwendungen als kompromittiert.

Eine kurze Geschichte: MD5, SHA-1, SHA-2

MD5 wurde 1991 von Ron Rivest entworfen, mit 128 Bit Ausgabelänge. Es war damals ein Fortschritt gegenüber MD4 und über Jahre Standard für Datei-Checksummen und Passwort-Hashes. SHA-1, 1995 von der NSA standardisiert, lieferte 160 Bit und schien lange sicher zu sein. Beide gehören zu derselben Familie von Merkle-Damgård-Konstruktionen mit Boolean-Operationen pro Runde.

Die SHA-2-Familie wurde 2001 vom NIST veröffentlicht: SHA-224, SHA-256, SHA-384 und SHA-512. Sie sind strukturell verwandt mit SHA-1, nutzen aber deutlich mehr Runden, größere interne Zustände und längere Ausgaben. SHA-3 (Keccak, 2015) basiert auf einem völlig anderen Schwamm-Konzept und ist als Reserve gedacht, falls SHA-2 jemals strukturell angreifbar wird.

Wie MD5 und SHA-1 gefallen sind

Bereits 2004 zeigten Wang, Feng, Lai und Yu eine erste praktische Kollision für MD5. Zwei verschiedene Eingaben ergaben denselben Hash — in Minuten auf Standard-Hardware. 2008 demonstrierte ein Forscherteam um Sotirov und Stevens, dass man damit gefälschte SSL-Zertifikate ausstellen kann. Seitdem ist MD5 für jede Sicherheitsanwendung tabu.

SHA-1 folgte 2017 mit dem berühmten SHAttered-Angriff von Google und CWI Amsterdam: zwei PDF-Dateien mit identischem SHA-1-Hash, aber unterschiedlichem Inhalt. Der Angriff kostete etwa 110 GPU-Jahre — teuer, aber finanzierbar für Staaten und große Organisationen. Browser, Git-Hoster und CAs phasen SHA-1 seitdem aktiv aus. SHA-256 hat bislang keinen vergleichbaren Angriff erfahren; klassische Brute-Force-Kollisionen wären im Bereich von 2^128 Operationen — astronomisch.

Was SHA-256 besser macht

SHA-256 liefert 256 Bit Output. Damit ist die theoretische Kollisionsresistenz nach dem Geburtstagsparadox bei 2^128 — eine Zahl, die weit jenseits aller heute denkbaren Rechenleistung liegt. Zusätzlich hat SHA-2 doppelt so viele Runden wie SHA-1 (64 statt 80, aber mit komplexerer Mischung) und einen größeren internen Zustand. Selbst eine drastische Reduktion der Sicherheit durch zukünftige Krypto-Analyse würde noch genug Reserve lassen.

In der Praxis ist SHA-256 auf modernen CPUs sehr schnell — Intel und AMD bieten seit Jahren spezielle Befehlssatz-Erweiterungen (SHA-NI). Auf ARM existieren entsprechende Crypto-Extensions. Für Massendurchsatz (z. B. Datei-Hashing in Backup-Tools) ist SHA-256 oft schon nicht mehr der Flaschenhals. Wer noch mehr Reserve braucht oder native 64-Bit-Architekturen optimal ausreizen will, greift zu SHA-512.

Wann welcher Algorithmus?

Eine pragmatische Faustregel:

• MD5: nur noch für nicht-sicherheitskritische Prüfsummen (z. B. schnelle Deduplizierung, Cache-Keys, Verifikation gegen versehentliche Bit-Fehler). Nie für Signaturen, Zertifikate oder Passwort-Hashes.
• SHA-1: vermeiden. In Bestandssystemen toleriert (z. B. Git-Commit-IDs), aber in jeder neuen Anwendung durch SHA-256 ersetzen.
• SHA-256: heutiger De-facto-Standard. Für TLS-Zertifikate, JWT-Signaturen (HS256/RS256), digitale Signaturen, Datei-Integrität, Blockchain (Bitcoin) und alles, wo Kollisionsresistenz zählt.
• SHA-512: identische Sicherheitsphilosophie, aber doppelte Hash-Länge. Empfohlen, wenn 256 Bit als Margin nicht reichen oder wenn 64-Bit-CPUs sie performanter berechnen als SHA-256.

SHAttered: wie Google 2017 SHA-1 endgültig erledigte

Im Februar 2017 veröffentlichten Forscher bei Google und CWI Amsterdam die erste praktische SHA-1-Kollision: zwei verschiedene PDF-Dateien, die denselben SHA-1-Hash produzierten. Das Projekt hieß »SHAttered«. Die beiden PDFs waren visuell unterschiedlich (eine zeigte ein rotes Rechteck, die andere ein blaues), hatten aber Byte-Sequenzen, die durch die SHA-1-Funktion zum gleichen Output führten. Das war keine theoretische Übung mehr — das war ein praktischer Angriff mit echten Konsequenzen.

Der Rechenaufwand war enorm: rund 6500 CPU-Jahre für die erste Phase und 110 GPU-Jahre für die zweite. In Cloud-Mietzeit von 2017 entsprach das damals etwa 110.000 USD — viel für einen Nachmittag, aber durchaus erschwinglich für staatliche Akteure oder gut finanzierte Kriminelle. Innerhalb von Tagen nach der Veröffentlichung deaktivierten Browser-Hersteller, Git-Tools und Versionskontrollsysteme die Verwendung von SHA-1 für sicherheitskritische Anwendungen.

Die Lehre: »noch keine praktische Kollision bekannt« heißt nicht »sicher«. SHA-1 galt seit 2005 als theoretisch angegriffen, aber praktische Demonstrationen fehlten. Zwölf Jahre lang blieben die meisten Systeme bei SHA-1 — »funktioniert doch«. Dann kam SHAttered, und plötzlich war jeder im Migrations-Stress. Wer 2026 noch SHA-1 in Produktion hat (ja, das gibt es), läuft genau diesem Muster nach. Bei SHA-2 (also SHA-256 und SHA-512) gibt es bisher nicht einmal theoretische Angriffe, die einer kryptografisch relevanten Schwelle nahe kommen — aber das ist kein Argument dafür, ewig dabei zu bleiben.

Warum SHA-256 für Passwörter falsch ist (auch wenn alle es so machen)

Eine der häufigsten Verwechslungen in Code-Reviews: »wir hashen Passwörter mit SHA-256, das ist doch sicher«. Nein, ist es nicht — und zwar nicht, weil SHA-256 unsicher wäre, sondern weil es zu schnell ist. Eine moderne GPU rechnet rund 10 Milliarden SHA-256-Hashes pro Sekunde durch. Das heißt: ein 8-Zeichen-Passwort aus Buchstaben und Zahlen (etwa 218 Billionen Kombinationen) ist in unter sechs Stunden komplett durchprobiert — ein Brute-Force-Angriff zum Mietpreis von wenigen Hundert Dollar.

Was du stattdessen brauchst, sind langsame, salt-fähige Algorithmen, die explizit für Passwort-Hashing gebaut sind: Argon2id (Empfehlung 2026 für neue Systeme), bcrypt (immer noch akzeptabel mit cost ≥12), oder scrypt. Diese Funktionen sind absichtlich rechen- und speicherintensiv. Argon2id mit Standard-Parametern braucht etwa 100 ms pro Hash auf einer normalen Server-CPU — und damit lassen sich selbst mit einer GPU-Farm nur etwa 100 Versuche pro Sekunde durchführen statt 10 Milliarden. Das ist der Faktor, der ein 8-Zeichen-Passwort von »6 Stunden Brute-Force« auf »6 Millionen Jahre« hebt.

Wer also einen Login-Form baut: SHA-256 ist nicht das Werkzeug. Wer eine bestehende Datenbank mit SHA-256-gehashten Passwörtern hat: bei jedem erfolgreichen Login das Passwort mit Argon2id rehashen und den alten Hash ersetzen. Das ist eine schmerzfreie Migration über ein paar Monate. Was nicht funktioniert: »wir hängen einfach 1000 SHA-256-Runden aneinander, dann ist es langsam genug«. Das ist PBKDF2, und es ist 2026 nur noch als Übergangslösung akzeptabel — Argon2id ist gegen GPU- und ASIC-Angriffe deutlich resistenter.

Code-Audit: wo MD5 und SHA-1 sich noch verstecken

Wer heute eine Codebase übernimmt, findet typischerweise an Stellen MD5 oder SHA-1, an denen es nicht weh tut — und an Stellen, an denen es weh tut. Beim Audit folgende Suchmuster in einer 30-Minuten-Sichtung durchgehen:

• Passwort-Felder. grep -rn 'md5(\$password' ., grep -rn 'sha1(\$pwd' .. Jeder Treffer ist eine kritische Sicherheitslücke, die vor dem nächsten Release auf Argon2id migriert werden muss.
• Signaturen und HMAC. Suche nach hash_hmac('md5', hmac.MD5, HMACSHA1. Hier ist MD5 fast immer falsch — HMAC-MD5 ist zwar noch nicht praktisch angegriffen, aber kein moderner Standard. Migration auf HMAC-SHA-256.
• Datei-Integritäts-Checks. md5sum und sha1sum in Build-Pipelines, Backup-Skripten, Deployment-Tools. Wenn die Hashes nur Übertragungsfehler erkennen sollen (kein böswilliger Angreifer involviert), ist MD5 ok. Wenn ein Angreifer die Datei manipulieren könnte (Software-Update, Lizenz-Datei), bitte sofort auf SHA-256 wechseln.
• Cookie-Tokens und Session-IDs. md5(uniqid()) ist ein klassischer Anti-Pattern, das in PHP-Codebases der späten 2000er allgegenwärtig war. Das Ergebnis ist nicht zufällig genug. Lösung: random_bytes(32) in PHP, crypto.randomBytes(32) in Node.js — kein Hashing nötig.
• Datenbank-Indizes auf Hash-Spalten. Eine MD5-Spalte als VARCHAR(32) als Primärschlüssel oder Index — funktioniert technisch, ist aber selten optimal. Bei Migration zu SHA-256 die Spaltenbreite auf VARCHAR(64) erhöhen, nicht die alten Daten löschen, sondern parallel beide Hashes pflegen, bis ein vollständiger Schwenk möglich ist.

Wer einen konkreten Hash gegen unbekanntes Algorithmus prüfen will: unser Hash-Generator berechnet MD5, SHA-1, SHA-256 und SHA-512 nebeneinander für denselben Input. Mit zwei Tabs lässt sich das Hex-Format und die Länge eines unbekannten Hashes vergleichen, um den Algorithmus zu erkennen (MD5 = 32 Hex-Zeichen, SHA-1 = 40, SHA-256 = 64, SHA-512 = 128).

Was Quantencomputer mit SHA-256 machen werden

Eine Frage, die in jedem zweiten Krypto-Vortrag aufkommt: »macht Quantum SHA-256 kaputt?«. Kurze Antwort: nein, aber er halbiert die effektive Sicherheit. Grover's-Algorithmus auf einem ausreichend großen Quantencomputer kann eine Hash-Funktion in 2^(n/2) Versuchen brechen statt 2^n. Für SHA-256 heißt das: statt 256 Bit Sicherheit gegen Pre-Image-Angriffe bleiben 128 Bit. 128 Bit Sicherheit gelten weiterhin als ausreichend für die nächsten Jahrzehnte.

Praktisch: SHA-512 ist gegenüber Quantum-Angriffen besonders entspannt — auch dort halbiert sich die Bit-Sicherheit, aber 256 Bit verbleibend ist enorm viel. Wer absolute Langzeit-Sicherheit für sehr langfristige Archive (Notarakten, medizinische Daten mit Aufbewahrungsfristen über 50 Jahre) plant, kann ohne Performance-Probleme auf SHA-512 wechseln. Für alltägliche Web-Anwendungen ist SHA-256 weiterhin die ausgewogene Wahl.

Häufige Fragen

Ist SHA-256 quantensicher?

Symmetrische Primitive wie Hash-Funktionen sind gegen Quantencomputer deutlich robuster als asymmetrische Verfahren (RSA, ECDSA). Grover's Algorithmus halbiert effektiv die Bit-Sicherheit — SHA-256 hätte gegen einen idealen Quantencomputer noch rund 128 Bit Sicherheit, was praktisch ausreicht. Für höhere Margin nutzt man SHA-512 oder SHA-3.

Brauche ich für Passwörter SHA-256 oder etwas anderes?

Weder MD5 noch SHA-256 sind allein geeignet für Passwort-Speicherung. Sie sind zu schnell — Angreifer können Milliarden Hashes pro Sekunde durchprobieren. Für Passwörter verwendet man absichtlich langsame Verfahren wie bcrypt, scrypt oder Argon2, die mit Salt und konfigurierbarem Aufwand arbeiten.

Ist SHA-3 besser als SHA-256?

Nicht zwingend. SHA-3 ist strukturell anders konstruiert und damit eine sinnvolle Diversifizierung — falls SHA-2 jemals theoretisch angegriffen wird, bleibt SHA-3 als Backup. In der Praxis ist SHA-256 derzeit aber breiter unterstützt, schneller in vielen Hardware-Implementierungen und für die meisten Anwendungen die richtige Wahl.

Sind SHA-256 und SHA-2 dasselbe?

SHA-2 ist die Familie, SHA-256 ist ein konkreter Algorithmus dieser Familie. SHA-2 umfasst SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 und SHA-512/256. Die Zahlen geben die Ausgabelänge in Bit an. SHA-256 ist mit Abstand das verbreitetste Mitglied, gefolgt von SHA-512 bei besonders sicherheitskritischen Anwendungen.

Was ist ein Salt und warum sollte ich einen verwenden?

Ein Salt ist eine zufällige Zeichenfolge (typisch 16–32 Bytes), die vor dem Hashen an das Passwort angehängt wird und mit dem Hash zusammen gespeichert wird. Ohne Salt hashen alle Nutzer mit demselben Passwort zum gleichen Hash — ein Angreifer mit einer Rainbow Table (vorberechnete Hash-zu-Passwort-Liste) kann sofort lookups machen. Mit einem einzigartigen Salt pro Nutzer wird jede Rainbow Table sinnlos. Argon2id und bcrypt erzeugen den Salt automatisch — manuelle Lösungen wie »SHA-256(password + 'mein_geheimes_salt')« sind anti-pattern.

Ist Bitcoin sicher, wenn SHA-256 mal gebrochen wird?

Bitcoin nutzt SHA-256 (eigentlich doppeltes SHA-256) für Mining und Block-Hashes. Wenn SHA-256 jemals kollisions-anfällig würde, würden Bitcoin-Miner trotzdem nicht sofort »zurückrechnen« können — die Schwierigkeit liegt darin, einen Hash mit einer bestimmten Vorgabe (leading zeros) zu finden, nicht in der Umkehrung. Trotzdem ist die Frage berechtigt: ein theoretisch erfolgreicher Angriff würde wahrscheinlich einen Soft Fork erzwingen, der zu SHA-3 oder einem post-quantum-sicheren Hash migriert. Der Aufwand wäre erheblich, aber im Bitcoin-Ökosystem operativ machbar.