Login-E-Mail ändern: Profilkorrektur oder eigener Sicherheitsablauf?

Die Änderung einer registrierten Login-E-Mail sollte ein eigener Sicherheitsablauf sein, nicht die gewöhnliche Bearbeitung eines Kontaktfelds. Legen Sie fest, wie die Person ihre Berechtigung nachweist, wie die neue Adresse bestätigt wird, welche Nachricht an die bisherige Adresse geht und wann die Änderung wirksam wird. Eine beantragte Änderung darf in der Oberfläche nicht wie eine abgeschlossene aussehen.

Hier geht es um angemeldete Kunden, die ihre registrierte Adresse ändern möchten. Vergessene Passwörter, verlorene zweite Faktoren und die Wiederherstellung nach Verlust des Postfachzugangs brauchen getrennte Verfahren. Dieser Artikel ist weder eine vollständige Sicherheitsspezifikation noch eine Garantie gegen Angriffe.

Welche E-Mail-Adresse wird überhaupt geändert?

Ein Portal kann eine Login-Adresse, einen Rechnungsempfänger und eine Kontaktadresse im Kundendatensatz haben. Entscheiden Sie vor der Gestaltung des Formulars, ob das bewusst getrennte Angaben sind oder tatsächlich dasselbe Feld. Halten Sie fest, welche davon die Funktion verändert.

Ein erfundenes Beispiel: Ein Kunde möchte Rechnungen an die Buchhaltung senden lassen, ohne ihr die Kontrolle über sein Login zu geben. Das ist zunächst eine Zustellungspräferenz, nicht zwingend eine Änderung der Kontoidentität. Verknüpfen Sie beides nicht allein deshalb, weil im ersten Datenmodell nur eine Spalte vorgesehen war.

Liegt die Anmeldung bei einem externen Identitätsanbieter, fragen Sie nach der maßgeblichen Datenquelle. Welche Adresse verwaltet der Anbieter, und welche Änderung kann das Portal selbst ausführen? Eine lokale Profilkorrektur darf nicht als Änderung einer extern verwalteten Identität versprochen werden.

Zunächst vormerken, nicht sofort überschreiben

Das OWASP Authentication Cheat Sheet empfiehlt, die Gültigkeit des Authentifizierungs-Cookies oder Tokens zu prüfen, den Ablauf zu erklären, eine regelkonforme neue Adresse entgegenzunehmen und sie als ausstehende Änderung zu speichern. Identitätsprüfung und Nachrichten unterscheiden sich dabei je nachdem, ob eine Mehrfaktor-Authentifizierung aktiviert ist.

Für das Briefing heißt das: Zeigen Sie die aktuelle registrierte Adresse und den vorgeschlagenen Ersatz getrennt an. Erklären Sie, was noch fehlt. „Bestätigung angefordert“ darf nicht wie „Login-Adresse geändert“ aussehen. Vereinbaren Sie, welche Adresse während der Wartezeit zur Anmeldung dient, und lassen Sie das vorführen. Dieser Artikel unterstellt kein bestimmtes Produktverhalten.

Klären Sie außerdem einen zweiten Änderungsantrag, der eingeht, bevor der erste abgeschlossen ist. Eine mögliche Regel ist, den ersten Antrag abzulösen und verständlich darauf hinzuweisen, dass nur der jüngste abgeschlossen werden kann. Das ist ein Gestaltungsvorschlag, keine hier behauptete OWASP-Pflicht.

Die beiden Bestätigungswege nicht vermischen

Für Konten mit aktivierter Mehrfaktor-Authentifizierung empfiehlt OWASP eine Identitätsprüfung per MFA. Die bisherige Adresse erhält eine Benachrichtigung, die neue Adresse eine Bestätigungsaufforderung. Die Nachricht an die bisherige Adresse enthält eine Möglichkeit, unerwartete Aktivitäten zu melden.

Für Konten ohne MFA empfiehlt OWASP die Abfrage des aktuellen Passworts und getrennte Bestätigungen an der bisherigen sowie der neuen Adresse. In diesem Zweig ist die Nachricht an die alte Adresse also nicht nur ein Hinweis.

Das sind Sicherheitsempfehlungen von OWASP, keine Rechtsvorschriften und kein Beleg dafür, dass jeder Anbieter so arbeitet. Lassen Sie den vorgesehenen Ablauf dokumentieren und Abweichungen begründen. Die Meldungen für Kunden sollen erklären, welche Schritte für ihr Konto gelten, ohne sensible Implementierungsdetails offenzulegen.

Der Abschnitt empfiehlt zeitlich begrenzte Nonces, also Prüfwerte für den Ablauf. Verlangen Sie eine dokumentierte und getestete Gültigkeitsdauer der Bestätigungslinks. Eine allgemeingültige Minutenzahl lässt sich daraus nicht ableiten.

Auch unvollständige Anträge brauchen einen Abschluss

Was passiert bei einer vertippten neuen Adresse, einer nicht angekommenen Nachricht, einem abgelaufenen Link oder einem zurückgezogenen Änderungswunsch? Eine ausstehende Änderung braucht einen erkennbaren Status und einen vereinbarten Weg zum Abbrechen oder erneuten Anfordern. Abgelaufene oder abgelöste Links dürfen die Adresse nicht später unbemerkt ändern.

Für Meldungen über unerwartete Änderungen muss jemand zuständig sein. Legen Sie fest, wo die Meldung landet, welche Rückmeldung der Kunde bekommt und wie Mitarbeitende reagieren, ohne nach Passwörtern oder Bestätigungslinks zu fragen. Ein Link in einer Warnmail ersetzt keinen betreuten Supportprozess.

Kann der Kunde das bisherige Postfach nicht mehr öffnen, sollte der Support nicht einfach dessen Bestätigung als erledigt markieren. Dafür braucht es ein gesondert freigegebenes Wiederherstellungsverfahren. OWASP weist auch darauf hin, dass Supportmitarbeitende die vorgeschriebenen Prozesse befolgen und Social-Engineering-Versuche erkennen sollen. Eine überzeugende Geschichte am Telefon ersetzt die vereinbarte Identitätsprüfung nicht.

Den vollständigen Ablauf vorführen lassen

Verwenden Sie Testkonten und eigens kontrollierte Testpostfächer, keine echten Kundenkonten. Die folgenden vorgeschlagenen Prüfungen machen den Ablauf überprüfbar, beweisen aber nicht die Sicherheit des gesamten Systems:

• Ohne gültige Sitzung lässt sich die Änderung weder über die Oberfläche noch durch einen direkten Aufruf starten.
• Der vorgesehene Zweig verlangt MFA beziehungsweise das aktuelle Passwort.
• Die neue Adresse erscheint als ausstehend und überschreibt nicht stillschweigend die bisherige.
• Im MFA-Zweig ist die Nachricht an die alte Adresse eine Benachrichtigung; im Zweig ohne MFA verlangt sie entsprechend dem dokumentierten Ablauf eine Bestätigung.
• Die neue Adresse allein kann eine Änderung ohne MFA nicht abschließen, solange die Bestätigung der alten Adresse fehlt.
• Abgelaufene, abgebrochene und abgelöste Anträge lassen sich nicht mehr abschließen.
• Nach Abschluss zeigt die Oberfläche die registrierte Adresse eindeutig; die Anmeldung verhält sich wie vereinbart.
• Für unerwartete Aktivitäten und verlorenen Postfachzugang gibt es einen definierten Supportweg ohne informelle Umgehung.

Nehmen Sie das gewählte Verhalten in die Akzeptanzkriterien Ihrer Web-App auf. Klären Sie auch, was nach Abschluss mit anderen angemeldeten Sitzungen und verbundenen Systemen geschieht. Diese Folgen brauchen eigene Entscheidungen; der hier zitierte Abschnitt beantwortet sie nicht vollständig.

Fragen zum Projektumfang

Darf dasselbe Formular auch die Rechnungsadresse ändern?

Nur wenn das beabsichtigt und deutlich erklärt ist. Halten Sie die Zwecke in der Spezifikation auseinander, auch wenn eine Oberfläche beide Funktionen anbietet.

Ändert ein Passwort-Reset auch die registrierte E-Mail?

Davon sollten Sie nicht ausgehen. Ein neues Passwort und eine neue registrierte Adresse sind unterschiedliche Abläufe. Beauftragen Sie beide ausdrücklich, wenn beide gebraucht werden.

Was ist, wenn der Identitätsanbieter das bereits kann?

Lassen Sie den tatsächlich unterstützten Ablauf einschließlich Zwischenzuständen, Nachrichten und Wiederherstellungsgrenzen zeigen. Eine parallele lokale Funktion ist problematisch, wenn sie eine Änderung suggeriert, während die maßgebliche Identität unverändert bleibt. Die Schnittstelle lässt sich im Gespräch über Business-App-Entwicklung abgrenzen.

Quelle und Grenzen

OWASP Authentication Cheat Sheet, „Changing A User's Registered Email Address“: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html#changing-a-users-registered-email-address. Belegt sind die getrennten Empfehlungen mit und ohne MFA, das Vormerken, zeitlich begrenzte Nonces und die Hinweise zum Supportprozess. Getrennte E-Mail-Felder, das Ablösen früherer Anträge, Oberflächentexte und die Vorführungen sind Planungsempfehlungen, keine Aussagen über getestete Implementierungen.