toolctrl-labs/HiveGrid-Wireframes
9
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
58df5360aab2953ca8070f736eec2a135b855ea2
HiveGrid-Wireframes/02 Wireframes/P2 Auth/WF-P2 Change Password/WF-P2 Change Password.md
T
david 7ac52911fd Initial wireframe planning
2026-06-24 23:36:10 +02:00

8.6 KiB
Raw Blame History

kind, project, ticket, package, typ, status, subframe, canvas
kind project ticket package typ status subframe canvas
wireframe-package HiveGrid Screen Project D-P2 / Auth-Core WF-P2 Change Password Auth-Core Zubringer/Modal Flow In Subframe https://app.subframe.com/f023064a5ca0/flow/04767909-3c2f-4236-92a8-b08eaa3f51b7/edit 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

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:

10. Handoff-Check

  • Eigenes Paket ist angelegt.
  • Profil ist nur Trigger, nicht Besitzer des Flows.
  • E-Mail-Link-Variante ist fuer eingeloggte Passwortaenderung rausgenommen.
  • Reauth mit aktuellem Passwort ist dokumentiert.
  • 2FA-Code ist als optionaler Zustand in M01 dokumentiert.
  • David hat die Kandidaten validiert.
  • Subframe-Link ist eingetragen.
Reference in new issue View Git Blame Copy Permalink