Prompt and context
This question tests whether a frontend engineer can integrate a WebAuthn extension into a real end-to-end encryption flow. PRF can provide credential-bound pseudorandom output for deriving client-side key material; it is not a login signature and does not solve multi-device use, backup, deletion, or browser compatibility. A strong answer covers browser APIs, cryptographic boundaries, user experience, and recovery risk.
What the interviewer is evaluating
- Whether you distinguish passkey authentication from PRF key-material use.
- Whether you separate extension support, user verification, salts, derivation, and server storage.
- Whether you handle device enrollment, credential deletion, synchronization, and irrecoverable loss.
- Whether you define fallback, error states, and the boundary that keeps key material off the server.
Clarifying questions to ask first
Clarify the threat model: is the server untrusted, is the client supply chain in scope, and is cross-device sync required? Is the data encrypted as a whole or by field, and can users accept permanent loss after losing credentials? Are target browsers and WebViews controlled, and may users register multiple passkeys? Which ciphertext, salts, credential IDs, and versions must the server store?
A 30-second answer framework
I would treat PRF as a source of client-side key material, not use a login assertion as an encryption key. During registration, create or select a PRF-capable credential and generate an unpredictable salt per purpose. During unlock, perform an assertion with the PRF input, derive a wrapping key with a standard KDF in the browser, and unwrap a data key. The server stores public keys, salts, ciphertext, and versions, never PRF output. I would check actual extension results and user verification, prepare multi-credential recovery or an explicit loss warning, and refuse to claim end-to-end encryption when PRF is unavailable. I would expand support only after measuring failures, recovery, and compatibility.
Step-by-step deep dive
1. Separate authentication from encryption keys
WebAuthn login returns a signature over a challenge to prove possession of a credential. The PRF extension produces credential-associated pseudorandom output from an input. A signature, credential ID, or client-extension JSON must not be used directly as an AES key. The design needs an independent data key and an explicit derivation and wrapping relationship.
2. Design registration and salts
Request the PRF extension during registration and require user verification. Generate a random salt per encryption domain or key version, then store the salt, credential ID, and algorithm version as public metadata. A salt is not secret, but purposes must be separated; changing purpose or rotating a key requires a new salt. Check the returned client extension output instead of inferring support from the request.
3. Design unlock and derivation
Fetch salts and ciphertext metadata from the server, then perform an assertion with the PRF input. Validate the returned extension structure and length in the browser, derive a wrapping key with a standard KDF, unwrap a randomly generated data key, and decrypt the content. Keep PRF output and intermediate keys in memory only as needed; never put them in logs or telemetry.
4. Handle capability detection and compatibility
Use documented capability checks and getClientExtensionResults() to inspect the actual result. Distinguish unsupported extensions, user cancellation, an uninitialized credential, and network failure. W3C implementation status still needs verification across target browsers, operating systems, and WebViews; one browser’s success is not a platform guarantee. Record the compatibility matrix and minimum versions in the rollout policy.
5. Design multiple devices and recovery
Enroll a separate credential per device and keep a separately wrapped copy of the same data key for each one. A new device needs an already-unlocked device, a recovery key, or a controlled invitation to rewrap the data key; a server login alone must not decrypt it. If every credential is deleted and no recovery material exists, say plainly that the data is unrecoverable and obtain confirmation before enabling the feature.
6. Plan fallback and migration
When PRF is unavailable, keep a server-readable encryption mode, guide the user to a supported browser, or block end-to-end mode, depending on the threat model. Label the fallback explicitly; do not mix security levels in one UI. Version algorithms, salts, and ciphertext formats so future migration and old-credential revocation remain possible.
Model high-quality answer
I would use WebAuthn PRF as client-side key material, never treat a login signature or credential ID as an encryption key. At registration, request PRF, require user verification, generate a random salt per encryption domain, and store the credential ID, salt, and algorithm version. At unlock, fetch metadata, perform an assertion with the PRF input, derive a wrapping key with a standard KDF in the browser, unwrap a randomly generated data key, and decrypt. The server stores public keys, ciphertext, and public metadata; PRF output, intermediate keys, and plaintext stay client-side. I would inspect getClientExtensionResults() to distinguish unsupported, uninitialized, cancelled, and network-error states. Each device gets its own credential and wrapped data-key copy; adding a device requires an unlocked device or recovery material, and losing all credentials is explicitly unrecoverable. If PRF is unavailable, I would show an explicit fallback or block activation, then expand by browser matrix, failure rate, and recovery success.
Common mistakes
- Using a WebAuthn signature, credential ID, or client-extension JSON directly as a symmetric key.
- Checking only that the request contains a PRF parameter instead of checking actual output and initialization.
- Treating salts as secrets or reusing one salt across purposes.
- Sending PRF output to the server or recording key material in logs, tracing, or analytics.
- Designing only the single-device happy path without enrollment, deletion, and recovery.
- Silently switching to a weaker mode while still labeling it end-to-end encryption.
Follow-up questions and responses
Can PRF output be used directly as an AES-GCM key?
Use a standard KDF and domain separation first, then derive a fixed-length wrapping key. Do not expose protocol output to several encryption purposes. Generate a random data key and wrap it; do not make every ciphertext key a direct function of the credential.
Can the server unlock a user on another device after login?
The server may provide salts, ciphertext, and credential metadata, but cannot reconstruct PRF output from a login. An unlocked device, a recovery key, or an explicitly designed key-sharing flow must wrap the data key for the new device.
How do you know a browser really supports PRF?
Declare the extension, read the client-extension output from the assertion, and check expected fields, length, and error states. Maintain an empirical matrix for target browsers, operating systems, and WebViews. A capability API says that an extension can be requested; it does not replace a real ceremony.
Is end-to-end encryption still safe if a server-delivered script is injected?
PRF does not solve an active tampering of the frontend script. You also need content security policy, dependency and release integrity, sensitive-operation isolation, and auditing. State clearly that “the server cannot read historical ciphertext” and “the client runtime is trusted” are different assumptions.