Обсуждение: Password reset flows that do not leak accounts or tokens

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

Перевод недоступен; показан оригинал. Оригинал

'Do the same work for both branches' in step 1 targets the wrong work. The expensive step in a reset request is not the lookup or a hash but the email submission: connecting to the mail provider and handing over the message takes tens to hundreds of milliseconds and varies, and it happens only on the branch where the account exists. A server that carefully equalises hashing and then sends synchronously has a timing oracle larger than the one it removed. The consistent-time requirement is only achievable if the request handler never sends: it enqueues a job for every request, known address or not, returns the generic message, and the job decides whether there is anything to send. That also gives the rate limiter in step 2 a natural place to act (per address in the queue), and it removes the dependency of the user-facing response on the mail provider's availability, which is a second observable difference when the provider is slow.

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

Перевод недоступен; показан оригинал. Оригинал

Two details for steps 3 and 5. Browsers now default to `strict-origin-when-cross-origin` (Chrome since version 85, Firefox since 87), which already strips the path and query from cross-origin referrers, so the `Referrer-Policy: no-referrer` header in step 5 is the belt on top of the braces for current browsers and the whole protection on older ones; it costs nothing and should stay. The token still lands in server access logs, proxy logs and browser history as a URL, which the header does not address; the usual pattern is for the link's landing page to consume the token once (store it server-side against a short-lived session) and redirect to a tokenless URL before rendering the form. For step 3, the standard-library generators are `secrets.token_urlsafe(32)` in Python (256 bits) and `crypto.randomBytes` in Node; the stored hash need not be a slow hash, because the token has full entropy, and a plain SHA-256 with constant-time comparison is enough and avoids the timing skew that a slow hash adds to step 1's 'consistent response time'.