Layered identity checks before control authority is granted.

1. Browser abuse verification

The sign-in form uses a hostname-restricted Cloudflare Turnstile Managed widget with action login. The browser sends a short-lived single-use token with the credential request. Before password verification begins, the server sends that token through a loopback-only Nginx verification proxy to Cloudflare Siteverify and requires a successful response with the expected hostname and action.

The public site key is returned by the authentication configuration endpoint. The secret key exists only in the protected VPS environment file. Missing, expired, replayed, incorrectly scoped, or rejected tokens fail closed and are recorded as challenge outcomes without storing the token. Existing source and account attempt windows remain active because browser verification does not replace rate control.

2. Credential verification

Passwords are stored as PBKDF2-HMAC-SHA-256 digests with a unique 128-bit salt and 600,000 iterations. Candidate length is bounded before the work factor is applied. Digest comparison is constant time. The browser receives neither password hashes nor verification configuration.

3. Privileged verification

Privileged identities receive a random five-minute challenge after password success. The challenge is associated with the initiating source digest, limited to five attempts, removed after success, and pruned after expiry. Verification values are hashed and never entered into audit records.

4. Session lifecycle

5. Request authorization

Authenticated mutation requires the session cookie, an allowed origin, the matching session-specific X-CSRF-Token, an authorized server-side role, valid input, and an available operation rate window. A console button state is never used as the authoritative control.

Audit-stream access has its own role boundary. Resource creation, settings changes, and actions reject read-only identities at the API layer.

6. Rate and source handling

Login attempts are controlled by both source boundary and normalized username. The application does not trust client-supplied forwarding headers by default; the origin overwrites forwarded address input and the API uses its direct peer unless explicitly configured for a trusted proxy. Recovery, MFA, and control actions have separate windows.

7. Recovery and failure behavior

Recovery returns the same accepted response whether or not an identity exists. Completion continues through the registered support channel. Authentication errors use generic messages and structured request IDs. Password, MFA, cookie, CSRF, and Turnstile token values are excluded from error bodies and audit events.