Hardened password reset

Verifies

Password-reset tokens are cryptographically random, single-use and short-lived, and the request step does not reveal whether an account exists. No AI engine is involved: the verdict is reproducible from the source alone.

Inputs

Non-test code files of the checkout (JavaScript, TypeScript, Python, PHP) whose path or content names the password-reset flow, analysed statically with the static analysis kit: tokens, function units, calls, imports and route registrations of Next, Express, Fastify, Koa, Hono, Nest, Lambda, Django, Flask, FastAPI and Laravel. The units of analysis are the REQUEST function (a forgot/recover/send-reset route or function that reads the address and issues the token or the mail) and the CONFIRMATION function (a reset/confirm/new-password route or function that reads the token and sets the password); the functions they call within 2 module hops (token helpers, repositories, mailers) are followed. Paths listed in excludes (test, spec and tmp files, __tests__, __mocks__, fixtures, test, tests and audit-scripts folders) are never analysed. Nothing of the checkout is executed.

Decision rule

Not applicable when the checkout has no password-reset flow, or when files use reset vocabulary but none implements a request or a confirmation function and no framework flow is referenced (the reason says so). PASS when a framework flow (Django PasswordResetView/default_token_generator, Laravel Password broker/Fortify, Devise, NextAuth, Clerk, Auth0, Supabase or Firebase reset) is referenced and no custom unit overrides it. For the request unit: FAIL (HIGH) when the token is generated with Math.random, random.random, rand, mt_rand, uniqid, str_shuffle or the clock, in the unit or a function it calls; FAIL (HIGH) when the absent-account branch (if (!user), if user is None, except DoesNotExist, or a firstOrFail/get_object_or_404 lookup) answers with a 4xx status, an exception, a validation error or a message naming the missing account; a message of its own that the success path never answers is MEDIUM (blocks in Extended suites); the same message, a uniform 'if an account exists' answer or no distinct branch passes. For the confirmation unit: MEDIUM when the token is not consumed (no delete, null, used mark, invalidation or framework check_token in the unit or its callees) and MEDIUM when its expiry is never checked (no expires/ttl/valid_until/created_at comparison, PASSWORD_RESET_TIMEOUT, checkToken or tokenExpired). PASS when every request unit uses a cryptographic or invisible-but-framework token source and answers uniformly, and every confirmation unit consumes the token and checks its expiry; the summary names each. Not judged by this check (declared): timing differences between the two branches, the length of the expiry, the strength of the token stored (hashed or not), single use and expiry when the checkout has no confirmation unit, and enumeration when it has no request unit.

Type

deterministic

1.1.1: a callee whose root is a name that `Object.prototype` also carries (`build().toString()` tokenizes to the bare callee `toString`; also `constructor`, `valueOf`, `hasOwnProperty`) was looked up in the plain object that holds the imported names, so it resolved to the INHERITED FUNCTION instead of to nothing and the whole check died with "name.includes is not a function". Only a real binding counts now, and the name of a unit is always read as a string. Found on a 1 319-file checkout (2fa-available and session-expiry-rotation, 2026-09-24); the same line was in the 15 scripts that walk the call graph, so all fifteen ship the fix. (1.1.0: deterministic: the rule runs over the static analysis kit (tokens, function units, calls, imports, routes) with no AI engine; exact decisionRule and languages published; not-applicable with the reason when the checkout gives nothing to evaluate. The units are the REQUEST function and the CONFIRMATION function of the reset flow (plus 2 module hops): a weak token source is HIGH; the absent-account branch (if (!user), is None, DoesNotExist, firstOrFail) answering 4xx, an exception or a 'no account' message is HIGH, a message of its own is MEDIUM; a confirmation without token consumption or without an expiry check is MEDIUM; framework flows pass when not overridden; reset vocabulary without a request or confirmation unit is not-applicable. Not judged: timing, expiry length, token hashing. (1.0.2: never analyses temporary files (*.tmp.*; spec.excludes follows AUDITOR_ANALYSIS_EXCLUDES). (1.0.1: never analyses test, spec, fixture and mock paths nor the auditor's own scripts (spec.excludes = AUDITOR_ANALYSIS_EXCLUDES); a fixture-looking secret (sk_test_, example, dummy) in real code is LOW, informative; every model call stays under the engine prompt cap (spec.promptMaxChars = AUDITOR_AI_PROMPT_MAX_CHARS): assess mode sends the candidate set in parts and aggregates the verdicts (a HIGH in any part is a FAIL, an unsatisfied part is a FAIL).)))

The full script is disclosed on request in a read-only viewer (never published on GitHub); the attestation binds to this exact hash.