Welche Passwort-Policy ist heute sinnvoll? Mindestlängen, Komplexität, Ablauf und Speicherung im Vergleich

Anforderungen an Passwörter: Mindestlängen, Passphrasen, Sperrlisten und die Rolle von Komplexität

Mindestlänge als primärer Sicherheitshebel

Die Mindestlänge beeinflusst die effektive Suchraumgröße stärker als viele gängige Komplexitätsregeln. In Offline-Angriffsszenarien (gestohlene Hashes) skaliert die Angreifbarkeit primär mit der Entropie des gewählten Geheimnisses und der Geschwindigkeit der Hash-Prüfung. Eine kurze Mindestlänge führt zu einem dominanten Risiko: Selbst robuste Hash-Verfahren können schwache, kurze Passwörter nicht „reparieren“, weil Angreifer Kandidaten in großen Mengen testen und erfolgreiche Treffer unabhängig vom Speichermodell bleiben.

Für Online-Login-Flows (ohne Hash-Exfiltration) wirkt Mindestlänge ebenfalls, jedoch in Kombination mit Rate-Limiting, Lockout-Strategien und MFA. Entscheidend ist, dass Richtlinien Mindestlänge nicht durch restriktive Zeichensatzverbote oder zu niedrige Maximalwerte konterkarieren. Zu enge Grenzen (etwa niedrige max length) drücken Nutzer in Wiederverwendung und Musterbildung, während passphrasenfreundliche Obergrenzen die Wahrscheinlichkeit einzigartiger Geheimnisse erhöhen.

Passphrasen: Länge, Wortlisten und Eingaberegeln

Passphrasen zielen darauf, Länge mit merkbarer Merkbarkeit zu verbinden. Praktisch entsteht Mehrwert, wenn Eingaben natürlich möglich bleiben: Leerzeichen, Umlaute und gängige Satzzeichen sollten akzeptiert werden; Normalisierung (z. B. Unicode-Normalformen) muss konsistent umgesetzt werden, damit gespeicherte und eingegebene Werte zuverlässig verglichen werden. Ebenso wichtig ist eine hohe zulässige Maximallänge, da Passphrase-Manager und zufällige Generatoren ansonsten abgeschnitten werden und dadurch ungewollt schwächer werden.

Wortlisten-basierte Passphrasen (mehrere zufällig gezogene Wörter) können hohe Entropie erreichen, wenn die Auswahl tatsächlich zufällig erfolgt und nicht aus naheliegenden Redewendungen besteht. Richtlinien sollten daher eher Rahmenbedingungen festlegen (Mindestlänge, Sperrlistenprüfung, Rate-Limits) als Nutzer zu bestimmten „Mustern“ zu drängen. Verbot von Leerzeichen oder die Begrenzung auf ASCII reduziert den Suchraum nicht für Angreifer, wohl aber die realistische Vielfalt bei Nutzern.

• Zulässige Zeichen: Leerzeichen und umfangreiche Unicode-Eingaben zulassen; problematische Steuerzeichen können serverseitig abgewiesen oder normalisiert werden, ohne Nutzer auf A–Z0–9 zu beschränken.
• Maximallänge: Obergrenze so wählen, dass Passwortmanager und Passphrasen nicht abgeschnitten werden (in der Praxis häufig 64 bis 128 Zeichen oder mehr), inklusive klarer Behandlung von Trimming und Unicode-Normalisierung.
• Fehlermeldungen: Bei Ablehnung keine Hinweise geben, ob Länge, Sperrlisten-Treffer oder Komplexität der Grund ist; dadurch sinkt die Nutzbarkeit als Orakel für Angreifer.

Sperrlisten (Blocklists) statt „kreativer“ Komplexitätsregeln

Sperrlisten adressieren ein Kernproblem: Viele Passwörter sind nicht zufällig, sondern vorhersehbar (häufige Wörter, Tastaturmuster, bekannte Leaks). Eine Blocklist-Prüfung beim Setzen oder Ändern eines Passworts kann diese Kandidaten zuverlässig ausschließen, ohne Nutzer zu Sonderzeichen- oder Großbuchstabenritualen zu zwingen. Wirksam wird der Ansatz, wenn er nicht nur exakte Treffer prüft, sondern auch einfache Varianten (z. B. angehängte Ziffern) und wenn die Datenbasis regelmäßig gepflegt wird.

In der Umsetzung zählt Datenschutz: Eine lokale Prüfung gegen gehashte/komprimierte Listen ist oft vorzuziehen. Falls ein externer Dienst genutzt wird, müssen Datenminimierung und Protokollierung restriktiv ausgelegt werden; übertragen werden sollte, wenn überhaupt, nur ein datenschutzarm gestalteter Prüfschlüssel und niemals das Klartextpasswort. Zusätzlich sollten Sperrlisten den Kontokontext einbeziehen: Unternehmensname, Produktname, E-Mail-Lokalteile oder triviale Ableitungen daraus sind für gezielte Angriffe besonders attraktiv.

Komplexität: begrenzter Nutzen, typische Nebenwirkungen

Komplexitätsanforderungen (mindestens Groß-/Kleinbuchstaben, Ziffern, Sonderzeichen) erzeugen messbare Nebenwirkungen: Nutzer weichen auf vorhersehbare Konstruktionen aus (z. B. Wort + ! + Jahreszahl), die in Angriffswörterbüchern standardmäßig enthalten sind. Damit sinkt die reale Entropie, obwohl formale Kriterien erfüllt sind. In Offline-Szenarien zählt die tatsächliche Unvorhersehbarkeit; Komplexitätsregeln fördern dagegen oft eine kleine Menge wiederholter Muster.

Sinnvoll bleibt Komplexität als weiche Leitplanke in engen Umgebungen, etwa wenn Passwörter zwangsläufig kurz sein müssen (historische Systeme) oder wenn Eingaben stark eingeschränkt sind. Moderne Policies priorisieren jedoch Länge, Blocklists, Rate-Limiting und sichere Speicherung. Wo Komplexität beibehalten wird, sollte sie minimalinvasiv sein und keine Zeichenklassen verbieten. Kritisch sind zudem Regeln, die das Kopieren/Einfügen unterbinden oder Passwortmanager erschweren; diese Maßnahmen erhöhen typischerweise die Wiederverwendung und senken die Gesamtsicherheit.

• Bevorzugte Leitplanke: Mindestlänge plus Sperrlistenprüfung statt starrer Klassenregeln; Komplexität nur ergänzend und nicht als Ersatz für Länge.
• Verbotene Anti-Pattern: „Passwort darf keinen Sonderchar enthalten“ oder „nur ASCII“; solche Einschränkungen reduzieren Eingabevielfalt und brechen Passwortmanager-Workflows.
• Interoperabilität: Klar definierte Normalisierung (z. B. Unicode) und konsistente Behandlung von führenden/trailing Spaces; ansonsten entstehen schwer nachvollziehbare Zurücksetzungen und Support-Fälle.

Ablauf, Fehlversuche und Durchsetzung: Rotation, Lockout, Rate-Limiting und risikobasierte Kontrollen

Durchsetzungsmechanismen entscheiden darüber, ob eine Passwort-Policy in der Praxis Sicherheitswirkung entfaltet oder vor allem Reibung erzeugt. Ablaufregeln (Rotation), Reaktionen auf Fehlversuche (Lockout), technische Bremssysteme gegen automatisierte Angriffe (Rate-Limiting) sowie risikobasierte Kontrollen (Risk-based / Adaptive Authentication) greifen ineinander. Eine saubere Policy trennt dabei zwischen Maßnahmen, die Angriffe erschweren, und solchen, die Missbrauch nach Kompromittierung begrenzen. Gerade bei Passwortrotation lohnt Präzision: erzwungene Wechsel ohne Anlass fördern vorhersehbare Varianten und senken damit häufig die tatsächliche Sicherheit.

Rotation und Ablauf: wann ein Passwortwechsel sinnvoll ist

Passwortablauf lässt sich technisch leicht erzwingen, ist aber konzeptionell umstritten. Moderne Leitlinien vieler Sicherheitsprogramme behandeln periodische Rotation als Ausnahme, nicht als Standard: Ein Wechsel ist vorrangig dann angebracht, wenn ein Passwort kompromittiert wurde, ein Verdacht besteht (z. B. Phishing, Malware, Credential-Stuffing-Erfolg) oder wenn ein Konto in einen höheren Schutzbedarf wechselt. In Umgebungen, in denen Passwörter nicht die Primärhürde sind (z. B. mit FIDO2/Passkeys als verpflichtender Faktor), kann Rotation für reine Fallback-Passwörter sogar kontraproduktiv sein, weil sie selten genutzt und dann eher vergessen werden.

Wenn Rotation dennoch erforderlich ist, sollte sie mit Kontrollen flankiert werden: Historienprüfung gegen Wiederverwendung, Mindestalter zur Vermeidung schneller „Durchklick“-Wechsel und kompromissorientierte Trigger (z. B. Leaks, ungewöhnliche Anmeldemuster). Wichtig ist außerdem die Differenzierung nach Kontotyp: privilegierte Konten benötigen oft strengere Regeln, Servicekonten hingegen sollten nach Möglichkeit durch verwaltete Identitäten, Zertifikate oder Secrets-Management ersetzt werden, statt mit menschlichen Rotationsprozessen zu arbeiten.

Lockout-Strategien: Schutz vor Brute-Force ohne Selbst-DoS

Account-Lockout nach Fehlversuchen ist ein klassisches Mittel gegen Online-Brute-Force, kann aber zum Angriffsvektor werden: Angreifer lösen gezielt Sperren aus, um legitime Nutzerkonten außer Gefecht zu setzen (Denial-of-Service). Robuste Designs kombinieren deshalb mehrere Stellschrauben: graduelle Verzögerungen statt harter Sperren, Sperren nur bei eindeutigem Online-Passwortraten (nicht bei MFA-Fehlern), sowie eine Entsperrlogik, die Self-Service erlaubt, aber Missbrauch begrenzt (z. B. Entsperren nur nach zusätzlicher Verifikation).

Für privilegierte Konten sind strengere Reaktionen vertretbar, allerdings sollte der Betrieb „break-glass“-Konten separat absichern, um bei großflächigen Lockouts handlungsfähig zu bleiben. In föderierten Szenarien ist außerdem wichtig, ob Sperrungen am Identity Provider, an der Applikation oder an einem vorgelagerten Gateway umgesetzt werden; inkonsistente Sperrorte führen häufig zu verwirrenden Fehlbildern und Supportlast.

• Schwellwerte differenzieren: Separate Zähler pro Konto und pro Quelle (z. B. IP/ASN/Device-Fingerprint) reduzieren Self-DoS; reine Konto-Zähler begünstigen gezieltes Aussperren.
• Progressive Verzögerung bevorzugen: Nach mehreren Fehlversuchen Verzögerungen (z. B. 1 s, 2 s, 4 s, …) sind oft wirksamer als lange harte Sperren und bleiben für legitime Nutzer besser beherrschbar.
• Entsperrung absichern: Self-Service-Entsperren sollte eine zusätzliche Prüfung verlangen (z. B. Schritt-up mit FIDO2/Passkey oder Einmalcode), statt allein über E-Mail-Links zu erfolgen.
• Fehlerfeedback begrenzen: Einheitliche Fehlermeldungen („Anmeldung nicht möglich“) vermeiden Account-Enumeration, ohne die Ursachenanalyse komplett zu verhindern; detaillierte Gründe gehören in Logs, nicht ins UI.

Rate-Limiting und Erkennung automatisierter Angriffe

Rate-Limiting zielt auf die eigentliche Angriffsschleife: massenhaft wiederholte Login-Versuche. Es wirkt gegen Credential Stuffing, Passwortspraying und verteilte Brute-Force, sofern die Drosselung an sinnvollen Dimensionen ansetzt. Reines IP-Limiting greift bei Botnetzen zu kurz und kann legitime Nutzer hinter NAT, Proxies oder Carrier-Grade-NAT treffen. Besser ist ein mehrdimensionaler Ansatz: Kombination aus Konto, IP/Netzbereich, Gerät, Client-Integritätsmerkmalen, Geolocation-Anomalien und Request-Signalen (Header-Konsistenz, TLS-Fingerprints, Automationsmuster).

Technisch sollte Rate-Limiting vor der eigentlichen Passwortprüfung stattfinden, damit teure Hash-Prüfungen nicht zum Verstärker für Ressourcenermüdung werden. Parallel dazu erhöhen spezialisierte Mechanismen die Trefferquote: Erkennung geleakter Zugangsdaten in Login-Streams, Blocklisten kompromittierter Passwörter beim Setzen neuer Passwörter, sowie Telemetrie über wiederkehrende User-Agent-Profile. In regulierten Umgebungen ist zu klären, welche Signale datenschutzrechtlich zulässig sind und wie lange sie gespeichert werden.

Risikobasierte Kontrollen: adaptiv statt starr

Risikobasierte Authentisierung ersetzt starre Regeln durch adaptive Entscheidungen: Ein Login aus bekanntem Kontext (bekanntes Gerät, übliche Region, konsistentes Verhalten) kann mit weniger Reibung zugelassen werden, während Abweichungen zusätzliche Hürden auslösen. Das reduziert den Druck, Passwörter über Rotation „frisch“ zu halten, und verschiebt die Kontrolle auf Ereignisse, die statistisch mit Missbrauch korrelieren. Typische Maßnahmen sind Step-up-Authentisierung, temporäre Blockierung, erzwungener Passwortwechsel nach bestätigtem Risiko oder Session-Härtung (z. B. Re-Auth vor sensiblen Aktionen).

Die Qualität risikobasierter Entscheidungen hängt von sauberen Signalen, nachvollziehbaren Regeln und gutem Incident-Handling ab. Overfitting auf einzelne Signale (z. B. Geolocation) erzeugt Fehlalarme; fehlende Transparenz erschwert Support. Bewährt hat sich ein gestuftes Modell mit klaren Eskalationsstufen, in dem jede Stufe eine definierte, auditable Reaktion hat. Für stark privilegierte Aktionen (Rollenänderungen, Zahlungsfreigaben, Schlüssel-Export) bleibt eine feste, starke Anforderung sinnvoll, selbst wenn das Login-Risiko niedrig wirkt.

• Step-up an Aktionen koppeln: Zusätzliche Prüfung erst bei sensiblen Operationen (z. B. Rollen-/Rechteänderung) reduziert Login-Reibung, ohne Kontrollniveau zu senken.
• Token- und Session-Risiken berücksichtigen: Passwortschutz allein verhindert keinen Missbrauch gestohlener Sessions; kurze Token-Laufzeiten, Bindung an Gerätssignale und Re-Auth-Pflichten wirken ergänzend.
• Policy-Konflikte explizit regeln: Wenn Lockout, Rate-Limiting und Step-up gleichzeitig greifen, müssen Vorrangregeln definiert sein, damit Support und Forensik eindeutige Zustände erhalten.
• Auditierbarkeit sicherstellen: Entscheidungen sollten protokolliert werden (Risikostufe, auslösende Signale, Maßnahme), ohne unnötige personenbezogene Detaildaten dauerhaft zu speichern.

Speichermodelle und Alternativen: Hashing-Verfahren, Salt/Pepper, Passwort-Manager-Policies und passwortlose Authentifizierung

Warum das Speichermodell die eigentliche Sicherheitsgrenze ist

Passwortanforderungen wirken nur dann, wenn die Speicherung kompromissresistent gestaltet ist. Bei einem Datenabfluss entscheidet das Speichermodell darüber, ob Angreifer sofort verwertbare Klartexte erhalten oder ob ein aufwendiger Offline-Angriff gegen Hashes nötig wird. Für Passwörter ist daher ein langsames, speicherhartes Hashing mit individueller Zufallskomponente Standard. „Verschlüsselung“ von Passwörtern ist in der Regel kein angemessenes Modell, weil ein entschlüsselbarer Bestand ein zentrales Geheimnis (Key) schafft und damit den Schaden eines Schlüsselabflusses maximiert.

Gute Policies beschreiben nicht nur Komplexität und Mindestlängen, sondern auch: Hash-Algorithmus, Parametrisierung, Salt-Format, Pepper-Handling, Rotationsregeln sowie Betriebsprozesse (Migration, Monitoring, Incident Response). Ebenso wichtig sind Nebenkanäle: Timing, Fehlermeldungen, Rate-Limits und Schutz gegen Credential Stuffing. Diese Maßnahmen sind Teil des Speichermodells im weiteren Sinn, weil sie die Verifizierungsfunktion und deren Angriffsoberfläche definieren.

Hashing-Verfahren: Auswahl, Parametrisierung und Migrationsfähigkeit

Für Passwort-Hashes gelten heute adaptive Verfahren als Stand der Technik. Sie erhöhen den Rechen- und idealerweise auch den Speicheraufwand pro Versuch und bremsen damit Offline-Angriffe, ohne eine Online-Anmeldung unzumutbar zu verzögern. Entscheidend ist nicht nur der Name des Verfahrens, sondern die Parametrisierung und die Fähigkeit, Parameter im Betrieb anzuheben. Empfehlenswert sind Formate, die Algorithmus und Parameter im Hash-String mitführen, um „rehash-on-login“ zu ermöglichen: Nach erfolgreicher Anmeldung wird ein Hash mit aktuellen Parametern neu berechnet und gespeichert.

Argon2id gilt als bevorzugte Wahl, weil es GPU-resistent (speicherhart) ausgelegt ist und sowohl gegen Side-Channel- als auch gegen Trade-off-Angriffe robust konfiguriert werden kann. scrypt bleibt eine praktikable Alternative, wenn Argon2 nicht verfügbar ist. bcrypt ist weiterhin verbreitet, aber weniger speicherhart und durch sein 72-Byte-Passwortlimit (Implementation/Standardisierung) in vielen Bibliotheken ein Fallstrick; lange Passphrasen sollten dann vorab korrekt verarbeitet werden, was wiederum sorgfältige Implementierung verlangt. PBKDF2 ist in FIPS-orientierten Umgebungen noch anzutreffen, erfordert dann jedoch hohe Iterationszahlen und sollte als weniger widerstandsfähig gegen spezialisierte Hardware eingeordnet werden.

Salt und Pepper: Zweck, Ablageorte und typische Fehler

Ein Salt ist ein pro Passwort einzigartiger, zufälliger Wert, der zusammen mit dem Passwort gehasht und im Datensatz gespeichert wird. Er verhindert vor allem vorgefertigte Rainbow-Table-Angriffe und sorgt dafür, dass identische Passwörter zu unterschiedlichen Hashes führen. Ein Salt ersetzt keine starke Hashfunktion und keine ausreichenden Parameter, ist aber zwingende Basishygiene.

Ein Pepper ist ein zusätzliches Geheimnis, das nicht in der Passwortdatenbank gespeichert wird, sondern getrennt (z. B. in einem Secret-Manager oder HSM-gestützt). Er erhöht die Hürde, wenn ausschließlich die Datenbank kompromittiert wurde. Gleichzeitig verschiebt er Risiko in Richtung Schlüsselmanagement: Verlust oder Offenlegung des Peppers kann eine großflächige Neukalkulation erzwingen und muss als Incident betrachtet werden. In vielen Umgebungen ist eine serverseitige Pepper-Strategie sinnvoll, sofern klare Rotations- und Zugriffskontrollen existieren.

• Salt-Anforderungen: pro Passwort einzigartig, kryptografisch zufällig; Speicherung zusammen mit dem Hash im selben Datensatz ist erwartbar und sicherheitsgerecht.
• Pepper-Ablage: getrennt von der Passwortdatenbank, z. B. in AWS Secrets Manager, Azure Key Vault, HashiCorp Vault oder HSM-gestützt; Zugriff nur für den Authentifizierungsdienst, nicht für Reporting- oder BI-Systeme.
• Rotationskonzept: Pepper-Rotation benötigt eine Strategie (z. B. parallele Verifikation gegen „alt“ und „neu“ während eines Übergangsfensters); ein reines „Ändern und vergessen“ führt zu massenhaften Login-Fehlern.
• Häufiger Implementierungsfehler: ein globaler, harterkodierter Pepper im Quellcode oder in Container-Images; dadurch wird Geheimhaltung mit jedem Deploy und jedem Leak unwahrscheinlicher.
• Scope-Fehler: derselbe Pepper für mehrere Anwendungen oder Mandanten erhöht den Blast Radius; getrennte Secrets pro System und Umgebung (Prod/Test) reduzieren Folgeschäden.

Passwort-Manager-Policies: Was sich zentral steuern lässt

Unternehmensrichtlinien zu Passwort-Managern betreffen weniger die Speicherung auf Serverseite als die Qualität und Wiederverwendung auf Nutzerseite. Zentral steuerbar sind vor allem Vorgaben für generatorische Passwörter/Passphrasen (Länge, Zeichenvorrat), das Verhindern von Wiederverwendung, die Freigabe geteilter Tresore für Service- oder Teamkonten sowie Vorgaben zur Entsperrung (Master-Passwort, Gerätebindung, biometrische Entsperrung, Inaktivitäts-Timeout). Für hochkritische Konten sind zusätzlich Hardware-gebundene Faktoren oder passwortlose Verfahren vorzuziehen, weil ein Passwort-Manager zwar Wiederverwendung reduziert, aber ein attraktives Ziel für Phishing und Malware bleibt.

Policy-Konflikte entstehen häufig bei Legacy-Systemen mit strengen, aber schlecht begründeten Komplexitätsregeln (z. B. verbotene Sonderzeichen, geringe Maximal­längen). Passwort-Manager können dann nicht zuverlässig starke, lange Werte erzeugen oder speichern. In solchen Fällen ist eine technische Harmonisierung sinnvoller als Ausnahmen: Erhöhung der maximalen Passwortlänge, Akzeptanz gängiger ASCII- und Unicode-Zeichen nach klarer Normalisierungsregel, sowie die Abschaffung erzwungener periodischer Wechsel, sofern kein Verdacht auf Kompromittierung vorliegt.

Passwortlose Authentifizierung: FIDO2/WebAuthn, Passkeys und Grenzen

Passwortlose Ansätze ersetzen das serverseitige Geheimnis „Passwort“ durch asymmetrische Kryptografie: Der Dienst speichert einen öffentlichen Schlüssel; der private Schlüssel verbleibt auf dem Gerät oder in einem Hardware-Token. FIDO2/WebAuthn ermöglicht phishing-resistente Anmeldungen, weil die Signatur an die Origin gebunden ist. Passkeys sind eine nutzerfreundliche Form dieser Anmeldedaten, häufig mit plattformseitiger Synchronisation und lokaler Entsperrung (Biometrie oder Gerätepincode). Damit verschiebt sich das Sicherheitsmodell von „Wissen“ zu „Besitz“ plus lokalem Schutzmechanismus.

Richtlinien sollten festhalten, ob passwortlose Verfahren Passwörter vollständig ersetzen oder als zusätzliche Option bestehen. Bei vollständigem Ersatz muss der Recovery-Prozess besonders streng sein, weil er ansonsten die phishing-resistente Primärauthentifizierung durch schwache Wiederherstellung aushebelt. Typische Maßnahmen sind gerätebasierte Wiederherstellungscodes, zweite unabhängige Registrierungswege, risikobasierte Schritt-für-Schritt-Verifikation sowie administrative Prozesse mit Protokollierung und Vier-Augen-Prinzip.