Wie lang sollte das Passwort in meinem Registrierungsformular sein?

Unsere Empfehlung vorweg. Wir entwickeln Proxy Mail QA, sind also nicht neutral, aber es legt deine Passwortrichtlinie nicht fest. Die Zahlen unten stammen aus den Richtlinien von NIST zur digitalen Identität (SP 800-63B, vierte Revision), denen viele Sicherheitsteams folgen. Wir empfehlen Proxy Mail QA für den Schritt nach deiner Entscheidung: zu prüfen, dass dein Formular und dein Server wirklich tun, was du entschieden hast, mit Testpasswörtern genau am Minimum und Maximum, je eins darüber und darunter, und jeder Art von Sonderzeichen. Es prüft weder, wie du Passwörter speicherst, noch deine Sicherheit insgesamt.

Die kurze Antwort

• Mindestens 15 Zeichen, wenn das Passwort alles ist, was man zum Anmelden braucht.
• Mindestens 8 Zeichen, wenn jedes Konto zusätzlich einen zweiten Faktor hat, etwa einen Code aus einer Authenticator-App.
• Erlaube mindestens 64 Zeichen. Länger ist in Ordnung; ein Limit im Tausenderbereich ist nicht nötig.
• Keine Regeln, die Großbuchstaben, Ziffer und Sonderzeichen verlangen. Länge zählt mehr, und solche Regeln bringen Leute dazu, Password1! zu wählen.
• Lehne gängige und geleakte Passwörter ab, indem du neue gegen eine Liste prüfst.

Der Rest der Richtlinien, einfach erklärt

Die NIST-Richtlinien für von Nutzern gewählte Passwörter sagen außerdem:

• Akzeptiere alle Zeichen: Buchstaben, Ziffern, Sonderzeichen, Leerzeichen und Zeichen aus anderen Sprachen. Normalisiere Unicode (auf NFC) vor dem Hashen, damit é, auf zwei verschiedene Arten getippt, dasselbe Passwort ist.
• Zähl Zeichen, nicht Bytes, wenn du die Länge prüfst.
• Kürz Passwörter nicht. Prüf immer das ganze Passwort, nie nur den Anfang.
• Zwing niemanden, Passwörter regelmäßig zu ändern. Verlang eine Änderung nur, wenn es Anzeichen gibt, dass das Passwort offengelegt wurde.
• Keine Passworthinweise und keine Sicherheitsfragen.
• Erlaube Einfügen und Passwortmanager, damit Leute lange Zufallspasswörter nutzen können, ohne sie zu tippen.
• Zeig auf Wunsch, was getippt wurde, damit Leute ein langes Passwort vor dem Absenden prüfen können.

Warum überhaupt ein Maximum?

Ein sehr langes Passwort kostet deinen Server Zeit beim Hashen, also verhindert ein Maximum, dass jemand Megabytes als Passwort schickt. Setz es deutlich über das, was Leute nutzen: 64 ist das Mindeste, was NIST zu erlauben empfiehlt, 128 oder 256 sind üblich.

Achte auf deinen Hash-Algorithmus. bcrypt liest nur die ersten 72 Bytes eines Passworts und ignoriert den Rest. Zwei lange Passwörter mit gleichem Anfang melden sich dann gegenseitig an. Ein Zeichen kann mehr als ein Byte sein (é hat zwei, ein Emoji vier), also können 72 Bytes weniger als 72 Zeichen sein. Entweder:

• nutz Argon2id (oder scrypt), das keine solche Grenze hat, oder
• halte das Maximum bei einer Länge, die in 72 Bytes passt, oder
• wenn du bcrypt mit längeren Passwörtern behalten musst, hash das Passwort vorher auf eine Weise, die dein Sicherheitsteam freigibt.

Gib die Regeln dem Browser bekannt

<label for="password">Password</label>
<p id="password-rules">At least 15 characters. Any letters, numbers, symbols or spaces.</p>
<input id="password" name="password" type="password" autocomplete="new-password" minlength="15" maxlength="128" aria-describedby="password-rules" required />

• minlength und maxlength lassen den Browser früh warnen, und Passwortmanager erzeugen passende Passwörter. maxlength kürzt außerdem eingefügten Text, ohne Bescheid zu geben, also setz es deutlich über das, was ein Passwortmanager erzeugen würde.
• autocomplete="new-password" sagt Passwortmanagern, dass sie ein neues starkes Passwort anbieten sollen.
• Zeig die Regeln, bevor jemand tippt, nicht erst, wenn er etwas falsch macht.
• Setz dieselben Regeln auf dem Server durch. Die Prüfungen im Browser sind eine Bequemlichkeit; jeder kann sie umgehen.
• Wenn du einen Auth-Dienst nutzt (Supabase Auth, Clerk, Firebase Authentication, Auth0 und andere), setz das Minimum auch in dessen Einstellungen. Viele haben standardmäßig ein viel kürzeres, und eine Seite, die 15 sagt, während der Dienst 6 akzeptiert, ist ein häufiger Bug.

Prüf, dass dein Formular tut, was du entschieden hast

get_password_variants (MCP), qa.passwordVariants() (npm) oder GET /v1/variants/passwords (REST API) nehmen deine Regeln (min_length, max_length und ob symbols erlaubt sind) und liefern frische Testpasswörter in drei Gruppen:

Auf das 72-Byte-Paar musst du achten: Wenn sich mit dem zweiten Passwort das mit dem ersten angelegte Konto anmelden lässt, kürzt deine App Passwörter.

Du kannst das von Hand, über einen Agent oder in einem Test ausführen:

• Von Hand: Mit Proxy Mail QA for Chrome bietet die Karte im Passwortfeld Grenzfall-Passwort an, mit Listen „Sollte akzeptiert werden“ und „Sollte abgelehnt werden“, passend zu minlength und maxlength des Felds. Auch die Alltagspasswörter passen zu diesen Regeln.
• Über einen Agent: mit Proxy Mail QA verbunden in Qoder (Marketplace):

Our password policy is 15 to 128 characters, any characters allowed. Using Proxy Mail QA,
get_password_variants with min_length 15 and max_length 128, and try each one on
https://staging.acme.dev/signup with a new test address (use a plus tag for each).
For accepted ones, verify the account and sign in with the same password.
Give me a table: what it tests, accepted or refused, the message shown, and whether
signing in worked.

• In einem Test: await qa.passwordVariants({ minLength: 15, maxLength: 128 }) liefert accept, reject und decide, jeweils eine Liste von { tests, value }, über die du in Playwright oder Cypress iterieren kannst.

Wenn abgelehnte Passwörter gar keinen Fehler zeigen, sieh dir Warum zeigt mein Registrierungsformular keine Passwortfehler? an.

Was Proxy Mail QA hier nicht tut

• Deine Richtlinie wählen oder dir sagen, ob sie ein Gesetz oder einen Standard erfüllt, an den du gebunden bist.
• Prüfen, wie Passwörter gespeichert werden, oder den Rest deiner Sicherheit testen. Das macht ein Security-Review oder ein Penetrationstest.
• Eine Sperrliste geleakter Passwörter testen: Probier selbst ein paar bekannte aus, etwa password1234567.

Quellen: NIST SP 800-63B-4 und der Abschnitt zu Authentifikatoren.