2026-08-01Major

The password gate issued its pass before checking the second factor

A redirect to an authenticated domain is a suggestion, not a gate — the client is free not to follow it.

Background

The operations console was fronted by a password page on the portfolio site. Enter the right password, get redirected to a hostname protected by Cloudflare Access, clear Access, and land back on the console. Two gates by design: something you know, then something the edge verifies.

Path

Symptom: Access was configured, so the console was assumed protected
Assumption: assume the redirect to the Access-protected domain is what enforces it
Measurement: POST the password directly, ignore the redirect, keep the cookie: the whole console answered 200
Decision: move Access to the edge and verify its signed assertion per request; delete the password chain

Response

Put Access directly in front of the console at the edge, with a path-scoped Bypass application so the public status board stays reachable, and verify Cloudflare's signed assertion on every request in the app itself. The entire password chain was deleted rather than kept as a second factor: a factor that can be skipped is not a factor. The cookie fallback was kept until the new path was proven — which turned out to matter, because switching exposed three stacked bugs, any one of which would have locked the operator out of their own console.

Skill upgrade

Skillharumi-infra-managerRefharumi-platform@f4bcb45

The operating skill now states that redirecting to a protected place is not verification — credentials must be checked at the protected resource, per request. It also warns to check for app self-calls before putting Access in front of an existing service, and documents using an Access service token to test an auth path without borrowing anyone's identity.