Warum die alten Passwort-Regeln falsch waren
Jahrzehntelang haben Systeme Passwörter wie "P@ssw0rd1!" erzwungen: mindestens 8 Zeichen, Großbuchstabe, Kleinbuchstabe, Ziffer, Sonderzeichen. Das Ergebnis? Benutzer verwenden vorhersagbare Muster — erster Buchstabe groß, Zahl am Ende, @ statt a. Angreifer kennen diese Muster und ihre Wörterbuch-Angriffe berücksichtigen sie längst.
Das BSI (Bundesamt für Sicherheit in der Informationstechnik) und das NIST (SP 800-63B) empfehlen seit Jahren: Länge schlägt Komplexität. Ein 20-Zeichen-Passwort aus Kleinbuchstaben ist stärker als ein 8-Zeichen-Passwort mit Sonderzeichen. Der Grund liegt in der Mathematik der Entropie.
Erzwungene Komplexitätsregeln führen außerdem dazu, dass Benutzer Passwörter aufschreiben, überall dasselbe verwenden, oder minimal ändern (Passwort1, Passwort2, Passwort3). Das untergräbt die Sicherheit mehr als einfache aber lange Passwörter.
Die modernen Empfehlungen: Mindestlänge 12–16 Zeichen (besser mehr), keine Komplexitätsregeln erzwingen, gegen bekannte kompromittierte Passwörter prüfen (Have I Been Pwned API), und Multi-Faktor-Authentifizierung als zweite Verteidigungslinie einsetzen.
Entropie verstehen: Die Mathematik hinter Passwortstärke
Entropie misst die Unvorhersagbarkeit eines Passworts in Bits. Die Formel für ein zufällig generiertes Passwort: E = log₂(Alphabetgröße^Länge) = Länge × log₂(Alphabetgröße). Ein 8-Zeichen-Passwort aus Kleinbuchstaben (26 Zeichen) hat: 8 × log₂(26) ≈ 8 × 4,7 ≈ 37,6 Bits Entropie.
Was bedeuten die Bit-Werte praktisch? Bei 40 Bits Entropie gibt es etwa 1 Billion mögliche Passwörter — ein moderner GPU-Cluster knackt das in Sekunden wenn der Hash schwach ist (MD5, SHA-1). Bei 80 Bits sind es 1,2 × 10²⁴ Möglichkeiten — selbst mit Brute-Force gegen einen schnellen Hash dauert das Jahrhunderte.
Empfohlene Mindest-Entropie 2026: 60 Bits für unkritische Accounts, 80 Bits für wichtige Accounts (E-Mail, Banking), 128 Bits für Master-Passwörter (Passwort-Manager) und kryptographische Schlüssel. Unser Passwort-Generator zeigt die berechnete Entropie für jedes generierte Passwort an.
Wichtig: Diese Berechnung gilt nur für wirklich zufällig generierte Passwörter. Ein von Menschen gewähltes 12-Zeichen-Passwort hat typischerweise deutlich weniger als die theoretischen 12 × 6,5 = 78 Bits, weil Menschen vorhersagbare Muster verwenden. Wörterbuch-basierte Schätzungen (wie zxcvbn) sind realistischer.
Entropie-Tabelle für zufällige Passwörter:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Alphabet │ Bits/Zeichen │ 12 Zeichen │ 16 Zeichen
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Ziffern (0-9) │ 3,3 Bits │ 39,9 Bits │ 53,2 Bits
Kleinbuchstaben (a-z) │ 4,7 Bits │ 56,4 Bits │ 75,2 Bits
Groß+Klein+Ziffern │ 5,95 Bits │ 71,5 Bits │ 95,3 Bits
Alle druckbaren ASCII (95) │ 6,57 Bits │ 78,8 Bits │ 105,1 Bits
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Passphrases (Diceware, 7776 Wörter): ~12,9 Bits pro Wort
4 Wörter ≈ 51,7 Bits │ 5 Wörter ≈ 64,6 Bits │ 6 Wörter ≈ 77,5 BitsPassphrases: Sicher und merkbar
Eine Passphrase besteht aus mehreren zufällig gewählten Wörtern: "korrekt pferd batterie heftklammer" (das berühmte XKCD-936-Beispiel). Der Vorteil: Leichter zu merken als "x7$kQ2!mZ" bei gleicher oder höherer Entropie. Eine 4-Wort-Passphrase aus einer 7776-Wort-Liste (Diceware) hat ~51,7 Bits Entropie.
Für gute Passphrases brauchst du echte Zufälligkeit bei der Wortwahl — nicht einfach Wörter nehmen die dir einfallen. Diceware verwendet physische Würfel: Fünf Würfe ergeben eine 5-stellige Zahl, die einem Wort in der Liste zugeordnet ist. Digital generierte Passphrases verwenden kryptographisch sichere Zufallsgeneratoren (crypto.getRandomValues).
Empfohlene Länge 2026: Mindestens 5 Wörter (64+ Bits) für normale Accounts, 6–7 Wörter (77–90 Bits) für kritische Accounts. Optional kannst du ein zufälliges Zeichen oder eine Zahl zwischen die Wörter setzen, um Wörterbuch-Angriffe weiter zu erschweren.
Nachteile von Passphrases: Sie sind länger zu tippen (besonders auf Mobilgeräten), und manche Systeme haben lächerliche Maximallängen (16 oder 20 Zeichen). In solchen Fällen ist ein Passwort-Manager mit generierten Zufallspasswörtern die bessere Lösung.
Passwort-Hashing: Wie du Passwörter korrekt speicherst
Speichere niemals Passwörter im Klartext oder mit reversibler Kodierung (Base64, AES). Verwende einen spezialisierten Passwort-Hashing-Algorithmus: Argon2id (Gewinner der Password Hashing Competition 2015), bcrypt (bewährt seit 1999), oder scrypt. Diese sind absichtlich langsam, um Brute-Force-Angriffe zu erschweren.
Warum nicht SHA-256? Schnelle Hash-Funktionen wie SHA-256 oder MD5 sind für Passwort-Hashing ungeeignet, weil sie genau dafür optimiert sind: schnell zu sein. Eine moderne GPU berechnet Milliarden von SHA-256-Hashes pro Sekunde. Argon2id hingegen ist so konfigurierbar, dass ein einziger Hash 100ms+ dauert und viel Speicher verbraucht.
Argon2id-Parameter für 2026: Mindestens 64 MB Speicher (memory), 3 Iterationen (time), 4 Lanes (parallelism). Das ergibt eine Hash-Zeit von ~100–200ms auf moderner Server-Hardware — schnell genug für Login, aber langsam genug um Brute-Force unwirtschaftlich zu machen.
Salting ist bei allen modernen Hashing-Algorithmen eingebaut: bcrypt und Argon2 generieren automatisch einen zufälligen Salt und speichern ihn im Hash-Output. Du musst (und sollst) den Salt nicht separat verwalten. Das verhindert Rainbow-Table-Angriffe und stellt sicher, dass identische Passwörter verschiedene Hashes produzieren.
// Argon2id mit Node.js (empfohlen für 2026)
import { hash, verify } from '@node-rs/argon2';
// Passwort hashen (bei Registrierung)
const passwordHash = await hash(userPassword, {
memoryCost: 65536, // 64 MB
timeCost: 3, // 3 Iterationen
parallelism: 4, // 4 Threads
outputLen: 32, // 256-Bit Output
});
// "$argon2id$v=19$m=65536,t=3,p=4$..."
// Passwort verifizieren (bei Login)
const isValid = await verify(storedHash, inputPassword);
// bcrypt Alternative (falls Argon2 nicht verfügbar)
import bcrypt from 'bcrypt';
const bcryptHash = await bcrypt.hash(password, 12); // 12 Runden
const bcryptValid = await bcrypt.compare(input, bcryptHash);Passwort-Manager: Die praktische Lösung
Die sicherste Strategie für 2026: Ein Passwort-Manager generiert und speichert einzigartige, zufällige Passwörter für jeden Account. Du merkst dir nur ein starkes Master-Passwort (Passphrase mit 6+ Wörtern). Der Manager erledigt den Rest — Generierung, Speicherung, Auto-Fill.
Die Mathematik dafür: Statt 100 mittelmäßige Passwörter mit 40 Bits Entropie zu merken, hast du 100 perfekte Passwörter mit 128 Bits Entropie, geschützt durch ein Master-Passwort mit 80+ Bits. Das Risiko konzentriert sich auf einen Punkt — den schützt du mit MFA.
Empfohlene Passwort-Manager-Einstellungen: Generierte Passwörter mit 20+ Zeichen (Groß/Kleinbuchstaben + Ziffern + Sonderzeichen), automatischer Wechsel bei bekannten Breaches, und Ausschluss von visuell ähnlichen Zeichen (0/O, l/1/I) wenn du Passwörter gelegentlich manuell eintippen musst.
Für Teams und Unternehmen: Bitwarden (Open Source, self-hostable), 1Password (Business-Features wie Vaults und Zugriffskontrollen), oder KeePass (lokal, kein Cloud-Sync). Die Wahl hängt von Compliance-Anforderungen und der bestehenden Infrastruktur ab.
Multi-Faktor-Authentifizierung (MFA)
Selbst das beste Passwort schützt nicht vor Phishing, Keyloggern oder Server-Breaches. MFA fügt eine zweite Verteidigungslinie hinzu: Etwas das du weißt (Passwort) + etwas das du hast (Handy, Hardware-Key) oder etwas das du bist (Biometrie).
Die Hierarchie der MFA-Methoden 2026 (von stark zu schwach): Hardware-Security-Keys (FIDO2/WebAuthn) > Passkeys (gerätegebunden) > TOTP-Apps (Google Authenticator, Authy) > Push-Benachrichtigungen > SMS-Codes. SMS ist anfällig für SIM-Swapping und sollte nur als Fallback dienen.
TOTP (Time-based One-Time Passwords) basiert auf einem geteilten Secret und der aktuellen Uhrzeit. Alle 30 Sekunden wird ein neuer 6-stelliger Code generiert. Das Secret wird typischerweise als Base32-kodierter String im QR-Code übertragen. Speichere die Recovery-Codes sicher — ohne sie verlierst du den Zugang bei Geräteverlust.
Passkeys (WebAuthn/FIDO2) sind die Zukunft: Kein Passwort, kein Phishing-Risiko, kein Replay-Angriff möglich. Der private Schlüssel verlässt nie das Gerät. Für Entwickler: Implementiere WebAuthn als primäre Anmeldung und Passwort+TOTP als Fallback für Geräte die Passkeys nicht unterstützen.
Breach-Erkennung und Credential Stuffing
Credential Stuffing ist der häufigste Angriffsvektor 2026: Angreifer nehmen Benutzername/Passwort-Kombinationen aus einem Leak (z.B. LinkedIn 2012, 700M+ Accounts) und probieren sie bei anderen Diensten. Weil Menschen Passwörter wiederverwenden, funktioniert das erschreckend oft.
Als Entwickler solltest du bei der Registrierung und beim Passwort-Ändern gegen die Have I Been Pwned API prüfen. Die API arbeitet mit k-Anonymity: Du sendest nur die ersten 5 Zeichen des SHA-1-Hashes und bekommst eine Liste aller Hashes mit diesem Prefix zurück. So erfährt der Service nie das vollständige Passwort.
Für bestehende Accounts: Implementiere schrittweise Prüfung beim Login. Wenn ein Benutzer sich erfolgreich anmeldet und sein Passwort in einer Breach-Datenbank auftaucht, fordere ihn auf, es zu ändern. Zwinge ihn nicht sofort zum Ändern — das führt zu Support-Tickets und Frustration.
Rate-Limiting ist essentiell: Begrenze Login-Versuche auf 5–10 pro Minute pro Account, mit exponentiellem Backoff. Verwende CAPTCHAs nach mehreren fehlgeschlagenen Versuchen. Für APIs: API-Keys oder OAuth statt Passwort-basierte Authentifizierung.
// Have I Been Pwned API (k-Anonymity-Ansatz)
async function isPasswordBreached(password) {
const encoder = new TextEncoder();
const data = encoder.encode(password);
const hashBuffer = await crypto.subtle.digest('SHA-1', data);
const hashHex = Array.from(new Uint8Array(hashBuffer))
.map(b => b.toString(16).padStart(2, '0'))
.join('')
.toUpperCase();
const prefix = hashHex.slice(0, 5);
const suffix = hashHex.slice(5);
const response = await fetch(
`https://api.pwnedpasswords.com/range/${prefix}`
);
const text = await response.text();
// Prüfe ob der Suffix in der Antwort vorkommt
return text.split('\n').some(line =>
line.startsWith(suffix)
);
}Zusammenfassung: Passwort-Checkliste für Entwickler
Für Benutzer-Interfaces: Mindestlänge 12 Zeichen erzwingen, keine Maximallänge unter 128 Zeichen, keine Komplexitätsregeln, Passwort-Stärke visuell anzeigen (zxcvbn-Bibliothek), gegen Breach-Datenbanken prüfen, und MFA anbieten (idealerweise Passkeys).
Für Backend-Systeme: Argon2id mit empfohlenen Parametern verwenden, niemals eigene Krypto implementieren, Timing-sichere Vergleichsfunktionen für Hash-Verifikation nutzen (verhindert Timing-Angriffe), und regelmäßig die Hashing-Parameter erhöhen wenn Hardware schneller wird.
Für die eigene Praxis: Passwort-Manager verwenden, einzigartige Passwörter für jeden Dienst, MFA überall wo möglich aktivieren, Recovery-Codes sicher offline speichern, und regelmäßig prüfen ob eigene Accounts von Breaches betroffen sind.
Zukunftsausblick: Passkeys werden Passwörter langfristig ersetzen. Bis dahin ist die Kombination aus Passwort-Manager + MFA der beste Schutz. Biometrische Authentifizierung (Face ID, Fingerabdruck) ist bequem, sollte aber immer an ein Geräte-Secret gebunden sein — biometrische Daten allein sind keine Geheimnisse (du hinterlässt Fingerabdrücke überall).