fix(auth): encrypt stored cookie keys; tighten the link and sign-out flows

- Data-protection keys are encrypted (AES-256-GCM, key derived from the
  server secret) before they reach the DataProtectionKeys table.
- /link only follows local return paths and keeps the form when a
  signed-in visitor has an identity waiting to be linked.
- A failed sign-out says so instead of reloading as if it worked.
This commit is contained in:
Alexa
2026-10-25 15:52:29 +02:00
parent f0e4679887
commit 891ec89899
8 changed files with 150 additions and 13 deletions
+4 -1
View File
@@ -497,7 +497,10 @@ above.
Sessions are HttpOnly cookies per host (`dorknet_session`, 30 days, sliding).
The keys that encrypt them are stored in the database (`DataProtectionKeys`),
so redeploys and extra replicas keep everyone signed in. Unlinking the
so redeploys and extra replicas keep everyone signed in. They're stored
encrypted with a key derived from the server secret (`DORKNET_JWT_SECRET`),
so a database backup alone can't forge sessions; changing that secret signs
everyone out. Unlinking the
identity, deleting the account or banning the player ends the session on the
next request. Wrong passwords on the link form are limited to 5 per 15
minutes per provider identity and per username.