--- kind: wireframe-package project: HiveGrid Screen Project ticket: D-P2 / Auth-Core package: WF-P2 Set Password typ: Auth-Core Flow status: In Subframe subframe: "https://app.subframe.com/f023064a5ca0/flow/534bffc2-b7d3-423b-b9b6-da424980dcf3/edit" canvas: "02 Wireframes/P2 Auth/WF-P2 Set Password/WF-P2 Set Password.canvas" --- # WF-P2 Set Password Status: In Subframe Subframe-Link: https://app.subframe.com/f023064a5ca0/flow/534bffc2-b7d3-423b-b9b6-da424980dcf3/edit Canvas: [[WF-P2 Set Password.canvas]] Stand: 2026-06-23 --- ## 1. Kurzfassung `Set Password` ist ein zentraler Auth-Core-Flow fuer wiederverwendbare Passwort-Trigger. Er wird von mehreren Zubringerflows genutzt, z. B. Passwort Reset, Einladung, Passwort aendern, Admin-Reset und Security-Incident. Ausnahme: Der Neukunden-Signup setzt das Passwort direkt im Signup-Flow, um Reibung im Self-Service-Signup zu reduzieren. Signup ist deshalb kein normaler Zubringer zu diesem Core-Flow. Der Nutzer setzt ein neues Passwort und bekommt 2FA entweder freiwillig angeboten oder muss 2FA verpflichtend einrichten. --- ## 2. Intent Check | Frage | Antwort | |---|---| | Welches Ticket/Modul ist betroffen? | D-P2 / Auth-Core | | Was soll der Nutzer am Ende schaffen? | gueltiges Passwort setzen und 2FA-Status klaeren | | Ist es ein Flow, einzelner Screen, Zustand oder nur Dokumentation? | zentraler Auth-Core-Flow | | Welche Planning-Quellen wurden geprueft? | D-P2, UX-Entscheidung mit Head Development | | Was ist sicher im Scope? | Passwort setzen, 2FA freiwillig, 2FA Pflicht, 2FA Setup, Recovery-Hinweis, Abschluss | | Was ist sicher nicht im Scope? | E-Mail anfordern, Reset-Link gesendet, Neukunden-Signup-Daten, Admin-Ausloeser | | Gibt es Admin/Normalrolle-Unterschiede? | Nicht im Core selbst; Pflicht/Freiwillig kommt vom Zubringerflow | | Welche Annahmen sind noch unsicher? | genaue 2FA-Methode/Provider, genaue Recovery-Code-Logik | --- ## 3. Scope | Punkt | Inhalt | |---|---| | Ticket/Modul | D-P2 / Auth-Core | | Nutzerrolle | Nutzer, der zu einem Passwort-Setzen gezwungen oder eingeladen wurde | | Admin-Variante | Admin-Reset kann bestimmen, ob 2FA Pflicht oder freiwillig ist | | Normale Rolle | hoechste Rolle unter Admin; Core bleibt gleich | | Startpunkt | wird von Zubringerflow gesetzt | | Ziel | neues Passwort + 2FA-Entscheidung/Setup abgeschlossen | | Haupt-Archetyp | A4 Form + A5 Auth-Step | | Bespoke-Anteil | nein | | Out of scope | Reset-Anforderung, Signup-Formular, Admin-Trigger | --- ## 4. Brainstorming Screen-Listen entstehen erst nach dem Brainstorming. Hier wurde entschieden, ob `Set Password` nur ein Passwort-Screen oder ein gefuehrter Sicherheits-Setup-Flow ist. ### Flow-Frage Soll `Set Password` nur ein Passwort-Screen sein oder ein zentraler Sicherheitsflow mit Passwort + 2FA + Abschluss? ### UX-Varianten | Option | Beschreibung | Vorteil | Nachteil | Empfehlung | |---|---|---|---|---| | A | Nur Passwort setzen | sehr einfach | 2FA wird nicht gefuehrt | raus | | B | Passwort setzen + 2FA anbieten | flexibel | Pflicht-2FA braucht Sonderlogik | teilweise | | C | Gefuehrter Security-Setup: Passwort + 2FA + Recovery + Abschluss | B2B-sicher, klar, wiederverwendbar | mehr Screens | genommen | | D | Eigener Set-Password-Flow pro Einstieg | maximal spezifisch | unuebersichtlich, viel Dopplung | raus | ### Entscheidung | Entscheidung | Status | Notiz | |---|---|---| | Option C | genommen | zentraler B2B-Security-Flow | | 2FA immer sichtbar machen | genommen | mindestens anbieten | | 2FA freiwillig und 2FA Pflicht trennen | genommen | zwei verschiedene UX-Momente | | Pflicht/Freiwillig kommt vom Zubringerflow | genommen | z. B. Reset, Einladung, Admin-Reset | | Neukunden-Signup ist Ausnahme | genommen | Passwort wird dort direkt im Signup gesetzt | | Recovery-Hinweis bauen | genommen | sicherheitskritisch | | Zurueck-Button bei versehentlichem Einstieg | genommen | sekundare Navigation zurueck zum vorherigen Auth-Schritt, z. B. Reset Password | ### Happy Path 1. Nutzer kommt aus einem Zubringerflow. 2. Nutzer setzt ein neues Passwort. 3. Flow prueft, ob 2FA Pflicht oder freiwillig ist. 4. Nutzer richtet 2FA ein oder ueberspringt, falls erlaubt. 5. Nutzer sieht Recovery-/Sicherheitshinweis. 6. Nutzer erreicht Abschluss und wird weitergeleitet. Der Nutzer kann den Flow ueber eine sekundare Zurueck-/Abbrechen-Aktion verlassen, solange noch keine sicherheitskritische Aktion abgeschlossen wurde und der Zubringerflow es erlaubt. ### Varianten / Branches - 2FA freiwillig: Nutzer kann einrichten oder ueberspringen. - 2FA Pflicht: Nutzer kann nicht ueberspringen. - Zurueck/Abbrechen: Nutzer kann bei versehentlichem Einstieg zum vorherigen Auth-Schritt zurueck. - 2FA Setup wird nach zu vielen Versuchen gesperrt. ### Roadblocks - Passwort zu schwach - 2FA-Code falsch - 2FA Setup gesperrt - Recovery-Hinweis nicht bestaetigt, falls Pflicht ### Offene Fragen - Welche 2FA-Methode ist v1 final? TOTP/Authenticator ist wahrscheinlich. - Muss Recovery-Code aktiv bestaetigt werden oder reicht Hinweis? - Welche Zubringerflows setzen 2FA auf Pflicht? --- ## 5. Screen-Kandidaten nach Entscheidung | Kandidat | Warum eventuell noetig? | Erste Einschaetzung | |---|---|---| | Neues Passwort setzen | Hauptschritt | Bauen | | 2FA freiwillig anbieten | Nutzer darf ueberspringen | Bauen | | 2FA erforderlich | Pflichtzustand, kein Skip | Bauen | | 2FA einrichten | QR/Code/Bestaetigung | Bauen | | Recovery-Code / Sicherheitshinweis | wichtig nach 2FA Setup | Bauen | | Abschluss | klares Ende + Weiterleitung | Bauen | | Zurueck/Abbrechen | wichtig bei versehentlichem Reset-Einstieg | Als Aktion dokumentieren | | Passwort zu schwach | Formularzustand | Nur dokumentieren | | 2FA-Code falsch | Formularzustand | Nur dokumentieren | | 2FA Setup gesperrt | sicherheitskritischer Blocker | Bauen | | 2FA uebersprungen | Ergebniszustand | in Abschluss integrieren | --- ## 6. Screen Validation Gate | ID | Screen/Zustand | Ist eigener Arbeitsmoment? | Neue Struktur/Entscheidung/Risiko? | Entscheidung | Begruendung | |---|---|---|---|---|---| | S01 | [[Screens/S01 Neues Passwort setzen]] | ja | ja, Hauptschritt | Bauen | zentraler Einstieg in Core | | S02 | [[Screens/S02 2FA freiwillig anbieten]] | ja | ja, freiwillige Entscheidung | Bauen | anderer UX-Moment als Pflicht | | S03 | [[Screens/S03 2FA erforderlich]] | ja | ja, Pflicht ohne Skip | Bauen | klarer Sicherheitszwang | | S04 | [[Screens/S04 2FA einrichten]] | ja | ja, Setup mit Code | Bauen | eigener Setup-Schritt | | S05 | [[Screens/S05 Recovery Hinweis]] | ja | ja, sicherheitskritisch | Bauen | Recovery muss verstanden werden | | S06 | [[Screens/S06 Abschluss]] | ja | ja, Ende und Weiterleitung | Bauen | klares Abschlussfeedback | | V01 | Passwort zu schwach | nein | nein | Nur dokumentieren | A4 Formularzustand | | V02 | 2FA-Code falsch | nein | nein | Nur dokumentieren | Inline-Fehler in S04 | | V03 | [[Varianten/V03 2FA Setup gesperrt]] | ja | ja, Blocker | Bauen | Nutzer braucht Loesung | | D01 | 2FA uebersprungen | nein | Ergebniszustand | Wiederverwenden | anderer Text in S06 | | D02 | Zurueck/Abbrechen | nein | Aktion je Zubringerflow | Nur dokumentieren | kein eigener Screen | ### Copy-kritische Zustaende | Zustand | Bauen? | Warum / Copy-Entscheidung | |---|---|---| | 2FA erforderlich | ja | Pflicht darf nicht wie Empfehlung wirken | | 2FA freiwillig | ja | Angebot muss klar, aber nicht noetigend sein | | Recovery-Hinweis | ja | sicherheitskritisch | | Abschluss | ja | Weiterleitung und Status muessen klar sein | | 2FA Setup gesperrt | ja | starker Blocker | --- ## 7. Validierte Screen-Liste | ID | Screen/Zustand | Typ | Umsetzung | Ort | Status | |---|---|---|---|---|---| | S01 | [[Screens/S01 Neues Passwort setzen]] | Auth Form | Bauen | Core Start | Validiert | | S02 | [[Screens/S02 2FA freiwillig anbieten]] | Auth Decision | Bauen | nach S01 | Validiert | | S03 | [[Screens/S03 2FA erforderlich]] | Auth Decision | Bauen | nach S01 | Validiert | | S04 | [[Screens/S04 2FA einrichten]] | Auth Security | Bauen | nach S02/S03 | Validiert | | S05 | [[Screens/S05 Recovery Hinweis]] | Auth Security | Bauen | nach S04 | Validiert | | S06 | [[Screens/S06 Abschluss]] | Auth Feedback | Bauen | Flow-Ende | Validiert | | V03 | [[Varianten/V03 2FA Setup gesperrt]] | Auth Blocker | Bauen | Variante von S04 | Validiert | --- ## 8. Subframe-Grid Hauptflow mit 2FA freiwillig: ```text S01 Neues Passwort setzen -> S02 2FA freiwillig anbieten -> S04 2FA einrichten -> S05 Recovery Hinweis -> S06 Abschluss ``` Freiwillig ueberspringen: ```text S02 2FA freiwillig anbieten -> S06 Abschluss ``` 2FA Pflicht: ```text S01 Neues Passwort setzen -> S03 2FA erforderlich -> S04 2FA einrichten -> S05 Recovery Hinweis -> S06 Abschluss ``` Blocker: ```text S04 2FA einrichten -> V03 2FA Setup gesperrt ``` --- ## 9. Screen-Pakete - [[Screens/S01 Neues Passwort setzen]] - [[Screens/S02 2FA freiwillig anbieten]] - [[Screens/S03 2FA erforderlich]] - [[Screens/S04 2FA einrichten]] - [[Screens/S05 Recovery Hinweis]] - [[Screens/S06 Abschluss]] - [[Varianten/V03 2FA Setup gesperrt]] --- ## 10. Handoff-Check - [x] Jeder Screen ist mit Umsetzung markiert. - [x] Jedes sichtbare Feld hat eine Datenquelle. - [x] Jeder Button hat eine Aktion. - [x] Banner/Inline-Meldungen sind dokumentiert. - [x] Toasts/Action-Feedback sind dokumentiert. - [x] Relevante Zustaende sind beschrieben. - [x] Zubringer-/Core-Regel ist dokumentiert. - [x] Zurueck-/Abbrechen-Aktion ist dokumentiert. - [x] Offene Fragen sind sichtbar. - [x] Subframe-Link ist eingetragen.