Authentication fuzzing

Verifies

Requires an AI engine: Every credential verification site (JWT, bearer, session token, OTP, magic link, personal access token) rejects malformed, expired, replayed and downgraded credentials; the fuzz classes are applied statically, without executing the code.

Inputs

Non-test code files of the checkout (JavaScript, TypeScript, Python, PHP) that verify credentials. They are sent together (at most 24) in one assessment call to the chosen engine through the platform ai service; at most 160000 estimated tokens. Paths listed in excludes (test, spec and tmp files, __tests__, __mocks__, fixtures, test, tests and audit-scripts folders) are never analysed. Every model call (rubric, repository context and files) stays under 120000 characters; a candidate set that does not fit is sent in parts, each part bounded by what the chosen engine serves in one call (the engine publishes that budget; a call is never filled up to the transport cap).

Decision rule

Not applicable when no verification site exists. FAIL (HIGH) on jwt.verify without an algorithms list, 'none' among accepted algorithms, PyJWT decode without algorithms or with verify_signature False, php-jwt decode without an algorithm-bound Key, a token decoded and trusted without verification, ignoreExpiration or verify_exp disabled, or a clock tolerance above five minutes. A verifier not wrapped in error handling, or a one-time credential verified without a consumption signal, is MEDIUM (blocks in this Extended suite). The model must establish with confidence of at least 0.8 that every site rejects the four classes: an unsatisfied or undecided assessment is a FAIL, a HIGH finding is a FAIL, an unparseable answer is a FAIL. PASS only with a satisfied assessment and nothing blocking. When the candidate set goes in parts, a HIGH finding in any part is a FAIL and the assessment is unsatisfied when any part says so, satisfied only when a part establishes it and none denies it. Without an AI engine the check is not executed (requires an AI engine).

Type

ai-assisted · engine chosen by the organisation · medium

1.0.4: `assess` mode cuts the candidate set to what the chosen ENGINE serves in ONE call (`ctx.ai.maxInputChars`, published by the engine per its catalogue budget; `ENGINE_CALL_MAX_CHARS` = 32 000 when an older sandbox does not publish it), instead of filling the call up to the TRANSPORT cap of the proxy (`spec.promptMaxChars`, unchanged at 120 000). On a 1 319-file checkout the old packing produced single prompts of 17 672 / 26 709 / 29 351 tokens and the platform GPU answered "CUDA out of memory": the check ended in `error`. Every call of the same run under ~24 000 characters was answered normally. The part aggregation of 1.0.1 is unchanged: a HIGH in any part is a FAIL, an unsatisfied part is a FAIL, undecided never passes. (1.0.3: requires an AI engine (spec.requiresEngine: true): the check needs judgement and is executed only when the organisation provides an engine; the core catalogue runs without one. (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.