Alle drei Monate das Passwort ändern. Mindestens ein Großbuchstabe, eine Zahl, ein Sonderzeichen. Nicht im Wörterbuch vorkommen. Und wehe, es ähnelt einem der letzten zehn Passwörter.

Diese Regeln kennen wir alle. Sie wurden uns jahrelang eingehämmert — von Active-Directory-Policies, Compliance-Checklisten und dem gut gemeinten Security-Onkel aus der IT. Das Problem: Sie sind falsch. Nicht „vielleicht nicht mehr optimal" falsch, sondern „führt nachweislich zu unsichereren Passwörtern" falsch.

NIST hat das 2017 erkannt und 2024 nochmal nachgeschärft. Das BSI hat nachgezogen. OWASP sowieso. Dieser Artikel fasst zusammen, was die drei wichtigsten Autoritäten heute empfehlen — und was du in deiner Passwort-Policy ändern solltest. Mit dem bitcalc Passwort-Generator setzt du die Empfehlungen direkt um.

Die Todsünden der alten Passwort-Policy

Bevor wir zu den Empfehlungen kommen, ein kurzer Blick zurück. Warum war das alles falsch?

1. Komplexitätsregeln („mindestens ein Sonderzeichen")

Die Idee war: Je mehr Zeichentypen, desto mehr Kombinationsmöglichkeiten. Theoretisch richtig. Praktisch führt es zu Passwort123! — das beliebteste „erfüllt-die-Regeln"-Passwort in jeder Firma. Der Mensch ist kein Zufallsgenerator. Wenn du ihn zwingst, ein Sonderzeichen zu benutzen, hängt er ein Ausrufezeichen an. Das erhöht die Sicherheit nicht, es macht Passwörter vorhersagbar.

Praxis-Fakt Eine Studie von Microsoft Research (2016) hat gezeigt: Komplexitätsregeln erhöhen die Shannon-Entropie eines durchschnittlichen Benutzer-Passworts um etwa 2 Bit. Eine zufällige Erhöhung der Passwortlänge um zwei Zeichen erhöht die Entropie um 13 Bit. Länge schlägt Komplexität — um den Faktor 6.

2. Regelmäßiger Passwortwechsel („alle 90 Tage")

Das war mal sinnvoll, als Passwörter über unverschlüsselte Leitungen gingen und Brute-Force offline Monate dauerte. Heute ist das Gegenteil richtig: Wer sein Passwort alle drei Monate ändern muss, wählt schwächere Passwörter. Oder schreibt sie auf einen Zettel. Oder inkrementiert eine Zahl am Ende — Passwort123! wird zu Passwort124!. Niemand, wirklich niemand, denkt sich alle 90 Tage ein komplett neues, starkes Passwort aus.

3. Passwort-Hints und „Geheimfragen"

„Lieblingsfarbe?" — Blau. „Name des ersten Haustiers?" — Steht auf Instagram. „Mädchenname der Mutter?" — Einwohnermeldeamt. Geheimfragen sind ein Backdoor in jedes Konto, und zwar einer, der mit OSINT-Recherche statt mit Technik geöffnet wird.

Was NIST SP 800-63B heute fordert

Das National Institute of Standards and Technology (NIST) hat 2017 mit der Revision 800-63B die alte Policy-Ära beendet und 2024 mit dem vierten Update bestätigt. Die Kernforderungen:

  1. Mindestlänge: 8 Zeichen für benutzergenerierte Passwörter, 15 Zeichen für systemgenerierte (z.B. Service Accounts). Der Verifier MUSS längere Passwörter akzeptieren, mindestens 64 Zeichen.
  2. KEINE Komplexitätsregeln mehr. Kein Zwang zu Groß/Klein/Zahlen/Sonderzeichen. Der Benutzer SOLL alle druckbaren ASCII-Zeichen plus Unicode verwenden dürfen.
  3. KEIN regelmäßiger Passwortwechsel. Nur noch bei Kompromittierungsverdacht.
  4. Passwort-Blacklist. Der Verifier MUSS das Passwort gegen eine Liste bekannter kompromittierter Passwörter prüfen (Have-I-Been-Pwned-API, oder mindestens die Top-100.000).
  5. Keine Passwort-Hints. Keine Geheimfragen. Keine Wissensbasierte Authentifizierung.
  6. Copy-Paste erlauben. Der Verifier SOLL Einfügen aus der Zwischenablage im Passwortfeld zulassen.
Entropie-Tabelle: Passwortlänge vs. Zeichensatz vs. Knackzeit
Entropie in Bit: Ab 60 Bit gilt ein Passwort als sicher. Ein 8-Zeichen-Passwort mit Sonderzeichen (52 Bit) ist schwächer als ein 12-Zeichen-Passwort nur aus Kleinbuchstaben (56 Bit).

BSI: Der deutsche Blick

Das Bundesamt für Sicherheit in der Informationstechnik hat seinen IT-Grundschutz aktualisiert. Die BSI-Empfehlungen decken sich weitgehend mit NIST, setzen aber eigene Akzente:

  • Mindestens 8 Zeichen, aber ausdrückliche Empfehlung für längere Passwörter (12+).
  • Keine Komplexitätsregeln. Der Passwort-Generator auf bitcalc folgt genau dieser Logik: Du stellst die Länge ein, der Rest ist optional.
  • Zwei-Faktor-Authentisierung wird als Ergänzung empfohlen, nicht als Ersatz für schwache Passwörter.
  • Kein Passwortwechsel-Zwang.
  • Besonderer Fokus auf Service-Accounts: Systempasswörter müssen mindestens 24 Zeichen haben und in einem Secrets Manager verwaltet werden.

OWASP: Die Sicht der Entwickler

Das Open Web Application Security Project liefert mit dem Application Security Verification Standard (ASVS) die pragmatischste Checkliste. OWASP unterscheidet drei Levels:

Level Min. Länge Blacklist Credential Recovery
ASVS L1 (Basic)8 ZeichenTop-10.000Rate Limiting
ASVS L2 (Standard)8 ZeichenTop-100.000 + HIBPMulti-Faktor erforderlich
ASVS L3 (High)12+ Zeichen oder MFAHIBP + eigene WatchlistMFA + phys. Token

OWASP geht weiter als NIST, was Credential Recovery angeht: Schon auf Level 1 muss Rate Limiting aktiv sein (maximal 10 Fehlversuche pro Stunde). Auf Level 2 ist Multi-Faktor-Authentisierung Pflicht. Auf Level 3 wird ein physischer Token oder FIDO2-Schlüssel verlangt.

NIST vs. BSI vs. OWASP Empfehlungen im Vergleich
NIST, BSI und OWASP im direkten Vergleich. Die Kernaussage ist überall gleich: Länge > Komplexität, keine erzwungenen Wechsel, Passwort-Blacklist.

Passkeys: Das Ende des Passworts?

Passkeys (FIDO2/WebAuthn) sind der Elefant im Raum, über den alle reden, aber den kaum jemand umsetzt. Die Idee: Statt eines shared secret (Passwort) wird ein Public-Key-Paar verwendet. Der private Schlüssel verlässt das Gerät nie. Login passiert per Biometrie oder PIN — aber lokal, nicht auf dem Server.

Das BSI empfiehlt Passkeys seit 2024 explizit. Google, Apple und Microsoft unterstützen sie. Trotzdem sind sie in Unternehmensumgebungen noch selten — weil Active Directory kein natives FIDO2 kann (Azure AD / Entra ID schon), weil Legacy-Anwendungen keine WebAuthn-Endpunkte haben und weil der Rollout auf 5.000 Geräten kein Wochenendprojekt ist.

Für öffentliche Webdienste ist der Passkey das beste, was der Authentifizierung seit OAuth passiert ist. Für interne Umgebungen: Kommt drauf an. Wenn deine Identity-Plattform FIDO2 kann, mach es. Wenn nicht, setz eine gute Passwort-Policy um und ergänze sie mit TOTP oder Hardware-Token. Ein schlechtes Passwort + TOTP ist immer noch ein schlechtes Passwort.

Der bitcalc Passwort-Generator: Policy-konform in einem Klick

Den Passwort-Generator habe ich so gebaut, dass er die NIST-Empfehlungen eins zu eins abbildet:

  • Standard: 20 Zeichen, keine erzwungenen Zeichentypen — aber du kannst sie optional dazuschalten
  • Jedes Passwort wird clientseitig generiert, nichts verlässt den Browser
  • Der Entropie-Wert wird live angezeigt, während du die Optionen änderst
  • Copy-Paste ist natürlich erlaubt (NIST sei Dank)
Praxistipp Ein 20-stelliges Passwort aus Kleinbuchstaben hat 94 Bit Entropie. Das reicht, um selbst einen massiven GPU-Cluster jahrelang zu beschäftigen. Kein Sonderzeichen nötig. Wer trotzdem „P@ssw0rt!" eintippt, dem hilft auch keine Policy.

Was ich in echten Umgebungen umgesetzt habe

  1. Die Passwort-Policy im Active Directory umstellen. „Passwords must meet complexity requirements" → deaktiviert. Minimale Länge auf 12 gesetzt. Die Anzahl der Helpdesk-Anrufe wegen vergessener Passwörter ist um 40% gesunken, weil Leute sich jetzt Passwörter merken können, die sie sich selbst ausgedacht haben.
  2. Have-I-Been-Pwned im Onboarding integrieren. Bei der Passwort-Wahl prüft der Identity-Provider gegen die HIBP-Datenbank. Das blockiert „Sommer2026!" und alle seine Verwandten.
  3. Passwort-Manager für alle. Die Firma hat Bitwarden für jeden Mitarbeiter lizenziert. Plötzlich waren 30-stellige Zufallspasswörter der Standard — weil niemand sie sich merken muss.

Deine neue Passwort-Policy — die Kurzfassung

Wenn du nur drei Dinge änderst, dann diese:

  1. Mindestlänge auf 12 Zeichen setzen, Komplexitätsregeln abschaffen.
  2. Passwortwechsel nur noch bei Verdacht auf Kompromittierung.
  3. Eine Passwort-Blacklist einsetzen (HIBP-API, mindestens Top-100.000).

Alles andere — MFA, Passkeys, Hardware-Token — sind Addons, die auf dieser Basis aufbauen. Aber ohne diese Basis sind auch die Addons nichts wert.