MD5 vs SHA-256 vs bcrypt für Passwörter

Wenn Entwickler MD5 vs. SHA-256 vs. bcrypt für die Passwortspeicherung vergleichen, lautet der übliche Rat: „MD5 ist unsicher, verwende SHA-256.“ Dieser Rat ist falsch und der häufigste Sicherheitsfehler in diesem Bereich. MD5 ist zwar unsicher, aber rohes SHA-256 ist aus einem ganz anderen Grund ebenfalls eine schlechte Wahl für Passwörter: Es ist zu schnell. Die richtige Antwort ist ein bewusst langsamer Algorithmus, der für Passwörter entwickelt wurde, also bcrypt oder Argon2.

Dieser Leitfaden verdeutlicht den Unterschied, den die restlichen Suchergebnisse übersehen. Wir erklären, warum schnelle Hashverfahren gegen GPUs verlieren, was Salting und Arbeitsfaktoren tatsächlich bewirken und welchen Algorithmus Sie 2026 genau verwenden sollten. Sie können jeden Hash-Typ direkt im Browser testen, während wir fortfahren.

MD5 vs SHA-256 vs bcrypt auf einen Blick#

Der grundlegende Fehler besteht darin, alle Hashing-Verfahren als eine einzige Aufgabe zu betrachten. Es handelt sich um zwei verschiedene Aufgaben mit gegensätzlichen Anforderungen. Dateiintegrität benötigt einen schnellen Hash. Passwortspeicherung benötigt einen langsamen. Wer diese verwechselt, riskiert, dass gehackte Datenbanken innerhalb von Stunden geknackt werden.

Algorithmus	Typ	Geschwindigkeit	Salt integriert	Sicher für Passwörter?	Geeignet für
MD5	Schneller Hash	Extrem schnell	Nein	Nein (gebrochen)	Nichts sicherheitsrelevantes
SHA-1	Schneller Hash	Sehr schnell	Nein	Nein (gebrochen)	Nur Legacy-Kompatibilität
SHA-256	Schneller Hash	Sehr schnell	Nein	Nein (zu schnell)	Datei-Prüfsummen, Integrität, Signaturen
bcrypt	Langsamer Hash (KDF)	Einstellbar, langsam	Ja	Ja	Passwortspeicherung
Argon2id	Langsamer Hash (KDF)	Einstellbar, langsam	Ja	Ja (aktuell beste)	Passwortspeicherung
PBKDF2	Langsamer Hash (KDF)	Einstellbar, langsam	Ja (Sie fügen hinzu)	Ja (akzeptabel)	FIPS-beschränkte Umgebungen

Wichtigste Erkenntnis: SHA-256 ist hervorragend für die Aufgabe geeignet, für die es entwickelt wurde (Nachweis, dass eine Datei nicht verändert wurde), und unsicher für eine Aufgabe, für die es nie gedacht war (Widerstand gegen Passwort-Cracking-Hardware). "Sicherer Hash" bedeutet nicht "sicher für Passwörter."

Das Wort "sicher" sorgt für die meiste Verwirrung. SHA-256 gehört zur SHA-2-Familie und ist in dem Sinne kryptografisch sicher, dass man keine Kollisionen finden oder es mathematisch umkehren kann. Diese Eigenschaft ist das, was Dateiintegrität benötigt. Passwortspeicherung erfordert etwas ganz anderes: Widerstandsfähigkeit gegen Brute-Force-Angriffe in großem Maßstab.

Warum MD5 gebrochen ist (und SHA-1 gleich mit)#

MD5 versagt auf zwei Ebenen. Erstens ist es kollisionsgebrochen: Forscher können gezielt zwei verschiedene Eingaben mit demselben MD5-Hash erzeugen, was seinen Wert für Signaturen und Zertifikate zerstört. SHA-1 erging es ab 2017 mit der Veröffentlichung praktischer Kollisionen genauso.

Zweitens, und für Passwörter relevanter, ist MD5 extrem schnell. Eine moderne GPU kann Milliarden von MD5-Hashes pro Sekunde berechnen. Diese Geschwindigkeit ist ein Vorteil für eine Prüfsumme, aber eine Katastrophe für einen Passwort-Hash.

Was das in der Praxis bedeutet: Wenn eine Website Passwörter als einfaches MD5 speichert und die Datenbank durchsickert, kann ein Angreifer mit einer einzigen handelsüblichen Grafikkarte ein riesiges Wörterbuch gängiger Passwörter gegen jeden Account fast sofort testen. Mit einer vorbereiteten Rainbow Table (einer riesigen Tabelle von Hash zu Klartext) lassen sich ungesalzene MD5-Hashes gängiger Passwörter in Millisekunden umkehren.

• MD5: kollisionsgebrochen, viel zu schnell, kein Salt. Niemals für Sicherheit verwenden.
• SHA-1: seit 2017 kollisionsgebrochen, zu schnell. Überall veraltet.
• Die Lehre: „Gebrochen“ bezieht sich hier teils auf Kollisionen, teils auf die reine Geschwindigkeit.

Sie können MD5 oder SHA-256 weiterhin sicher für nicht-angreifbare Korruptionsprüfungen verwenden (wurde diese Datei intakt heruntergeladen?). Das ist Integrität, nicht Authentizität und keine Passwortspeicherung. Für alles, was ein Angreifer fälschen oder knacken möchte, ist MD5 tabu.

Die SHA-256-Falle: Sicher, aber zu schnell für Passwörter#

Das ist der Teil, den die meisten Vergleiche falsch verstehen. SHA-256 ist nicht kollisionsgebrochen. Es ist ein wirklich starkes kryptografisches Hashverfahren. Warum ist es dann das falsche Werkzeug für Passwörter?

Weil es absichtlich schnell ist. SHA-256 wurde entwickelt, damit Systeme große Datenmengen schnell hashen können, um die Integrität zu überprüfen. Ein High-End-GPU-Setup kann Milliarden von SHA-256-Hashes pro Sekunde berechnen. Wenn der Algorithmus schnell ist, ist auch die Brute-Force-Maschine des Angreifers schnell.

Passwortknacken ist ein Offline-Ratespiel. Sobald ein Angreifer Ihre Hash-Datenbank hat, gibt es keine Ratenbegrenzung. Er meldet sich nicht einmal pro Versuch auf Ihrer Website an. Er führt Ihre Hashes mit Wortlisten und Mutationsregeln auf spezieller Hardware aus. Je schneller Ihre Hash-Funktion, desto mehr Versuche pro Sekunde erhält er und desto günstiger wird jedes geknackte Passwort.

Salzen hilft, behebt aber nicht die Geschwindigkeit#

Ein häufiger Einwand ist: "Salzen Sie einfach Ihr SHA-256." Ein Salt ist ein eindeutiger, zufälliger Wert, der neben jedem Hash gespeichert und vor dem Hashen in die Eingabe gemischt wird. Salzen ist unerlässlich und bewirkt zwei Dinge:

• Es macht Regenbogentabellen unwirksam, da eine vorberechnete Tabelle gegen benutzerspezifische Zufallssalze nutzlos ist.
• Es stellt sicher, dass zwei Benutzer mit demselben Passwort unterschiedliche Hashes erhalten, sodass das Knacken eines Passworts nicht das andere kompromittiert.

Aber Salzen hat keinen Einfluss auf die Geschwindigkeit. Ein Angreifer knackt weiterhin jeden gesalzenen SHA-256-Hash einzeln mit Milliarden von Versuchen pro Sekunde. Salt entfernt die Abkürzung der Massenvorberechnung, macht die zugrunde liegende Funktion jedoch nicht langsam. Deshalb ist "gesalzenes SHA-256" besser als nacktes SHA-256, aber immer noch nicht gut genug für Passwörter.

Das Gedankenmodell: Salt schützt vor Vorberechnung. Ein langsamer Algorithmus schützt vor rohem Brute-Force-Durchsatz. Sie brauchen beides, und SHA-256 gibt Ihnen nur eines davon.

Was bcrypt anders macht: Absichtlich langsam#

bcrypt wurde 1999 speziell für die Passwortspeicherung entwickelt und seine zentrale Idee ist das Gegenteil von MD5 und SHA-256: es ist bewusst und einstellbar langsam. bcrypt bündelt drei Dinge, die ein Passwort-Hash benötigt.

• Ein integrierter Salt. bcrypt generiert und speichert automatisch einen Salt pro Hash, sodass Sie nicht vergessen können, einen hinzuzufügen.
• Ein Arbeitsfaktor (die "Kosten"). Dies ist eine Zahl, die Sie festlegen und die steuert, wie viele interne Iterationen bcrypt ausführt. Jede Erhöhung um eins verdoppelt in etwa die Zeit zur Berechnung eines Hashs.
• Ein adaptives Design. Wenn die Hardware schneller wird, erhöhen Sie den Arbeitsfaktor, um das Hashing langsam zu halten, ohne die Algorithmen zu ändern.

Ein bcrypt-Hash-String trägt seine eigenen Parameter. Ein typischer Hash sieht aus wie $2b$12$R9h/cIPz0gi..., wobei $2b$ die bcrypt-Version ist, 12 der Arbeitsfaktor (Kosten) und der Rest der kombinierte Salt und Digest. Dieses selbstbeschreibende Format bedeutet, dass die Verifizierung nur den gespeicherten Hash benötigt, keine separate Salt-Spalte.

Der Sinn des Arbeitsfaktors ist es, jede einzelne Vermutung teuer zu machen. Wenn ein bcrypt-Hash eine Viertelsekunde zur Berechnung benötigt, wird ein Angreifer, der Milliarden von SHA-256-Vermutungen pro Sekunde durchführen könnte, auf eine Handvoll bcrypt-Vermutungen pro Sekunde pro Kern reduziert. Dieselbe Wortliste, die SHA-256 in Minuten knackt, könnte gegen gut konfiguriertes bcrypt Jahre dauern.

Auswahl eines bcrypt-Arbeitsfaktors#

Der Arbeitsfaktor ist ein Kompromiss zwischen Sicherheit und der Anmeldeverzögerung auf Ihrem eigenen Server. Stellen Sie ihn so ein, dass ein einzelner Hash eine spürbare, aber akzeptable Zeit auf Ihrer Hardware benötigt, üblicherweise im Bereich von 0,1 bis 0,5 Sekunden pro Hash.

• Höhere Kosten sind sicherer, verlangsamen aber jede Anmeldung und jede Registrierung.
• Führen Sie Benchmarks auf Ihrer tatsächlichen Produktionshardware durch, nicht auf Ihrem Laptop. Schnellere Server können höhere Kosten verkraften.
• Bewerten Sie jährlich neu. Hardware verbessert sich, daher sind Kosten, die 2020 für Angreifer schmerzhaft waren, heute günstiger.

bcrypt hat auch eine Eigenheit, die man kennen sollte: es kürzt die Eingabe auf 72 Bytes. Wenn Sie sehr lange Passphrasen oder vor-gehashte Passwörter unterstützen (ein Muster, das einige Teams verwenden), testen Sie dieses Verhalten, damit Sie Zeichen jenseits des Limits nicht stillschweigend ignorieren.

Wo Argon2 passt (und PBKDF2)#

bcrypt ist hervorragend und bleibt auch 2026 eine absolut vertretbare Wahl. Die aktuelle Top-Empfehlung aus Sicherheitsleitfäden wie dem OWASP Password Storage Cheat Sheet ist jedoch Argon2id, der Gewinner des Password Hashing Competition 2015.

Argon2id verbessert bcrypt, indem es speicherintensiv ist. bcrypts Arbeitsfaktor kostet CPU-Zeit, verbraucht aber wenig Speicher, sodass Angreifer viele bcrypt-knackende Kerne auf günstiger Hardware unterbringen können. Argon2id ermöglicht die Einstellung von drei Parametern: Zeitkosten (Iterationen), Speicherkosten (wie viel RAM jeder Hash benötigt) und Parallelität. Wenn jeder Rateversuch bedeutend Speicher verbraucht, wird der GPU- und ASIC-Vorteil, der das Knacken billig macht, geschwächt.

Algorithmus	Widerstand gegen GPU-Knacken	Speicherintensiv	Wann wählen
Argon2id	Stark	Ja	Neue Systeme; die aktuelle Standardempfehlung
bcrypt	Stark	Nein	Ausgereift, kampferprobt; für bestehende Systeme geeignet
scrypt	Stark	Ja	Gültige speicherintensive Alternative, wenn Argon2 nicht verfügbar
PBKDF2	Mittel	Nein	FIPS-140-Konformitätsanforderungen; hohe Iterationszahlen verwenden

PBKDF2 verdient eine Erwähnung, da es in regulierten Umgebungen vorkommt. Es ist älter und nicht speicherintensiv, daher widersteht es GPUs weniger gut als bcrypt oder Argon2. Es ist jedoch FIPS-zugelassen, was für Regierungs- und einige Unternehmensumgebungen wichtig ist. Wenn Sie PBKDF2 verwenden müssen, erhöhen Sie die Iterationszahl stark (Hunderttausende bis Millionen, abgestimmt auf Ihr Latenzbudget).

Die Kurzversion des Entscheidungsbaums:

1. Neues Projekt ohne Einschränkungen: Argon2id verwenden.
2. Bestehendes System bereits mit bcrypt und funktionierend: bcrypt ist in Ordnung, behalten Sie es bei, erhöhen Sie die Kosten im Laufe der Zeit.
3. FIPS- oder strenge Compliance-Umgebung: PBKDF2 mit einer sehr hohen Iterationszahl.
4. Niemals: MD5, SHA-1, rohes SHA-256, rohes SHA-512 oder ein ungesalzener schneller Hash.

Testen Sie jeden Hash selbst#

Über Hashes zu lesen ist eine Sache. Sie selbst zu sehen ist eine andere und macht den Geschwindigkeitsunterschied deutlich. Sie können MD5-, SHA-1-, SHA-256- und SHA-512-Digests derselben Eingabe im Browser erzeugen, um zu sehen, wie jeder Algorithmus Text umwandelt.

Fügen Sie eine Beispielzeichenfolge wie correct horse battery staple in den kostenlosen Hash-Generator ein und beobachten Sie, wie sofort jeder Digest erzeugt wird. Dieses sofortige Ergebnis ist genau das Problem mit schnellen Hashes für Passwörter: Wenn Ihr Browser einen SHA-256-Digest ohne wahrnehmbare Verzögerung berechnet, stellen Sie sich eine GPU-Farm vor, die Milliarden davon pro Sekunde gegen eine durchgesickerte Datenbank ausführt.

Einige Dinge, die Sie beim Experimentieren ausprobieren können:

• Hashen Sie dasselbe Wort zweimal. Beachten Sie, dass MD5 und SHA-256 jedes Mal die identische Ausgabe liefern, weshalb sie ein externes Salt benötigen und Regenbogentabellen gegen sie funktionieren.
• Ändern Sie ein Zeichen. Der gesamte Digest ändert sich vollständig (der Lawineneffekt), was gut für Integritätsprüfungen ist.
• Vergleichen Sie die Digest-Längen. SHA-256 ist länger als MD5, aber die Länge allein macht es nicht sicher für Passwörter. Die Geschwindigkeit ist das eigentliche Problem.

Hinweis: Ein browserbasiertes Tool für schnelle Hashes ist der richtige Weg, um zu lernen, was diese Algorithmen produzieren, aber es ist nicht der Ort, um Produktions-Passwort-Hashes zu erzeugen. bcrypt und Argon2 gehören serverseitig in Ihre Authentifizierungsbibliothek, niemals in clientseitiges JavaScript.

Während Sie über die Sicherheit von Anmeldedaten nachdenken, lohnt es sich zu überprüfen, wie widerstandsfähig Ihre eigenen Passwörter sind. Ein starkes Passwort und ein langsamer Hash arbeiten zusammen: Schwache Passwörter fallen bei jedem Hash, und ein großartiger Hash kann ein Passwort, das in jeder Wortliste steht, nicht vollständig retten. Testen Sie einige mit dem Passwort-Stärke-Prüfer, um zu sehen, wie Erratbarkeit und Entropie einfließen, und generieren Sie wirklich zufällige mit dem sicheren Passwort-Generator, damit die Knack-Mathematik auf Ihrer Seite ist.

Häufige Fehler, die Sie vermeiden sollten#

Die Theorie ist einfach, aber dieselben Implementierungsfehler tauchen bei jedem Sicherheitsvorfall immer wieder auf. Achten Sie auf diese.

• SHA-256 zu verwenden, weil es "sicherer als MD5" ist. Das stimmt gegen Kollisionen. Für Passwörter ist es immer noch zu schnell. Das ist die Falle, auf die dieser ganze Artikel hinweist.
• Eine eigene Methode zu entwickeln, wie sha256(sha256(password) + salt). Das Stapeln schneller Hashfunktionen ergibt keinen langsamen Hash. Verwenden Sie eine echte Passwort-KDF.
• Das Salt falsch zu speichern oder ein globales Salt wiederzuverwenden. Salts müssen pro Benutzer eindeutig und zufällig sein. bcrypt und Argon2 erledigen das für Sie, ein weiterer Grund, sie zu verwenden.
• Den Arbeitsfaktor einmal festzulegen und nie zu erhöhen. Ein Kostenfaktor, der Angreifer vor Jahren behindert hat, ist heute billig. Überprüfen Sie ihn regelmäßig.
• Passwörter clientseitig in JavaScript zu hashen. Der Hash muss auf dem Server erfolgen. Ein clientseitiger Hash wird einfach zum neuen Passwort, das ein Angreifer wiederverwenden kann.

Wenn Sie auch Token verarbeiten und nicht nur gespeicherte Passwörter, gilt dieselbe Logik "die richtige Primitive verwenden" für Signaturen und Verifikation. Unser Leitfaden zum Dekodieren vs. Verifizieren eines JWT behandelt einen eng verwandten Fehler: einem Token zu vertrauen, das Sie nur dekodiert, aber nie kryptografisch verifiziert haben.

Das Urteil zu MD5 vs. SHA-256 vs. bcrypt#

Bei der Passwortspeicherung ist die Rangfolge eindeutig. MD5 ist gebrochen und viel zu schnell. SHA-256 ist kryptografisch stark, aber immer noch zu schnell, selbst mit Salt, und unterliegt daher GPU-Brute-Force, sobald Ihre Datenbank durchsickert. bcrypt und Argonid sind absichtlich langsam, salzen automatisch und ermöglichen es Ihnen, die Kosten zu erhöhen, wenn die Hardware besser wird, genau das, was die Passwortspeicherung erfordert.

Wenn Ihnen also jemand die Frage MD5 vs. SHA-256 vs. bcrypt für Passwörter stellt, lautet die Antwort bcrypt oder Argon2id, jedes Mal. Heben Sie SHA-256 für das auf, wofür es wirklich gut ist, wie Dateiintegrität und Prüfsummen, und lassen Sie sich niemals von einem "sicheren Hash"-Label dazu verleiten, einen schnellen Algorithmus dort einzusetzen, wo ein langsamer hingehört. Testen Sie jeden Digest im kostenlosen Hash-Generator, um den Geschwindigkeitsunterschied greifbar zu machen, und behalten Sie dann die langsamen, passwortspezifischen Algorithmen in Ihrer Authentifizierungsschicht, wo sie hingehören.

Häufig gestellte Fragen#

Ist SHA-256 sicher für Passwörter? Nein, obwohl SHA-256 selbst ein starker, ungebrochener kryptografischer Hash ist. Das Problem ist die Geschwindigkeit: SHA-256 ist darauf ausgelegt, schnell zu sein, sodass ein Angreifer mit einer durchgesickerten Datenbank Milliarden von Versuchen pro Sekunde auf einer GPU brute-forcen kann. Salzen hilft gegen Rainbow-Tabellen, verlangsamt den Algorithmus jedoch nicht. Verwenden Sie für Passwörter stattdessen eine bewusst langsame Funktion wie bcrypt oder Argon2id.

Warum ist bcrypt besser als SHA-256 für Passwörter? bcrypt ist absichtlich langsam und anpassbar, während SHA-256 absichtlich schnell ist. bcrypt enthält ein integriertes Salt und einen einstellbaren Arbeitsfaktor, sodass jeder einzelne Passwortversuch für einen Angreifer echte Zeit und Geld kostet. Mit besserer Hardware erhöhen Sie den Arbeitsfaktor, um das Knacken teuer zu halten. SHA-256 bietet Angreifern günstiges, schnelles Raten, was das Gegenteil von dem ist, was die Passwortspeicherung benötigt.

Sollte ich 2026 bcrypt oder Argon2 verwenden? Beide sind solide. Argon2id ist derzeit die Top-Empfehlung, da es speicherintensiv ist, was den Vorteil von GPUs und ASICs zunichtemacht, die das Knacken billig machen. bcrypt bleibt eine vollkommen vertretbare, kampferprobte Wahl, besonders wenn Ihr System es bereits verwendet. Für ein brandneues Projekt ohne Compliance-Einschränkungen verwenden Sie standardmäßig Argon2id; wenn Sie bereits bcrypt verwenden und die Kosten anpassen, gibt es keinen dringenden Grund zur Migration.

Reicht Salzen aus, um SHA-256 für Passwörter sicher zu machen? Nein. Salzen ist notwendig und Sie sollten es immer tun, aber es löst nur ein Problem: Es verhindert vorberechnete Rainbow-Tabellen und stellt sicher, dass identische Passwörter unterschiedliche Hashes erzeugen. Salzen tut nichts gegen die Geschwindigkeit des Algorithmus, sodass ein Angreifer jeden gesalzenen SHA-256-Hash immer noch mit Milliarden von Versuchen pro Sekunde knackt. Sie benötigen sowohl ein eindeutiges Salt als auch einen langsamen Algorithmus, genau das bieten bcrypt und Argon2.

Ist MD5 für irgendetwas sicher? Nur für nicht sicherheitsrelevante Korruptionsprüfungen, wie die Bestätigung, dass eine Datei fehlerfrei heruntergeladen wurde. MD5 ist kollisionsanfällig und darf daher niemals für digitale Signaturen, Zertifikate, Passwörter oder irgendetwas verwendet werden, das ein Angreifer fälschen oder knacken könnte. Selbst für Dateiintegrität gegenüber einem echten Gegner bevorzugen Sie SHA-256. Sie können sehen, wie MD5 im Vergleich zu anderen Digests abschneidet, mit einem kostenlosen Hash-Generator.

Was ist ein Arbeitsfaktor bei bcrypt? Der Arbeitsfaktor (auch Kosten genannt) ist eine Zahl, die steuert, wie viele interne Iterationen bcrypt durchführt. Jede Erhöhung um eins verdoppelt ungefähr die Zeit, einen einzelnen Hash zu berechnen. Sie setzen ihn so, dass ein Hash eine kleine, aber spürbare Bruchteil einer Sekunde auf Ihrer Produktionshardware dauert, was Logins für Sie schnell hält, während Massenknacken für Angreifer langsam wird. Erhöhen Sie ihn im Laufe der Zeit, wenn die Hardware schneller wird.