Kombinieren Sie Ihr Passwort-Hashing mit starken Zufallspasswörtern aus dem Passwort-Generator.
Warum Passwörter nicht mit SHA gehasht werden dürfen
SHA-256 und Verwandte sind auf Geschwindigkeit ausgelegt – und Geschwindigkeit lieben Angreifer: Spezielle Hardware kann Milliarden von Versuchen pro Sekunde gegen eine geleakte Hash-Datenbank testen.
Passwort-Hashing muss daher bewusst teuer sein. bcrypt und scrypt ergänzen ein individuelles Salt und einen einstellbaren Arbeitsfaktor, sodass jeder Versuch echte Zeit, Speicher oder beides kostet.
Wie bcrypt funktioniert
bcrypt basiert auf dem Blowfish-Schlüsselplan. Ein Kostenfaktor (2^cost Iterationen) steuert den Aufwand pro Hash, und ein 128-Bit-Salt wird mit dem Ergebnis gespeichert.
Die wichtigste Einschränkung ist das 72-Byte-Limit: Längere Passwörter werden gekürzt, sofern die Bibliothek nicht vorher hasht. Und weil bcrypt nur CPU-gebunden ist, knacken GPU-Cluster schwache bcrypt-Hashes schnell.
Wie scrypt sich unterscheidet
scrypt ist speicherhart: Es füllt während der Ableitung einen großen Speicherblock, sodass ein Angreifer pro Versuch entweder viel RAM einsetzen oder langsam neu rechnen muss.
Die Parameter N (CPU-/Speicherkosten), r (Blockgröße) und p (Parallelisierung) justieren das Verhältnis. Speicherhärte gibt scrypt bessere GPU- und ASIC-Resistenz als bcrypt bei vergleichbaren Einstellungen.
bcrypt vs. scrypt im Überblick
| Eigenschaft | bcrypt | scrypt |
|---|---|---|
| Typ | CPU-gebunden | Speicherhart |
| Eingabelimit | 72 Bytes | Praktisch unbegrenzt |
| Wichtige Parameter | cost (2^cost Iterationen) | N, r, p |
| GPU/ASIC-Resistenz | Mäßig | Stärker |
| Ökosystem | Sehr weit verbreitet | Weit verbreitet, weniger Defaults |
Was Sie 2026 verwenden sollten
- Erste Wahl: Argon2id, der moderne speicherharte Gewinner mit dedizierter Hardware-Resistenz
- Zweite Wahl: scrypt, wenn Argon2 nicht verfügbar ist
- Legacy: bcrypt ist akzeptabel, wenn cost ≥ 12 und Eingaben über 72 Bytes vorab gehasht werden
- Immer ein individuelles Zufalls-Salt verwenden und nie eigene Algorithmen bauen
Warnung: Erfinden Sie keine Pepper-Varianten, Doppel-Hashes oder eigene Iterationen „für mehr Sicherheit“. Komplexität erzeugt Implementierungsfehler; Standard-Algorithmen mit sinnvollen Parametern gewinnen.
FAQ
Q.Ist bcrypt 2026 noch sicher?
A.Ja, mit ausreichendem Kostenfaktor (≥ 12) und individuellem Salt. Für neue Systeme bieten Argon2id und scrypt aber bessere GPU- und ASIC-Resistenz.
Q.Welchen Kostenfaktor sollte ich verwenden?
A.Den höchsten, den Ihre Nutzer tolerieren. Messen Sie die Login-Latenz: Ziel sind etwa 100–300 ms auf Ihrer Hardware, mit Reserven für künftige CPU-Upgrades.
Q.Kann ich scrypt in Node.js verwenden?
A.Ja. Node.js bringt crypto.scrypt und crypto.scryptSync nativ mit; die meisten Frameworks bieten außerdem scrypt- oder Argon2-Bindungen. Nutzen Sie die asynchrone Variante, um den Event-Loop nicht zu blockieren.
Referenzen
- OWASP Password Storage Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
- NIST SP 800-63B – Digital Identity Guidelines: Authentication: https://pages.nist.gov/800-63-3/sp800-63b.html
Mit starkem Passwort starten
Zufallspasswörter mit eigenen Regeln, direkt im Browser erzeugt.
Reihenfolge der Wahl
Nehmen Sie Argon2id, wenn Ihr Framework es mitbringt, sonst scrypt, und behalten Sie bcrypt mit cost ≥ 12 für Altlasten. Salzen Sie jedes Passwort mit frischen Zufallsbytes.
Beginnen Sie mit starkem Input: erzeugen Sie Zufallspasswörter lokal mit dem Passwort-Generator.