Funktioniert Ihr Passwort-Reset wirklich – oder nur im Test?

Ein Nutzer kennt sein Passwort nicht mehr. Das klingt nach einem kleinen Supportfall.

Für einen Shop, ein Kundenportal oder ein SaaS-Produkt kann genau dieser Moment aber entscheiden, ob die Person zurückkehrt, beim Support landet oder einfach zur Konkurrenz geht. Gleichzeitig gehört der Passwort-Reset zu den sensibelsten öffentlichen Funktionen einer Anwendung: Er muss einem legitimen Nutzer Zugang zurückgeben, ohne Angreifern zu verraten, welche Konten existieren oder ihnen einen zweiten Weg ins Konto zu öffnen.

Das Problem ist selten, dass es gar keinen Reset-Link gibt. Das Problem ist, dass niemand den gesamten Ablauf regelmäßig wie ein echter Nutzer prüft.

Der Reset funktioniert – bis man ihn wirklich braucht

Typische Tests enden zu früh:

• Das Formular nimmt eine E-Mail-Adresse an.
• Der API-Endpunkt antwortet mit 200.
• Im lokalen Mail-Tool erscheint eine Nachricht.
• Ein Entwickler hat den Flow irgendwann erfolgreich ausprobiert.

Das beweist noch nicht, dass ein realer Nutzer sein Konto wiederherstellen kann. In Produktion können andere Dinge scheitern: Die Reset-Mail landet im Spam, der Link enthält die falsche Domain, ein Proxy beschädigt den Token, der Token ist vor Zustellung abgelaufen oder die Erfolgsseite behauptet, alles sei erledigt, obwohl der Backend-Schritt fehlgeschlagen ist.

Ein Monitoring, das nur die Erreichbarkeit der Login-Seite prüft, sieht davon nichts.

Sicherheitsfunktion und Conversion-Strecke zugleich

OWASP empfiehlt für Passwort-Reset-Flows unter anderem einheitliche Antworten für existierende und nicht existierende Konten, zeitlich begrenzte und einmalig nutzbare Tokens sowie Schutz vor automatisierten Massenanfragen. Diese Maßnahmen reduzieren Account Enumeration, Brute Force und E-Mail-Flooding.

Aus Produktsicht kommt eine zweite Ebene hinzu: Der Ablauf muss verständlich, zustellbar und auf Mobilgeräten nutzbar sein.

Ein sicherer Reset, den echte Nutzer nicht abschließen können, erzeugt Supportkosten und Abbrüche. Ein bequemer Reset ohne saubere Token- und Sitzungslogik wird zum Sicherheitsrisiko. Beides muss gemeinsam geprüft werden.

Sieben Red Flags, die Sie selbst testen können

1. Unterschiedliche Antworten verraten bestehende Konten

Gibt das Formular bei einer unbekannten Adresse sofort „Kein Konto gefunden“ aus, können Dritte gültige Nutzeradressen sammeln. Besser ist eine konsistente Meldung wie: „Wenn ein Konto zu dieser Adresse existiert, wurde eine Nachricht versendet.“ Auch deutlich unterschiedliche Antwortzeiten können Informationen verraten.

2. Reset-Mails sind technisch korrekt, aber praktisch unzustellbar

Testen Sie nicht nur mit Ihrer Firmenadresse. Prüfen Sie mehrere große Mailanbieter, mobile Clients und Weiterleitungen. Kontrollieren Sie SPF, DKIM und DMARC, den sichtbaren Absender, die Linkdomain und die Klarheit des Inhalts. Eine E-Mail im Serverlog ist noch keine zugestellte E-Mail.

3. Tokens sind zu lange gültig oder mehrfach verwendbar

Reset-Tokens sollten zufällig, ausreichend stark, sicher gespeichert, an ein Konto gebunden, zeitlich begrenzt und nach Nutzung ungültig sein. Prüfen Sie bewusst denselben Link zweimal, einen abgelaufenen Link, einen manipulierten Token, mehrere nacheinander angeforderte Links und einen Link nach erfolgreicher Passwortänderung.

4. Bestehende Sitzungen werden ignoriert

Nach einer Passwortänderung sollte klar entschieden sein, was mit aktiven Sitzungen passiert. OWASP empfiehlt, Nutzer über die Änderung zu informieren und bestehende Sitzungen entweder zu invalidieren oder ihnen eine verständliche Wahl anzubieten. Ein neues Passwort hilft wenig, wenn ein Angreifer mit einer alten Sitzung weiter angemeldet bleibt.

5. Das Formular kämpft gegen Passwortmanager

Browser und Passwortmanager können nur helfen, wenn Felder korrekt ausgezeichnet sind. MDN dokumentiert unter anderem autocomplete="new-password" für neue Passwörter und autocomplete="one-time-code" für Einmalcodes. Fehlende oder falsche Attribute führen zu irritierenden Autofill-Effekten und erhöhten Abbruchraten – gerade mobil.

6. MFA-Wiederherstellung wurde nie mitgedacht

Wer sein Passwort vergessen hat, kann zusätzlich den zweiten Faktor verloren haben. Passwort-Reset und vollständige Account-Recovery sind deshalb nicht immer dasselbe. NIST beschreibt Account-Recovery als eigenen, risikobasierten Prozess und nennt beispielsweise Recovery Codes, Recovery Contacts oder erneute Identitätsprüfung. Ein improvisierter Support-Override ohne dokumentierten Ablauf ist keine belastbare Lösung.

7. Niemand bemerkt, wenn der Flow nach einem Release bricht

Änderungen an Routing, E-Mail-Templates, Auth-Providern, Domains, Cookies oder Session-Handling können den Reset unbemerkt beschädigen. Deshalb gehört mindestens ein regelmäßiger synthetischer Test in den Betrieb: Testkonto anfordern, Nachricht empfangen, Reset-Link öffnen, neues Passwort setzen, anmelden, Token-Wiederverwendung ablehnen und das gewünschte Session-Verhalten prüfen.

Was ein belastbarer Audit betrachtet

Ein Website-Pflichtencheck würde nicht nur auf die sichtbare Formularseite schauen. Relevant sind unter anderem einheitliche Antworten, Rate Limits, Token-Erzeugung und -Ablauf, Redirects und Produktionsdomains, E-Mail-Zustellbarkeit, mobile Bedienbarkeit, Passwortmanager-Kompatibilität, Session-Invalidierung, MFA-Recovery, sichere Logs und automatisierte End-to-End-Tests.

Der wichtigste Test ist simpel: Kann eine echte Person ihr Konto heute sicher zurückbekommen, ohne Hilfe eines Entwicklers?

Wenn diese Antwort nur auf Annahmen beruht, ist der Reset-Flow kein fertiges Feature, sondern ein stilles Betriebsrisiko. Eine gezielte Prüfung kostet deutlich weniger als eine Welle gesperrter Nutzer oder ein Recovery-Prozess, der erst während eines Sicherheitsvorfalls entworfen wird.