Ein Passwort-Reset ist ein Login, das das Passwort überspringt. Jede Schutzmaßnahme des Login-Formulars muss hier daher nachgebildet oder bewusst ersetzt werden. Ist der Reset-Pfad schwächer als der Login-Pfad, wird ein Angreifer ihn nutzen. Das OWASP Forgot Password Cheat Sheet nennt diese Funktion „eine häufige Quelle für Schwachstellen“, mit User Enumeration als bekanntestem Beispiel.
Warum der Reset-Ablauf die Schwachstelle ist
Ein erfolgreiches Login erzeugt eine Session. Laut den OWASP-Hinweisen zum Session Management ist eine Session-ID eines authentifizierten Nutzers vorübergehend gleichwertig mit der stärksten Authentifizierungsmethode, die die Anwendung verwendet hat. Ein Reset, der in einer Session endet oder in einem vom Angreifer gewählten Passwort, liefert genau dasselbe aus.
NIST SP 800-63B-4 verlangt bei AAL2 den Nachweis von Besitz und Kontrolle über zwei unterschiedliche Authentifizierungsfaktoren. Fragt das Login zwei Faktoren ab, ist ein Reset mit einem einzigen per E-Mail versandten Token ein Single-Factor-Umweg daran vorbei. Der Auszug, auf den wir uns stützen, behandelt Recovery nicht; das vollständige Dokument enthält einen Abschnitt zum Authenticator-Event-Management.
Unsere eigene Regel: Bei einem Konto mit eingerichtetem zweitem Faktor fordern Sie diesen Faktor oder einen gespeicherten Recovery-Code an, bevor das neue Passwort akzeptiert wird. Ein Reset darf den Faktor niemals entfernen oder ersetzen.
Der Anfrageschritt
Antworten Sie identisch, unabhängig davon, ob das Konto existiert. „Falls diese Adresse registriert ist, haben wir eine E-Mail gesendet“ genügt.
Auch das Zeitverhalten verrät etwas. Ein Handler, der bei unbekannten Adressen früh abbricht und bei bekannten eine E-Mail versendet, zeigt den Unterschied, egal was die Meldung sagt. Führen Sie für jede Anfrage dieselbe Logik aus oder übergeben Sie den Mailversand an einen asynchronen Job.
Setzen Sie ein Rate-Limiting pro Konto, ein CAPTCHA oder eine ähnliche Maßnahme ein. Ohne eine solche Kontrolle kann ein Angreifer pro Stunde tausende Reset-Anfragen auf ein Konto abfeuern und das Postfach oder die SMS des Opfers fluten. Sperren oder verändern Sie das Konto nicht aufgrund einer Anfrage.
Das Token
OWASP stellt vier Anforderungen an ein Token oder einen Code:
- Es wird mit einem kryptografisch sicheren Zufallsalgorithmus erzeugt.
- Es ist lang genug, um Brute-Force-Angriffe zu verhindern.
- Es wird sicher gespeichert.
- Es ist nur einmal verwendbar und läuft nach angemessener Zeit ab.
Das Cheat Sheet nennt keine Zahlen für Länge oder Lebensdauer. Der nächstliegende Wert in den Quellen steht in den Hinweisen zum Session Management: ein CSPRNG mit mindestens 128 Bit Entropie, bevorzugt 160 Bit oder mehr. Er ist für Session-Token formuliert; wir wenden ihn auf Reset-Token an. Wählen Sie für die Lebensdauer einen kurzen Wert, dokumentieren Sie ihn und testen Sie dagegen.
„Sicher gespeichert“ lässt sich streng auslegen. Gehört das rein lesende Offenlegen des Token-Speichers zu Ihrem Bedrohungsmodell, beschreiben die Hinweise zum Session Management eine Aufteilung in Identifier und geheimen Verifier. Der Server speichert den öffentlichen Identifier zum Nachschlagen und den vollständigen SHA-256-Hash des Verifiers und vergleicht Hashes in konstanter Zeit. Der Identifier allein darf nie als Nachweis gelten. Die Übertragung auf Reset-Token ist unser Vorschlag.
Übermitteln Sie das Token über einen separaten Kanal, per E-Mail oder SMS, und niemals in der Antwort an den Browser. Ein Token in der URL ist das einfachste Design, doch die Hinweise zum Session Management warnen, dass IDs in URLs über Links und Logs, Browser-Verlauf und Lesezeichen, den Referer-Header und Suchmaschinen abfließen können. Wenn Sie Inhalte von Drittanbietern und ausgehende Links von der Reset-Seite fernhalten, schließen Sie nur das Referer-Leck. Für den Rest tauschen Sie das Token beim ersten Aufruf gegen kurzlebigen serverseitigen Zustand, leiten auf eine saubere URL weiter und halten diesen ersten Query-String aus den Access-Logs heraus.
Der Reset-Schritt
- Lassen Sie die Nutzer das neue Passwort zweimal eingeben und prüfen Sie es gegen dieselbe Richtlinie wie bei der Registrierung.
- Hashen Sie es über denselben Codepfad wie jedes andere Passwort.
- Entwerten Sie alle offenen Reset-Token des Kontos, sobald sich Passwort oder E-Mail-Adresse ändern. Sonst kann eine ältere E-Mail, die noch im Postfach liegt, das Konto erneut zurücksetzen.
- Senden Sie dem Nutzer eine E-Mail, dass sich das Passwort geändert hat. Das Passwort selbst gehört nie in die Nachricht.
- Leiten Sie den Nutzer zum normalen Login, statt ihn automatisch anzumelden. Ein automatisches Login bringt zusätzlichen Session-Handling-Code mit sich und damit die Gefahr neuer Schwachstellen.
- Beenden Sie bestehende Sessions oder bieten Sie zumindest an, sie zu beenden.
Nach einer vermuteten Kompromittierung überlebt die aktive Session des Angreifers eine Passwortänderung, sofern Sie sie nicht beenden. Wir würden die Invalidierung zum Standard machen.
MFA und kompromittierte Konten
Ein Passwort-Reset allein stellt die Kontrolle über ein Konto möglicherweise nicht wieder her. Der Angreifer kann noch eine aktive Session besitzen oder Recovery-Angaben bzw. MFA-Methoden geändert haben.
OWASP rät, sich nicht allein auf kürzlich hinzugefügte oder geänderte Recovery-Angaben zu verlassen. Nutzen Sie unabhängige Nachweise, die früher etabliert wurden, etwa gespeicherte Recovery-Codes, in einer Kombination, die den Sicherheitsanforderungen des Kontos genügt. Das Zurücksetzen von MFA hat im OWASP Multifactor Authentication Cheat Sheet einen eigenen Abschnitt; halten Sie diesen Prozess daher getrennt vom Passwort-Ablauf.
Das OWASP Authentication Cheat Sheet behandelt außerdem die Änderung einer registrierten E-Mail-Adresse. Das ist wichtig, weil eine geänderte Adresse jeden künftigen Reset umleitet.
Den Ablauf testen
| Test | So sieht ein bestandener Test aus |
|---|---|
| Existierende und nicht existierende Adresse | Gleiche Meldung und gleicher Statuscode |
| Skriptgesteuerte Reihe von Anfragen pro Adresse | Mediane der Antwortzeiten stimmen überein |
| Wiederholte Anfragen für ein Konto | Rate-Limit oder CAPTCHA greift |
| Reset anfordern, dann einloggen | Konto nicht gesperrt oder verändert |
| Token zweimal oder nach Ablauf verwendet | Versuch scheitert |
| Altes Token nach Passwort- oder E-Mail-Änderung | Versuch scheitert |
| Reset-Seite mit dem Token in der URL | Keine Drittanbieter-Anfragen oder ausgehenden Links |
| Reset bei geöffneter alter Session | Alte Session beendet |
| Eingerichteter zweiter Faktor, nur E-Mail-Token (unsere Regel) | Reset abgelehnt |
| Abschließende Antwort und die E-Mail | Kein automatisches Login, kein Passwort in der E-Mail |
Vergleichen Sie bei der Zeile zum Zeitverhalten Mediane und Streuung über viele Durchläufe. Das gehört in jeden Penetrationstest eines Authentifizierungsablaufs.
Wo Sie anfangen
- Fordern Sie für ein existierendes und ein nicht existierendes Konto jeweils viele Resets an. Vergleichen Sie Meldung, Statuscode und Antwortzeit.
- Lesen Sie den Token-Generator. Bestätigen Sie, dass er einen CSPRNG verwendet, machen Sie Token zur einmaligen Verwendung und legen Sie eine Lebensdauer fest, die Sie in Minuten angeben können.
- Ergänzen Sie am Anfrage-Endpunkt ein Rate-Limiting pro Konto oder ein CAPTCHA und stellen Sie sicher, dass eine Anfrage das Konto nie sperrt oder verändert.
- Sorgen Sie dafür, dass der Reset andere Sessions beendet, offene Token entwertet und eine Benachrichtigungs-E-Mail ohne Passwort versendet. Prüfen Sie, dass die Reset-Seite nichts von Drittanbietern lädt.
- Nehmen Sie ein Testkonto mit eingerichtetem MFA und versuchen Sie, es nur mit dem per E-Mail versandten Token zurückzusetzen. Bestätigen Sie, dass der Reset abgelehnt wird.
- Prüfen Sie, wer einen zweiten Faktor zurücksetzen oder entfernen darf, welche Nachweise dafür erforderlich sind und ob die Recovery kürzlich geänderte Angaben als nicht vertrauenswürdig behandelt.
