Einladungs-Token nur noch gehasht persistieren (Leser beidseitig)
Der einmal verwendbare Portal-Einladungs-/Reset-Token lag im KLARTEXT in
Consumers.verificationCode. Wer die Datenbank lesen kann, konnte damit jeden
offenen Einladungs-Link uebernehmen — Passwort setzen ist Konto-Uebernahme.
Dieselbe Fehlerklasse wie storeevent-persistiert-rohen-reset-token (behoben
2026-08-20); die Nutzer-Ebene (platform/auth password.ts) hasht laengst.
Neu: hashPortalInviteToken = sha256(token) hex. In der Zeile liegt nur noch
der Digest; der Roh-Token verlaesst den Prozess ausschliesslich in der
Mail-Adresse.
Reihenfolge ist tragend — der LESER kommt zuerst und ist beidseitig:
findConsumerByPortalInviteToken fragt ZUERST den Hash und faellt danach auf
den Roh-Wert zurueck, damit vor dem Umbau geminteten Einladungen einloesbar
bleiben. Der Rueckfall traegt ein Ablaufdatum im Kommentar (ENTFERNEN AB
2026-08-29 = Umbau-Tag + PORTAL_INVITE_TTL_MS); danach kann kein Roh-Token
mehr gueltig sein, weil inspectPortalInviteToken vorher abweist.
Bewusst OHNE pi-Praefix am Hash: ein reiner Hex-Digest kann per Bauart nicht
mit pi- beginnen, der Praefix bleibt damit die Trennung zum Telegram-
Anmelde-Wert in DERSELBEN Spalte. Gemessen 2026-08-22: 158 Zeilen mit
verificationCode, davon 2 mit pi-; die uebrigen 156 gehoeren Telegram und
werden nicht angefasst. Von den 2 war genau EINE noch innerhalb der
Lebensdauer (gesetzt 07:30Z), die andere 24 Tage alt und damit laengst
abgewiesen.
Kein Salz: der Token traegt 24 zufaellige Bytes, ein Woerterbuch-Angriff ist
gegenstandslos — und ein Salz machte den Gleichheits-Nachschlag unmoeglich,
den dieser Weg braucht.
portal-auth.ts ist NICHT angefasst: es ruft nur mint + set + find und
bekommt den Roh-Token weiterhin fuer die Mail-Adresse. Die Schichtung
stimmt damit von selbst.
8 neue Proben mit AY-Attrappe, die den WEG pruefen (welcher Wert im Filter
stand, in welcher Reihenfolge gefragt wurde) — nicht nur das Ergebnis.
Zwei Flip-Proben gefahren: Schreiber zurueck auf Klartext => 1 rot,
Lookup-Reihenfolge umgedreht => 2 rot, zurueck => 15/15. Volle Reihe 1574
gruen. Der fest verdrahtete Digest in der Probe ist derselbe wie in
crm-api — laufen die Zwillinge auseinander, wird eine Einladung
unaufloesbar, OHNE dass ein Fehler entsteht.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Consumers.verificationCode. Wer die Datenbank lesen kann, konnte damit jeden
offenen Einladungs-Link uebernehmen — Passwort setzen ist Konto-Uebernahme.
Dieselbe Fehlerklasse wie storeevent-persistiert-rohen-reset-token (behoben
2026-08-20); die Nutzer-Ebene (platform/auth password.ts) hasht laengst.
Neu: hashPortalInviteToken = sha256(token) hex. In der Zeile liegt nur noch
der Digest; der Roh-Token verlaesst den Prozess ausschliesslich in der
Mail-Adresse.
Reihenfolge ist tragend — der LESER kommt zuerst und ist beidseitig:
findConsumerByPortalInviteToken fragt ZUERST den Hash und faellt danach auf
den Roh-Wert zurueck, damit vor dem Umbau geminteten Einladungen einloesbar
bleiben. Der Rueckfall traegt ein Ablaufdatum im Kommentar (ENTFERNEN AB
2026-08-29 = Umbau-Tag + PORTAL_INVITE_TTL_MS); danach kann kein Roh-Token
mehr gueltig sein, weil inspectPortalInviteToken vorher abweist.
Bewusst OHNE pi-Praefix am Hash: ein reiner Hex-Digest kann per Bauart nicht
mit pi- beginnen, der Praefix bleibt damit die Trennung zum Telegram-
Anmelde-Wert in DERSELBEN Spalte. Gemessen 2026-08-22: 158 Zeilen mit
verificationCode, davon 2 mit pi-; die uebrigen 156 gehoeren Telegram und
werden nicht angefasst. Von den 2 war genau EINE noch innerhalb der
Lebensdauer (gesetzt 07:30Z), die andere 24 Tage alt und damit laengst
abgewiesen.
Kein Salz: der Token traegt 24 zufaellige Bytes, ein Woerterbuch-Angriff ist
gegenstandslos — und ein Salz machte den Gleichheits-Nachschlag unmoeglich,
den dieser Weg braucht.
portal-auth.ts ist NICHT angefasst: es ruft nur mint + set + find und
bekommt den Roh-Token weiterhin fuer die Mail-Adresse. Die Schichtung
stimmt damit von selbst.
8 neue Proben mit AY-Attrappe, die den WEG pruefen (welcher Wert im Filter
stand, in welcher Reihenfolge gefragt wurde) — nicht nur das Ergebnis.
Zwei Flip-Proben gefahren: Schreiber zurueck auf Klartext => 1 rot,
Lookup-Reihenfolge umgedreht => 2 rot, zurueck => 15/15. Volle Reihe 1574
gruen. Der fest verdrahtete Digest in der Probe ist derselbe wie in
crm-api — laufen die Zwillinge auseinander, wird eine Einladung
unaufloesbar, OHNE dass ein Fehler entsteht.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>