Security: initial password creation on passwordless accounts lacks step-up and session handling (SUF-02)

[devondragon]

Summary

POST /user/setPassword (adding an initial password to a passwordless / passkey-only account) requires only an authenticated session. It performs no step-up (fresh WebAuthn assertion or recent-auth proof), and it does not invalidate or rotate sessions after the credential is added.

Severity: Medium (requires a pre-existing authenticated session; additive-only; documented limitation)

Affected code

• src/main/java/com/digitalsanctuary/spring/user/api/UserAPI.java — setPassword (~488/511) only null-checks the principal.
• src/main/java/com/digitalsanctuary/spring/user/service/UserService.java — setInitialPassword (~837), persistInitialPassword (~873): no session invalidation.

Details

The endpoint is correctly guarded to initial password only — hasPassword() is checked at both the API and service layers, so it cannot overwrite an existing credential, and the account's existing passkey remains valid. However, on a passwordless account there is no way to prove the caller is the legitimate owner beyond "the session is authenticated," and no step-up primitive exists in the library yet. This is acknowledged in the endpoint Javadoc and MIGRATION.md.

Impact

A caller who already controls an authenticated session on a passwordless account can add a durable password credential (additive persistence; reversible via the email reset flow). This is a persistence concern, not privilege escalation or lockout.

Recommended fix

• Implement a WebAuthn step-up assertion bound to user, session, action (set-password), RP ID, origin, challenge, and short expiry, and require it here.
• Until step-up exists, consider disabling this endpoint by default or requiring a consumer-provided step-up service.
• Note: simply invalidating other sessions after the change would evict the legitimate user (default keeps the current session), not the attacker — step-up is the real remedy.
• Add endpoint-level tests for the auth/step-up/session behavior of /user/setPassword (currently only service-level coverage exists).

---

Identified during a code-first security assessment of the current main branch.

[devondragon]

WebAuthn Step-Up for Passwordless Sensitive Operations (SUF-02)

• Finding: SUF-02 — a stolen passkey-only session can perform credential-altering operations (add a password, delete/rename a passkey) with only a session, no fresh proof of possession.
• Library issue: Security: initial password creation on passwordless accounts lacks step-up and session handling (SUF-02) #328
• Demo-app issue: Add WebAuthn step-up ceremony (JS + UI + E2E) for passwordless sensitive operations SpringUserFrameworkDemoApp#75 (client ceremony JS + UI + E2E)
• Status: Design approved; spec for implementation planning.

Goal

Provide a reusable step-up primitive so that, when enabled, sensitive operations on passwordless (passkey-only) accounts require a fresh WebAuthn assertion ("step-up") before proceeding — closing the gap where a session alone authorizes durable credential changes. Unify this with the existing current-password reauthentication so there is a single "critical-operation gate": prove a current credential (password if set, else a recent WebAuthn step-up).

Decisions (from brainstorming)

1. Scope: a general step-up primitive reused by setPassword, passkey delete, and passkey rename (not a setPassword-only fix). Account-delete / GDPR step-up is out of scope for now (see Out of Scope).
2. Model: a session-bound recent-step-up marker — one assertion ceremony authorizes a sensitive op for a short window — rather than embedding an assertion in every sensitive request.
3. Rollout: opt-in via user.security.stepUp.enabled (default false). When off, behavior is unchanged (documented residual risk remains). Planned to become the default in the next major version.

Architecture

New / changed components

• WebAuthnRelyingPartyOperations bean (library-owned). A Webauthn4JRelyingPartyOperations built from the existing WebAuthn repositories (WebAuthnUserEntityBridge as the PublicKeyCredentialUserEntityRepository, the credential repository as the UserCredentialRepository) plus rpId and allowedOrigins from WebAuthnConfigProperties. In Spring Security 7 the http.webAuthn() DSL also consumes a WebAuthnRelyingPartyOperations bean when present, so login and step-up share one instance (no divergence in RP config). Guarded by @ConditionalOnMissingBean so consumers can override.
• StepUpService (interface + default DSStepUpService):
  • PublicKeyCredentialRequestOptions createChallenge(User user, StepUpAction action, HttpServletRequest request) — calls createCredentialRequestOptions(...) scoped to the user's credentials (allowCredentials), stores the returned options + {action} in the HTTP session, returns options to the client.
  • void completeStepUp(User user, StepUpAction action, PublicKeyCredential<AuthenticatorAssertionResponse> assertion, HttpServletRequest request) — rebuilds RelyingPartyAuthenticationRequest(storedOptions, assertion), calls authenticate(...), asserts the returned PublicKeyCredentialUserEntity maps to the current user, then stamps a marker.
  • void requireRecentStepUp(User user, StepUpAction action) — when enabled and no valid marker → throw StepUpRequiredException; no-op when disabled; consumes the marker on success (single-use).
  • boolean hasRecentStepUp(User user, StepUpAction action) — non-throwing check (for /auth-methods-style UI hints).
• StepUpApi (@RestController, /user/stepup):
  • POST /user/stepup/options — body { action }; authenticated; returns PublicKeyCredentialRequestOptions JSON.
  • POST /user/stepup/verify — body { action, assertion }; authenticated; verifies and stamps the marker; returns success/failure JSON.
• StepUpAction enum: SET_PASSWORD, DELETE_PASSKEY, RENAME_PASSKEY. Each maps to a stable string (set-password, …) used in the session marker and client contract.
• StepUpRequiredException → mapped to HTTP 401 with a distinct response code (step-up-required) so the UI can launch the ceremony. Distinct from lockout (423) and wrong-password.

The step-up marker

• Stored as a single HttpSession attribute: a Map<StepUpAction, Instant> (action → expiry). Never persisted to DB.
• Bound to: the current session (session attribute), the user id (validated on read), the action, and an expiry (now + ttlSeconds, default 300s).
• Single-use: requireRecentStepUp removes the marker for that action once it authorizes an operation, so one ceremony authorizes exactly one sensitive op. A second op requires a new ceremony.
• The assertion itself is bound to user, RP ID, origin, and the server-issued challenge by Webauthn4JRelyingPartyOperations.authenticate(...); we additionally bind session, action, and expiry.

Critical-operation gate (unification with SUF-04)

Introduce one gate reused by the sensitive endpoints:

requireCredentialProof(user, action):
    if userService.hasPassword(user):
        verify current password  (existing path: lock check + loginFailed/loginSucceeded — SUF-04)
    else:
        stepUpService.requireRecentStepUp(user, action)   // no-op unless stepUp.enabled

• UserAPI.setPassword (passwordless by definition — it is hasPassword-guarded) → requireRecentStepUp(user, SET_PASSWORD).
• WebAuthnManagementAPI delete/rename → today requireCurrentPasswordIfSet is a no-op for passwordless accounts; it becomes requireCredentialProof(user, DELETE_PASSKEY|RENAME_PASSKEY), so passwordless accounts now require step-up (when enabled) while password accounts keep the current-password path unchanged.

Configuration

• user.security.stepUp.enabled (boolean, default false) — master switch. When false, requireRecentStepUp is a no-op and the /user/stepup/* endpoints still function (harmless) but nothing requires them.
• user.security.stepUp.ttlSeconds (int, default 300) — marker lifetime.

Documented in CONFIG.md (Security Settings) and dsspringuserconfig.properties. Note the planned next-major default flip.

Error handling

Situation	Result
Sensitive op, enabled, no/expired marker	401, code step-up-required
/stepup/verify bad/expired challenge, or asserting user ≠ session user	401
Sensitive op, disabled	proceeds as today (no-op gate)
Password account (any of these ops that apply)	existing current-password path (incl. SUF-04 lockout)

WebAuthn assertion failures are proof-of-possession failures, not password guesses; they do not feed LoginAttemptService.

Backward compatibility

• Default enabled=false ⇒ no behavior change; all existing tests pass unmodified.
• New endpoints are additive.
• The shared WebAuthnRelyingPartyOperations bean must reproduce the DSL's current RP config (rpId, allowedOrigins) so login behavior is unchanged; covered by existing WebAuthn tests plus a new assertion-parity check.

Testing strategy

• DSStepUpService unit: marker stamped on successful verify; expired marker rejected; action mismatch rejected; user mismatch rejected; single-use (consumed) ; disabled ⇒ requireRecentStepUp no-op; verify with a mocked WebAuthnRelyingPartyOperations.
• StepUpApi (MockMvc): options returns JSON options; verify stamps marker; CSRF required; unauthenticated rejected.
• Sensitive-op integration: with enabled=true, passwordless setPassword / passkey delete / rename → 401 without a marker, succeed with one; with enabled=false, existing behavior (existing tests unchanged).
• RP-operations parity: the login WebAuthn flow still works with the library-owned bean present.

Consumer / demo responsibility

The library ships only the server side. The consuming app must add the client ceremony (options → navigator.credentials.get() → verify → sensitive call) and handle the step-up-required 401. Tracked in demo-app issue #75, which also carries the Playwright E2E for the enabled path. The library feature is not fully validated end-to-end until #75 lands.

Out of scope

• Step-up for account delete / GDPR delete (could reuse the same primitive later; not in this pass).
• Rate limiting of the /stepup/* endpoints (separate hardening; SUF-06 tracks anonymous-endpoint rate limiting generally).
• Making step-up the default (next major).

Risks / open questions

• Shared RP-operations bean: must exactly match the DSL's implicit configuration; if Spring Security's DSL does not consume a context WebAuthnRelyingPartyOperations bean in the resolved version, fall back to constructing a second instance for step-up from the same repositories (login unaffected). To confirm during implementation.
• allowCredentials scoping: the challenge should list the user's credential ids so the authenticator prompts for the right passkey; confirm the options request supports per-user scoping.