Files
HiveGrid-Wireframes/02 Wireframes/P2 Auth/WF-P2 Change Password/WF-P2 Change Password.md
T
2026-06-24 23:36:10 +02:00

200 lines
8.6 KiB
Markdown

---
kind: wireframe-package
project: HiveGrid Screen Project
ticket: D-P2 / Auth-Core
package: WF-P2 Change Password
typ: Auth-Core Zubringer/Modal Flow
status: In Subframe
subframe: "https://app.subframe.com/f023064a5ca0/flow/04767909-3c2f-4236-92a8-b08eaa3f51b7/edit"
canvas: WF-P2 Change Password.canvas
---
# WF-P2 Change Password
Status: In Subframe
Subframe-Link: https://app.subframe.com/f023064a5ca0/flow/04767909-3c2f-4236-92a8-b08eaa3f51b7/edit
Canvas: [[WF-P2 Change Password.canvas]]
Stand: 2026-06-23
---
## 1. Kurzfassung
`Change Password` ist ein eigener, wiederverwendbarer Reauth-/Step-up-Flow fuer Passwortaenderungen.
Der Flow wird aus Profil Settings getriggert, bleibt aber bewusst getrennt, damit er spaeter auch aus anderen Kontexten genutzt werden kann. Da der Nutzer bereits eingeloggt ist, laeuft die Reauth innerhalb der App-Shell als Modal-/Wizard-Flow.
Validierter Sicherheitsansatz: kein E-Mail-Link. Stattdessen wird die aktuelle Account-E-Mail readonly angezeigt, der Nutzer muss sein aktuelles Passwort eingeben und bei aktiver 2FA im selben Modal zusaetzlich den 2FA-Code bestaetigen. Danach fuehrt der Flow in den Core-Flow `WF-P2 Set Password`, der das neue Passwort und den Abschluss besitzt.
---
## 2. Intent Check
| Frage | Antwort |
|---|---|
| Welches Ticket/Modul ist betroffen? | D-P2 / Auth-Core |
| Was soll der Nutzer am Ende schaffen? | Passwortaenderung im eingeloggten Zustand sicher starten und in `WF-P2 Set Password` wechseln |
| Ist es ein Flow, einzelner Screen, Zustand oder nur Dokumentation? | eigener wiederverwendbarer Reauth-/Step-up-Modal-Flow |
| Welche Planning-Quellen wurden geprueft? | D-P2, Profil-und-Sicherheit-Entscheidung, OWASP MFA Guidance |
| Was ist sicher im Scope? | Account-E-Mail readonly anzeigen, aktuelles Passwort pruefen, optionaler 2FA-Code im selben Reauth-Modal, Uebergabe an `WF-P2 Set Password` |
| Was ist sicher nicht im Scope? | Profil Settings selbst, Passwort Reset fuer vergessene Passwoerter, Admin-Reset, E-Mail-Link-Flow, neues Passwort setzen, Abschlussfeedback |
| Gibt es Admin/Normalrolle-Unterschiede? | nein; gleicher Self-Service-Flow fuer eingeloggte Nutzer |
| Welche Annahmen sind noch unsicher? | ob 2FA nur bei aktivem 2FA verlangt wird oder fuer bestimmte Rollen/Policies immer |
---
## 3. Scope
| Punkt | Inhalt |
|---|---|
| Ticket/Modul | D-P2 / Auth-Core |
| Nutzerrolle | eingeloggter Nutzer |
| Admin-Variante | keine eigene UI; Policy kann 2FA erzwingen |
| Normale Rolle | gleicher Flow |
| Startpunkt | Trigger aus Profil Settings oder spaeter anderer Sicherheitskontext |
| Ziel | sicherer Uebergang in `WF-P2 Set Password` |
| Haupt-Archetyp | A5 Modal/Wizard + A4 Auth Form |
| Bespoke-Anteil | nein |
| Out of scope | Profil bearbeiten, 2FA verwalten, Passwort vergessen, E-Mail-Link versenden, neues Passwort setzen, Abschlussfeedback |
---
## 4. Brainstorming
### Flow-Frage
Soll Passwort aendern im eingeloggten Zustand ueber E-Mail-Link laufen oder direkt mit Step-up-Authentifizierung innerhalb der App?
### UX-Varianten
| Option | Beschreibung | Vorteil | Nachteil | Empfehlung |
|---|---|---|---|---|
| A | E-Mail-Link senden, danach Set-Password-Flow starten | stark entkoppelt | unnoetiger Medienbruch im eingeloggten Zustand | raus fuer diesen Flow |
| B | Modal-Flow: aktuelle E-Mail anzeigen, aktuelles Passwort, optional 2FA-Code im selben Modal, dann Uebergabe an `WF-P2 Set Password` | sicher, schnell, bleibt leichtgewichtig | etwas mehr Inhalt in einem Modal | genommen |
| C | Direkt neues Passwort im Profil setzen | sehr schnell | keine ausreichende Step-up-Pruefung | raus |
### Entscheidung
| Entscheidung | Status | Notiz |
|---|---|---|
| Eigener Change-Password-Flow | genommen | getrennt vom Profil, spaeter wiederverwendbar |
| UI als Modal-/Wizard-Flow | genommen | Start aus eingeloggter App-Shell |
| Account-E-Mail readonly anzeigen | genommen | Nutzer sieht, fuer welches Konto geaendert wird |
| Aktuelles Passwort verlangen | genommen | Step-up fuer sensible Kontoaenderung |
| Kein E-Mail-Link | genommen | bei erfolgreicher Reauth nicht noetig; Passwort Reset bleibt eigener E-Mail-Link-Flow |
| 2FA-Code im Reauth-Modal | genommen | wenn 2FA aktiv ist oder Policy es verlangt; kein eigener 2FA-Bestaetigen-Screen |
| Neues Passwort setzen liegt im Core | genommen | nach erfolgreicher Reauth fuehrt der Flow zu `WF-P2 Set Password` |
| Profil enthaelt nur Trigger | genommen | Profil startet Flow, enthaelt ihn aber nicht |
### Passwort-Staerke-Bar
Bei allen Screens, in denen ein neues Passwort gesetzt wird, soll unter dem Passwortfeld eine Staerke-Bar sitzen. Sie fuellt sich dynamisch und wird bei guter Passwortqualitaet gruen. Aktuelles Passwort/Reauth-Felder bekommen keine Staerke-Bar.
### Happy Path
1. Nutzer klickt in Profil Settings auf Passwort aendern.
2. Modal `Passwort aendern` oeffnet sich innerhalb der App-Shell.
3. Aktuelle Account-E-Mail wird readonly angezeigt.
4. Nutzer gibt aktuelles Passwort ein.
5. Wenn 2FA aktiv/erforderlich ist, gibt Nutzer den 2FA-Code im selben Modal ein.
6. Flow fuehrt in `WF-P2 Set Password`.
7. `WF-P2 Set Password` uebernimmt neues Passwort, Passwortregeln und Abschluss.
### Varianten / Branches
- Aktuelles Passwort ist falsch.
- 2FA-Code ist falsch.
- 2FA ist nicht aktiv: 2FA-Schritt wird uebersprungen.
- Passwort entspricht nicht den Regeln: liegt in `WF-P2 Set Password`.
- Rate Limit nach mehrfach falscher Reauth.
- Nutzer bricht ab und kehrt zu Profil Settings zurueck.
### Roadblocks
- aktuelles Passwort falsch
- 2FA-Code falsch
- Rate Limit
- nachgelagerte Passwortfehler liegen in `WF-P2 Set Password`
### Meldungs-/Error-State-Brainstorming
| Ereignis | UI-Form | Blockiert? | Bauen? | Copy/Notiz |
|---|---|---|---|---|
| aktuelles Passwort falsch | Inline | ja | nein | korrigierbar im Modal |
| 2FA-Code falsch | Inline | ja | nein | korrigierbar in M01 |
| Rate Limit | Modal/Banner | ja | pruefen | erneuter Versuch spaeter |
| neues Passwort ungueltig | - | - | nein | liegt in `WF-P2 Set Password` |
| Passwort geaendert | - | - | nein | Abschluss liegt in `WF-P2 Set Password` |
---
## 5. Screen-Kandidaten nach Entscheidung
| Kandidat | Warum eventuell noetig? | Erste Einschaetzung |
|---|---|---|
| Identitaet bestaetigen | aktuelles Passwort + Account-E-Mail | Bauen |
| 2FA-Code eingeben | Zustand in M01, falls 2FA aktiv/Policy | Nur dokumentieren |
| Neues Passwort setzen | Passwort-Core | Wiederverwenden `WF-P2 Set Password` |
| Passwort geaendert | Abschluss | Wiederverwenden `WF-P2 Set Password` |
| Rate Limit / zu viele Fehlversuche | Sicherheitsblocker | Bauen |
---
## 6. Screen Validation Gate
| ID | Screen/Zustand | Ist eigener Arbeitsmoment? | Neue Struktur/Entscheidung/Risiko? | Entscheidung | Begruendung |
|---|---|---|---|---|---|
| M01 | Identitaet bestaetigen | ja | ja, Security Step-up | Bauen | Account-E-Mail readonly + aktuelles Passwort + optionaler 2FA-Code |
| D03 | 2FA-Code eingeben | nein | nein, Teil von Reauth | Nur dokumentieren | kein eigener Screen/Flow |
| D01 | Neues Passwort setzen | ja | ja, Passwort-Core | Wiederverwenden | liegt in `WF-P2 Set Password` |
| D02 | Passwort geaendert | ja | nein, Feedback | Wiederverwenden | Abschluss liegt in `WF-P2 Set Password` |
| V01 | Zu viele Fehlversuche | ja | ja, Security Blocker | Bauen | Rate Limit darf nicht nur inline verschwinden |
---
## 7. Validierte Screen-Liste
| ID | Screen/Zustand | Typ | Umsetzung | Ort | Status |
|---|---|---|---|---|---|
| M01 | Identitaet bestaetigen | Modal | Bauen | von Profil Settings | Validiert |
| D01 | Neues Passwort setzen | Auth-Core | Wiederverwenden | `WF-P2 Set Password` | Validiert |
| D02 | Passwort geaendert | Auth-Core Feedback | Wiederverwenden | `WF-P2 Set Password` | Validiert |
| V01 | Zu viele Fehlversuche | Modal/Blocker | Bauen | nach falscher Reauth | Validiert |
---
## 8. Subframe-Grid
```text
Profil Settings -> M01 Identitaet bestaetigen
M01 enthaelt optional 2FA-Code, wenn 2FA aktiv/Policy
M01 -> WF-P2 Set Password
WF-P2 Set Password -> neues Passwort setzen + Abschluss
M01 -> V01 Zu viele Fehlversuche
```
---
## 9. Screen-Pakete
| ID | Datei |
|---|---|
| M01 | [[Screens/M01 Identitaet bestaetigen.md]] |
| V01 | [[Varianten/V01 Zu viele Fehlversuche.md]] |
Core-Verweis:
- [[../WF-P2 Set Password/WF-P2 Set Password.md]]
---
## 10. Handoff-Check
- [x] Eigenes Paket ist angelegt.
- [x] Profil ist nur Trigger, nicht Besitzer des Flows.
- [x] E-Mail-Link-Variante ist fuer eingeloggte Passwortaenderung rausgenommen.
- [x] Reauth mit aktuellem Passwort ist dokumentiert.
- [x] 2FA-Code ist als optionaler Zustand in M01 dokumentiert.
- [x] David hat die Kandidaten validiert.
- [ ] Subframe-Link ist eingetragen.