Hashed Magic-Link Tokens

Specify magic-link login that stores only a hash of the token. A database leak must not become a pile of valid login links. FLOW User enters email. We send a link. The link signs them in once. Token lifetime: [15 MINUTES] Single use: [YES] Email enumeration: [SAME RESPONSE EITHER WAY] DELIVER 1) Generate a random token with a CSPRNG, send it in the link, store only a hash (name the algorithm). The email is the lookup key plus the hash compare, or the hash is the lookup — pick one and say how you avoid timing leaks on the compare. 2) The row: hash, user id, expires_at, used_at. The consume step is an update that succeeds only if unused and unexpired, in one statement, so two clicks do not both win. 3) The response to "email not found" matches the response to "email sent," with the same timing budget as far as we can. Say what we still might leak. 4) Redirect after login: only relative paths or an allowlist. Show the open-redirect bug we are avoiding. 5) Rate limit on request-link per email and per IP, with numbers I can edit. Do not put the token in a log or a referrer. The link goes to our domain first, not through a third-party preview that fetches it, and you will mention email-scanner prefetch and a confirm button if that is a problem.