[heraldb]

Problem

Passkey login never works: after the user picks their passkey, the login
page drops them on the password step.

Passkey login needs the PRF extension. Its output decrypts the stored IMAP
password (passkey_login_complete in backend/src/routes/mfa.rs). But
preparePublicKeyOptions in frontend/src/app/page.tsx copies only the
challenge, rpId, allowCredentials and userVerification from the server
options. It drops extensions, so the authenticator never computes a PRF
output. extract_prf_output returns None, the server answers 401 without
logging anything, and attemptPasskey silently falls back to the password
step.

Registration (prepareCreationOptions in SecuritySettings.tsx) does pass
extensions, but the PRF salt is still the base64url string from the
server. WebAuthn requires a BufferSource there. Native browser
authenticators and hardware keys reject or ignore it. Password managers
that also accept the JSON encoding (parseCreationOptionsFromJSON), such
as Proton Pass, decode it, which is why registration seemed to work.

Change

A small prepareExtensions() helper in each file decodes the PRF salts to
ArrayBuffers:

• login: prf.evalByCredential[credId].first
• registration: prf.eval.first

Because those password managers already decoded the string salt the same
way, passkeys registered before this fix keep working; no re-enrollment is
needed.

Testing

Deployed on a self-hosted instance (0.2.4, Firefox on Linux, Proton Pass):

• Before: picking the passkey always led to the password step.
• After: passkey login goes straight to the mailbox, both with a passkey
  registered before the fix and with a newly registered one.

🤖 Generated with Claude Code