bcrypt für das Passwort-Hashing Warum allein die Verschlüsselung nicht genügt

Wenn Sie Benutzerpasswörter mit AES, RSA oder sogar SHA-256 speichern, tun Sie es falsch. Keine leichte Fehlertat – eine grundlegende Fehlertat. Dies ist der häufigste Sicherheitsfehler in der Webentwicklung, und er hat eine einfache Lösung: Verwenden Sie eine geeignete Passwort-Hash-Funktion wie bcrypt.

Warum das wichtig ist, wie bcrypt funktioniert und wie fertige Code aussieht.

Warum Passwörter besondere Behandlung benötigen

Die meisten kryptografischen Operationen sind so konzipiert, dass sie umkehrbar oder schnell sind. Verschlüsselung ist durch Design umkehrbar – das ist ihr gesamter Zweck. SHA-256 und MD5 sind schnell, verarbeiten Gigabytes pro Sekunde. Beide Eigenschaften sind katastrophal für Passwörter.

Wenn ein Angreifer Ihre Datenbank erhält, erhält er Ihre Passwort-Hashes. Bei Verschlüsselung, wenn sie den Schlüssel finden, entschlüsseln sie alles. Bei schnellen Hash-Funktionen wie MD5 oder SHA-256 führen sie einen GPU-verbesserten Brute-Force-Angriff durch – moderne Hardware kann pro Sekunde hunderte von Milliarden von MD5-Hashes testen. Ihr „komplexes“ Passwort wird in Minuten gekracht.

Passwörter müssen:

1. nicht umkehrbar sein – selbst mit dem Schlüssel oder dem Algorithmus können Sie das Klartext nicht zurückgewinnen
2. langsam berechnet werden – gezielte Langsamkeit macht Brute-Force-Angriffe unwahrscheinlich
3. für jeden Benutzer einzigartig sein – identische Passwörter müssen unterschiedliche Hashes erzeugen

bcrypt erfüllt alle drei. Allgemeine Hash-Funktionen und Verschlüsselung erfüllen dies nicht.

Hashen vs. Verschlüsselung vs. Passwort-Hashing

Diese sind nicht austauschbar:

Ansatz	Umkehrbar?	Schnell?	Sicher für Passwörter?
Verschlüsselung (AES, RSA)	Ja – mit Schlüssel	Ja	NEIN
Schnelle Hash-Funktionen (MD5, SHA-256)	NEIN	Ja (durch Design)	NEIN
Passwort-Hashing (bcrypt, Argon2id)	NEIN	Nein (durch Design)	Ja

Die Umkehrbarkeit von Verschlüsselung ist ein Deal-Breaker: Wenn der Schlüssel kompromittiert wird, sind alle Passwörter kompromittiert. Schnelle Hash-Funktionen sind ebenfalls ein Deal-Breaker: Die Geschwindigkeit ermöglicht Brute-Force-Angriffe. Passwort-Hash-Funktionen wurden so konzipiert, dass sie langsam sind – und das ist der Punkt.

Wie bcrypt funktioniert

bcrypt, entwickelt 1999 von Niels Provos und David Mazières, macht drei Dinge, die wichtig sind:

1. Salting. Bevor das Passwort gehasht wird, generiert bcrypt einen zufälligen Salt (16 Bytes) und fügt ihn dem Hash-Ergebnis hinzu. Selbst wenn zwei Benutzer das gleiche Passwort verwenden, sind ihre Hashes unterschiedlich. Dadurch wird eine vorberechnete Rainbow-Table-Angriff vollständig abgeschwächt.

2. Work-Faktor (Cost). bcrypt akzeptiert einen Cost-Parameter (normalerweise 10–14). Jede Erhöhung verdoppelt die Berechnungszeit. Bei Cost 12 dauert die Hash-Funktion etwa 250–400 ms auf modernen Geräten. Das ist für eine Login-Anfrage imperceptibly langsam – aber es macht einen Milliardenversuch-Brute-Force-Angriff zu einer Jahrzehntlange Operation.

3. Das Ergebnis ist selbstständig. Ein bcrypt-Hash sieht aus wie $2b$12$... und enthält die Algorithmus-Version, den Cost-Faktor, den Salt und den Hash zusammen. Sie benötigen keine separate Salt-Spalte. Speichern Sie die ganze Zeichenkette.

Produktions-Code: Node.js und Python

Node.js (bcryptjs oder bcrypt)

const bcrypt = require('bcrypt');

const SALT_ROUNDS = 12;

// Hash a password
async function hashPassword(plaintext) {
  return bcrypt.hash(plaintext, SALT_ROUNDS);
}

// Verify a password against a stored hash
async function verifyPassword(plaintext, storedHash) {
  return bcrypt.compare(plaintext, storedHash);
}

// Usage
const hash = await hashPassword('hunter2');
// Store `hash` in your database

const isValid = await verifyPassword('hunter2', hash);
// true

Python (bcrypt)

import bcrypt

COST = 12

def hash_password(plaintext: str) -> bytes:
    salt = bcrypt.gensalt(rounds=COST)
    return bcrypt.hashpw(plaintext.encode('utf-8'), salt)

def verify_password(plaintext: str, stored_hash: bytes) -> bool:
    return bcrypt.checkpw(plaintext.encode('utf-8'), stored_hash)

# Usage
hashed = hash_password('hunter2')
# Store hashed in your database

is_valid = verify_password('hunter2', hashed)
# True

Speichern Sie die vollständige Hash-String. Speichern Sie niemals das Klartext, speichern Sie niemals den Salt separat, speichern Sie niemals die Zwischenschritte.

Wählen Sie einen Work-Faktor

Der richtige Cost-Faktor hängt von Ihrem Hardware ab. Das Ziel: Machen Sie jede Hash-Operation auf Ihrem Produktions-Server 200–500ms lang. Das ist schnell genug für eine gute Benutzererfahrung, lang genug, um Angreifer zu verärgern.

Aktuelle Empfehlung: Cost 12 als Mindestwert, 14 für hochwertige Konten (Admin, finanzielle). Führen Sie eine Benchmark auf Ihrem tatsächlichen Hardware durch:

// Node.js: benchmark different cost factors
const bcrypt = require('bcrypt');

for (let cost = 10; cost <= 14; cost++) {
  const start = Date.now();
  await bcrypt.hash('benchmark', cost);
  console.log(`Cost ${cost}: ${Date.now() - start}ms`);
}

Wenn Cost 12 unter 100ms dauert, erhöhen Sie es. Wenn Cost 14 über 1000ms dauert, reduzieren Sie es auf 13. Überprüfen Sie jährlich – die Hardware wird schneller, und Ihr Cost-Faktor sollte sich anpassen.

Sie können bcrypt-Hashing interaktiv mit dem IO Tools bcrypt Hash Generator.

bcrypt vs. Argon2id vs. scrypt

bcrypt ist durchgeprüft und weit verbreitet. Hat jedoch eine Beschränkung: Es ist nicht memory-hard. Ein Angreifer mit spezieller Hardware (ASICs oder FPGAs) kann Angriffe effizienter parallelisieren als mit memory-hard Alternativen.

Algorithmus	Memory-hard	Parallelismus-resistent	Empfehlung
bcrypt	NEIN	Teilweise	Gute Standardwahl; verwenden Sie Cost ≥12
scrypt	Ja	Teilweise	Besser als bcrypt, weniger Tooling
Argon2id	Ja	Ja	Empfohlen für neue Projekte

Für neue Projekte: verwenden Sie Argon2id. Es hat den Password Hashing Competition (2015) gewonnen, ist memory-hard, resistent gegenüber GPU- und ASIC-Angriffen und ist nun in OWASP’s Top-Empfehlung. Die API ist fast identisch zu bcrypt.

Für bestehende Projekte: wenn Sie bereits auf bcrypt mit einem vernünftigen Cost-Faktor sind, ist die Migration nicht dringend. Fügen Sie es in Ihre nächste große Refaktor hinzu.

Gängige Implementierungsfehler

Das Hashen des Hashes. Einige Entwickler hashen das Passwort auf dem Client, bevor sie es senden, und hashen es dann erneut auf dem Server. Der Client-Hash wird zum „Passwort“. Sie hashen nun einen festen Hex-String, nicht ein von Menschen gewähltes Passwort – Sie verlieren nichts durch das doppelte Hash, aber Sie gewinnen auch nichts, und Sie führen Verwirrung ein.

Das 72-Byte-Abschneidungsproblem. bcrypt ignoriert automatisch alles außer den ersten 72 Bytes. Ein 100-Byte- und ein 72-Byte-Password, das die ersten 72 Bytes teilt, sind bei bcrypt identisch. Wenn Ihre Benutzer sehr lange Passwörter eingeben, ist dies eine unsichtbare Sicherheitsverschlechterung. Abhilfe: Hashen Sie vorher mit SHA-256, bevor Sie es an bcrypt weitergeben – aber nur wenn Sie die Auswirkungen vollständig verstehen und es klar dokumentieren.

Schwacher Work-Faktor. Cost 10 war 2011 angemessen. Im Jahr 2026 sollten Sie mindestens Cost 12 verwenden. Wenn Ihre bestehenden Datensätze Cost 10 verwenden, können Sie sie transparent aktualisieren: Nach einem erfolgreichen Login hashen Sie das überprüfte Passwort mit dem neuen Cost und speichern den aktualisierten Hash.

Async ist wichtig. bcrypt ist CPU-intensiv. Verwenden Sie immer die asynchrone API (wie oben gezeigt) in Node.js, um die Event-Schleife nicht zu blockieren. Synchronous bcrypt in einem Node-Server macht jede andere Anfrage aufrecht.

Migration von MD5/SHA zu bcrypt

Sie können das Passwort nicht ohne das ursprüngliche Klartext rehashen. Aber Sie können opportunisch migrieren:

1. Fügen Sie eine password_hash Spalte neben der alten password_md5 column
2. Bei einem erfolgreichen Login (wenn Sie das Klartext haben), hashen Sie das Passwort mit bcrypt und speichern Sie es in password_hash, löschen Sie die alte Spalte
3. Nach einer Migrationzeit können Benutzer, die nicht eingeloggt sind, gezwungen werden, ihr Passwort neu zu setzen
4. Einmal password_md5 ist leer für alle Benutzer, löschen Sie die Spalte

Dies ist der Standardansatz und erfordert keine Ausfallzeit.

Das Fazit

Verschlüsselung dient Daten, die Sie wiederholen müssen. Hashing dient Daten, die Sie überprüfen müssen. Passwörter sollten überprüft, nicht abgerufen werden – das bedeutet, dass Verschlüsselung das falsche Werkzeug ist.

bcrypt bietet Ihnen Salting, konfigurierbare Langsamkeit und ein selbstständiges Hash-Format. Es ist seit 25 Jahren die richtige Antwort. Verwenden Sie es mit einem Cost-Faktor von 12 oder höher, verwenden Sie Argon2id für neue Projekte und migrieren Sie so schnell wie möglich von MD5 und SHA-256.

Dieses Fehlverhalten ist kein hypothetischer Risiko. Datenbanken werden kompromittiert. Wenn sie das tun, sind bcrypt-hashete Passwörter rechnerisch schwer zu knacken. MD5-Hashes werden in der Nacht geknackt.

Das könnte Ihnen auch gefallen