WebAuthn Conditional UI Isolation and Cryptographic Step-Up Invariant

Q: How does adopting this rule prevent AI hallucinations?

This rule explicitly declares what the AI must avoid (Conflating Passive Passkey Autofill Assertions with Explicit High-Privilege Step-Up Proofs) and prescribes verified positive examples. Grounding the LLM with negative and positive pairs eliminates guesswork.

Q: Which AI coding environments are supported?

This specification is multi-platform compatible: Cursor (.cursor/rules/*.mdc & .cursorrules), Anthropic Claude Code (CLAUDE.md), Windsurf (.windsurfrules), Codex / Cline (AGENTS.md), and GitHub Copilot (.github/copilot-instructions.md).

Q: Can I combine this rule with other technology stacks?

Yes. Use the Interactive Stack Builder or download an Agent Pack to merge this rule with other frontend, backend, database, security, and DevOps rules without syntax collision.

WebAuthn Conditional UI Isolation and Cryptographic Step-Up Invariant

--- description: WebAuthn Conditional UI Isolation and Cryptographic Step-Up Invariant - Enforces strict cryptographic and contextual isolation between passive Conditional UI passkey autofill assertions and active step-up re-authentication ceremonies. Prevents session fixation, cross-context assertion replay, and downgrade attacks by mandating ephemeral transaction-bound challenges, explicit mediation, and compulsory User Verification (UV) flags for all privileged mutations. globs: src/auth/**/*.{ts,tsx}, src/server/auth/**/*.{ts,js}, src/services/auth/**/*.{ts,js}, src/api/routes/**/*.{ts,js}, src/hooks/usePasskey.{ts,tsx} alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/webauthn-conditional-ui-stepup-isolation" --- # WebAuthn Conditional UI Isolation and Cryptographic Step-Up Invariant > **Severity**: CRITICAL | **Category**: security > **Anti-Pattern Warning**: Conflating Passive Passkey Autofill Assertions with Explicit High-Privilege Step-Up Proofs ## System Constraints You are a Principal Security Architect enforcing FIDO2/WebAuthn Level 3 specifications. Your objective is to prevent authentication downgrade and session hijacking by strictly isolating Conditional UI (passkey autofill) flows from Step-Up and Re-Authentication ceremonies. Conditional UI must strictly govern ambient sign-in, whereas Step-Up re-authentication requires explicit user intent, transaction-bound ephemeral challenges, strict 'userVerification: required', and atomic invalidation of single-use challenges. ## Strict Guidelines - Engineers MUST ALWAYS set 'userVerification: required' on the server and client during Step-Up and Re-Authentication operations; 'preferred' or 'discouraged' is strictly forbidden for privileged transactions. - Engineers MUST NEVER permit 'mediation: conditional' during Step-Up, authorization-gated operations, or re-authentication flows; step-up ceremonies must execute explicitly with ambient UI blocked. - Services MUST bind the WebAuthn challenge to the specific transaction payload using a cryptographic digest (e.g., SHA-256 of action, amount, recipient, and session token) stored in a short-lived (<= 60s), single-use redis or memory store. - Services MUST atomically invalidate challenges immediately upon submission, regardless of whether the cryptographic verification succeeds or fails, to prevent replay attacks. - Services MUST verify that the AuthenticatorData flags contain both the User Present (UP) bit AND the User Verified (UV) bit set to 1, asserting cryptographic proof of biometrics or local PIN entry. - Components NEVER fall back to cached assertions or session tokens when executing sensitive state-changing operations (e.g., credential updates, funds transfer, access tier elevation). ## Bad vs Good Implementations ### Vulnerable Passkey Step-Up vs. Cryptographically Isolated Step-Up Implementation #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: The bad example permits authentication without strictly enforcing User Verification (UV flag). It reuses ambient login challenges without binding to the specific transaction context or payload digest, leaving the flow vulnerable to session fixation, assertion reuse across sessions, and silent bypass. ```typescript import { generateAuthenticationOptions, verifyAuthenticationResponse } from '@simplewebauthn/server'; // ANTI-PATTERN: Reusing generic login challenges without transaction binding, // accepting 'preferred' verification, and failing to invalidate on first read. export async function verifyStepUpAction(req: Request, user: UserSession) { const { credentialResponse } = await req.json(); // Flaw 1: Using generic cached challenge from session instead of transaction-bound store const expectedChallenge = user.currentChallenge; const verification = await verifyAuthenticationResponse({ response: credentialResponse, expectedChallenge, expectedOrigin: 'https://example.com', expectedRPID: 'example.com', authenticator: user.authenticators[0], requireUserVerification: false // Flaw 2: Fails to enforce biometric/PIN user verification }); if (verification.verified) { await performPrivilegedMutation(user.id); // Flaw 3: Mutation executed without proof-to-payload binding } return verification; } ``` #### Production Standard (Correct) > **Standard**: The invariant fix cryptographically ties the step-up challenge to the transaction payload and user session. It enforces strict User Verification (UV = true), prevents replay via atomic GETDEL consumption from Redis, and isolates step-up verification entirely from passive autofill challenges. ```typescript import { verifyAuthenticationResponse } from '@simplewebauthn/server'; import { createHash } from 'node:crypto'; import { redis } from '@/lib/redis'; interface StepUpPayload { action: 'TRANSFER_FUNDS' | 'UPDATE_SECURITY'; targetId: string; nonce: string; } export async function verifyIsolatedStepUp( credentialResponse: any, user: UserSession, payload: StepUpPayload ) { const payloadDigest = createHash('sha256') .update(`${user.id}:${payload.action}:${payload.targetId}:${payload.nonce}`) .digest('hex'); const stepUpKey = `auth:stepup:${user.id}:${payloadDigest}`; // Atomic retrieval and immediate deletion ensures single-use invariant const expectedChallenge = await redis.getdel(stepUpKey); if (!expectedChallenge) { throw new SecurityError('Invalid, expired, or previously consumed step-up challenge.'); } const authenticator = user.authenticators.find( (auth) => auth.credentialID === credentialResponse.id ); if (!authenticator) { throw new SecurityError('Unregistered credential submitted for step-up.'); } const verification = await verifyAuthenticationResponse({ response: credentialResponse, expectedChallenge, expectedOrigin: process.env.FIDO2_EXPECTED_ORIGIN!, expectedRPID: process.env.FIDO2_RP_ID!, authenticator, requireUserVerification: true // Enforces User Verification (UV bit === 1) }); if (!verification.verified || !verification.authenticationInfo.userVerified) { throw new SecurityError('Step-up verification failed: UV bit required.'); } return verification.authenticationInfo; } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: WebAuthn Conditional UI Isolation and Cryptographic Step-Up Invariant

WebAuthn Conditional UI Isolation and Cryptographic Step-Up Invariant defines an industrial-grade behavioral standard for security engineering. Enforces strict cryptographic and contextual isolation between passive Conditional UI passkey autofill assertions and active step-up re-authentication ceremonies. Prevents session fixation, cross-context assertion replay, and downgrade attacks by mandating ephemeral transaction-bound challenges, explicit mediation, and compulsory User Verification (UV) flags for all privileged mutations. Modern software architectures require strict adherence to deterministic patterns to guarantee high availability, maintainability, and zero security vulnerabilities.

Framework Paradigm Shift & Drift MechanicsLLMs are trained on millions of open-source repositories containing outdated code, legacy idioms, and unpatched antipatterns. When coding assistants generate implementations for this stack, they default to common statistical tokens: Conflating Passive Passkey Autofill Assertions with Explicit High-Privilege Step-Up Proofs Without an explicit system instruction file, developers spend hours debugging silent failures.

Failure Modes & Production Blast Radius

Hazard Analysis: What Breaks Without This Rule

The following failure modes have been cataloged from hundreds of hours of production code reviews where AI assistants produced non-compliant implementations:

Failure Mode	AI Symptom (The Anti-Pattern)	Severity	Production Impact & Remedy
AI Hallucination & Deprecation Drift	Conflating Passive Passkey Autofill Assertions with Explicit High-Privilege Step-Up Proofs	Critical	Violating this industrial standard introduces regression bugs, security risks, and unexpected runtime failures in production. Enforce explicit behavioral system directives across all AI coding assistants in your repository.
Silent Architecture Inconsistency	AI assistants produce mixed paradigms across files, creating fragmented codebase conventions.	Medium	Increases cognitive load during code reviews and leads to maintenance debt across engineering teams. Pin project conventions in .cursor/rules, CLAUDE.md, and AGENTS.md so all team agents follow identical guardrails.

Architectural Directives in Detail

Step-by-Step Production Directives

Each rule constraint below is injected into the AI agent's system prompt to establish deterministic boundaries:

Engineers MUST ALWAYS set 'userVerification

Engineers MUST ALWAYS set 'userVerification: required' on the server and client during Step-Up and Re-Authentication operations; 'preferred' or 'discouraged' is strictly forbidden for privileged transactions.

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.