Passwort-Reset-Links sind Zugangsdaten auf Zeit: Wo Tokens unbemerkt leaken

Ein Passwort-Reset beginnt oft harmlos: E-Mail-Adresse eingeben, Nachricht erhalten, Link anklicken, neues Passwort setzen. Technisch ist dieser Link aber für kurze Zeit ein Zugangsschlüssel. Wer den Token besitzt und ihn rechtzeitig einlösen kann, bekommt in vielen Systemen genau die Berechtigung, die der legitime Nutzer gerade braucht.

Deshalb reicht die Frage „Ist der Reset-Link zufällig genug?“ nicht aus. Ein guter Audit betrachtet den gesamten Weg des Tokens: wie er erzeugt wird, wo er auftaucht, welche Systeme ihn sehen, wie lange er gültig bleibt und was nach der Einlösung passiert.

Red Flag: Der Token erreicht mehr Systeme als gedacht

Ein typischer Reset-Link sieht sinngemäß wie https://example.de/reset?token=... aus. Schon damit existiert das Geheimnis in einer URL.

Das ist relevant, weil URLs an vielen Stellen verarbeitet werden können: Webserver und Reverse Proxies führen Request-Logs, Monitoring- und Error-Tracking-Systeme erfassen Request-Metadaten, Browser speichern Verlaufseinträge, und nachgeladene Ressourcen oder Navigationen können Referrer-Informationen erzeugen. RFC 9110 weist ausdrücklich darauf hin, dass URIs häufig angezeigt, geloggt oder an Stellen gespeichert werden, die nicht als Geheimnisspeicher gedacht sind.

Das bedeutet nicht, dass URL-Tokens grundsätzlich falsch sind. OWASP beschreibt sie ausdrücklich als praktikablen Ansatz für Passwort-Resets. Die Konsequenz ist vielmehr: Der Token muss wie ein kurzlebiges Credential behandelt werden und seine Angriffsfläche muss bewusst klein bleiben.

1. Ist der Token wirklich nur einmal verwendbar?

Ein Reset-Token sollte nicht zu einem zweiten Passwort werden.

Prüfen sollte man mindestens:

• Wird der Token kryptografisch sicher und mit ausreichender Entropie erzeugt?
• Ist er an genau ein Konto und genau einen Recovery-Zweck gebunden?
• Hat er eine kurze, definierte Lebensdauer?
• Wird er nach erfolgreicher Nutzung sofort ungültig?
• Werden ältere Reset-Tokens ungültig, wenn ein neuer angefordert wird?
• Wird der gespeicherte Token oder dessen Verifikationswert so behandelt, dass ein Datenbank-Leak nicht direkt alle offenen Reset-Links verwertbar macht?
• Gibt es Rate Limits für Anforderung und Einlösung?

OWASP empfiehlt für Reset-Tokens unter anderem sichere Zufälligkeit, ausreichende Länge, sichere Speicherung, Einmalnutzung und Ablaufzeiten. Das ist die Basis – nicht der komplette Recovery-Flow.

2. Was passiert auf der Seite, auf der der Token landet?

Die kritischste Seite ist häufig nicht das Formular „Passwort vergessen“, sondern die Redemption-Seite nach dem Klick aus der E-Mail.

Dort sollte möglichst wenig passieren, bevor der Token in einen eng begrenzten Recovery-Zustand überführt wurde. Ein guter technischer Entwurf vermeidet unnötige Drittanbieter-Skripte, Marketing-Tags, Chat-Widgets, A/B-Testing und andere Ressourcen, die für den Reset nicht erforderlich sind.

OWASP empfiehlt für Reset-Seiten explizit eine passende Referrer-Policy und rät im Web Security Testing Guide dazu, Drittanbieter-Ressourcen auf solchen Seiten zu vermeiden. Eine robuste Variante ist Referrer-Policy: no-referrer, damit die sensible URL nicht als Referrer an nachfolgende Requests oder Navigationen weitergereicht wird.

Wichtig: Auf Browser-Defaults sollte man sich bei einer Credential-Seite nicht verlassen. Die Sicherheitsanforderung sollte im Response selbst sichtbar und testbar sein.

3. Bleibt der Token nach der Prüfung in der Adresszeile?

Ein nützliches Muster ist, den einmaligen URL-Token nur für die erste Verifikation zu verwenden. Nach erfolgreicher Prüfung kann der Server daraus eine stark eingeschränkte, kurzlebige Recovery-Session erzeugen und anschließend auf eine saubere URL ohne Token weiterleiten.

So reduziert man die Zeit, in der das Credential in Verlauf, Screenshots, kopierten Links, Support-Tickets oder späteren Requests auftauchen kann.

Die Recovery-Session sollte nicht plötzlich Zugriff auf das normale Konto erhalten. Sie braucht nur die Berechtigung, den vorgesehenen Recovery-Schritt auszuführen.

4. Wird die Reset-URL aus einem vertrauenswürdigen Host erzeugt?

Ein überraschend klassischer Fehler entsteht schon beim Versand der E-Mail: Die Anwendung baut den Reset-Link dynamisch aus dem eingehenden Host-Header zusammen.

OWASP warnt davor, sich bei Reset-URLs auf einen untrusted Host-Header zu verlassen. Die Ziel-Domain sollte fest konfiguriert oder gegen eine definierte Allowlist validiert werden. Sonst kann ein Angreifer unter ungünstigen Bedingungen versuchen, einen legitimen Token in einen Link mit fremder Domain einzubauen.

Das ist ein gutes Beispiel dafür, warum Security-Audits nicht nur den sichtbaren Browser-Screen prüfen sollten. Der entscheidende Fehler kann im Zusammenspiel zwischen Proxy, Backend-Konfiguration und E-Mail-Template liegen.

5. Verrät die Anforderungsseite, welche Konten existieren?

Auch vor dem eigentlichen Token gibt es eine wichtige Grenze: Das „Passwort vergessen“-Formular sollte nicht unnötig bestätigen, ob eine bestimmte E-Mail-Adresse registriert ist.

Unterschiedliche Fehlermeldungen, deutlich unterschiedliche Antwortzeiten oder abweichende Statuspfade können Account-Enumeration ermöglichen. Gleichzeitig darf der Schutz davor nicht dazu führen, dass reale Nutzer einen unverständlichen Recovery-Prozess bekommen.

Praktisch heißt das: gleichartige Antworten, kontrollierte Laufzeiten und Rate Limits – und intern trotzdem sauberes Monitoring für Missbrauch und Zustellprobleme.

6. Was passiert mit bestehenden Sessions nach dem Reset?

Ein erfolgreich geändertes Passwort löst nicht automatisch das Problem, wenn ein kompromittierter Browser oder ein gestohlenes Session-Cookie weiterhin gültig bleibt.

OWASP empfiehlt, bestehende Sessions nach einem Passwort-Reset entweder zu invalidieren oder dem Nutzer eine klare Möglichkeit dazu zu geben. Für besonders sensible Anwendungen ist eine serverseitige Invalidierung aller alten Sessions häufig die verständlichere Sicherheitsgrenze.

Dabei sollte die Anwendung außerdem nachvollziehbar kommunizieren, dass das Passwort geändert wurde, ohne jemals das neue Passwort selbst per E-Mail zu versenden.

7. Und was ist mit Magic Links?

Passwortlose Login-Links haben ein ähnliches Grundproblem: Der Link selbst trägt für kurze Zeit Authentifizierungswert.

Deshalb sind viele derselben Prüfungen relevant: starke zufällige Tokens, kurze Lebensdauer, Einmalnutzung, HTTPS, vertrauenswürdige Link-Domain, begrenzte Versuche, möglichst geringe Drittanbieter-Oberfläche und ein sauberer Übergang in eine normale Session.

Der Unterschied liegt im Zweck: Ein Passwort-Reset darf nur Recovery ermöglichen; ein Login-Link erzeugt eine authentifizierte Sitzung. Genau deshalb sollte die Berechtigung des Tokens im Backend explizit an seinen Zweck gebunden sein, statt einen generischen „gültigen Token“ für mehrere Flows wiederzuverwenden.

Ein praktischer Audit in zehn Minuten

Wer einen Testaccount zur Verfügung hat, kann bereits viel beobachten:

1. Reset anfordern und prüfen, ob die Antwort die Existenz des Kontos verrät.
2. Den Link öffnen und die vollständige URL sowie Redirect-Kette dokumentieren.
3. Response-Header der Redemption-Seite prüfen, insbesondere Referrer-Policy und Cache-Verhalten.
4. Im Network-Panel kontrollieren, welche Drittanbieter vor und nach der Token-Verifikation geladen werden.
5. Den Token einmal verwenden und anschließend erneut aufrufen.
6. Einen zweiten Reset anfordern und testen, ob ein älterer Token noch funktioniert.
7. Prüfen, ob die Token-URL nach erfolgreicher Verifikation aus der Adresszeile verschwindet.
8. Nach dem Passwortwechsel eine alte Session in einem zweiten Browser testen.
9. Request- und Application-Logs stichprobenartig darauf prüfen, ob komplette Token-URLs gespeichert werden.
10. Den Flow auch über fehlerhafte, abgelaufene und mehrfach verwendete Tokens testen.

Ein produktiver Test sollte selbstverständlich nur mit eigenen Testkonten und in einem autorisierten System stattfinden.

Was Website-Pflichtencheck hier prüfen würde

Bei einem Recovery-Audit betrachten wir nicht nur das Formular. Interessant ist die gesamte Kette aus Frontend, Headern, Redirects, Drittanbieter-Requests und Session-Verhalten. Mit Testzugang oder Staging können zusätzlich Einmalnutzung, Ablauf, Token-Rotation und Session-Invalidierung überprüft werden.

Das Ziel ist kein möglichst komplizierter Auth-Flow. Im Gegenteil: Ein sicherer Recovery-Prozess ist eng begrenzt, vorhersehbar und lässt möglichst wenige Systeme mit dem temporären Credential in Berührung kommen.

Wenn Ihr Reset-Flow seit Jahren „einfach funktioniert“, ist genau das ein guter Anlass für einen kontrollierten Test. Recovery wird selten täglich benutzt – und gerade deshalb fallen alte Annahmen, vergessene Tracking-Skripte oder historisch gewachsene Redirects im normalen Betrieb kaum auf.