How Passkeys Protect Your Identity Vault in CardanoWall

A passkey in CardanoWall is not your identity. It is the key that unlocks an encrypted copy of it. Your real identity is a 32-byte Identity Seed; the passkey just lets your own device open the encrypted vault that holds that seed, so you don't have to paste it every time you sign or decrypt.

Face ID, Touch ID, Windows Hello, a synced platform passkey, or a compatible hardware key can all serve as that daily door. Behind the door sits ciphertext the CardanoWall server cannot read. That separation — the seed is the identity, the passkey is only an unlock factor — is the whole design.

What problem do passkeys actually solve?

They make strong identity storage usable day to day.

Without a convenience layer, every returning user would have to paste their Identity Seed every time they wanted to sign or decrypt something. That is secure in a narrow sense, but it is awkward — and awkward security tends to decay into unsafe security. People copy secrets into the wrong place, leave them in plain notes, or simply stop using the tool.

Passkeys remove that friction. CardanoWall keeps an encrypted vault for your account, and your own device unlocks it after a user-verification step (a fingerprint, a face scan, a PIN, a tap on a hardware key). You get one-tap access without handing CardanoWall a plaintext copy of your seed.

What is a passkey here?

A passkey is a WebAuthn credential — the same public-key sign-in technology behind "log in with Face ID" across the modern web.

In the FIDO and WebAuthn model, a credential is created for a specific relying party (here, CardanoWall's domain), and the private half is held by an authenticator. That authenticator might be built into your phone or laptop, synced through a passkey provider, or held on a separate hardware security key.

For the identity vault, plain sign-in is not enough. CardanoWall needs the authenticator to release some high-entropy secret material into the browser so the browser can decrypt the vault. That is exactly what the WebAuthn PRF extension provides.

What is WebAuthn PRF, in plain terms?

PRF stands for pseudorandom function. A PRF-capable authenticator can produce a secret output that is unique to a given credential, relying party, and a salt the application supplies — and it produces the same output every time for the same inputs.

CardanoWall derives that salt deterministically from your account identifier, so the PRF output is scoped to your account: the same physical key plugged into a different account produces different material and cannot open the wrong vault. The browser then uses the PRF output as the key that unwraps your vault.

The user-level summary is short:

the authenticator keeps its own secret and never exports it;
the browser only sees unlock material during the ceremony itself;
the server only ever stores encrypted vault ciphertext;
the server cannot reproduce the PRF output on its own.

That is what turns your passkey into an unlock factor for the vault rather than a copy of the secret inside it.

What exactly gets encrypted?

Your account's identity bundle.

One account can hold several identities. The bundle records each identity's Identity Seed and its private label, and the whole bundle is encrypted before it is ever stored. The vault is one ciphertext row per account — opaque service state, not custody.

CardanoWall encrypts it as an age-v1 ciphertext addressed only to WebAuthn-PRF (fido2prf) recipient stanzas — one stanza per registered passkey. Any one of your registered passkeys can open the vault after a successful ceremony; the implementation refuses to build a vault that carries any other kind of recipient, so the encryption stays symmetric-only by construction.

If there is no registered passkey, there is no server-side opening path at all — and that is fine, because the seed itself is the real portable identity. You can always restore from the seed.

Why is a passkey-wrapped vault safer than a password-protected one?

Because there is no password-derived stanza to grind offline.

When an attacker steals a file protected by a user-chosen password, they can run guesses against it locally, as fast as their hardware allows. That is the classic offline brute-force problem, and weak or reused passwords lose it.

CardanoWall's hosted vault is not built around a password. It is wrapped to authenticator-held PRF material — a random 256-bit key that lives inside your device. A database leak therefore hands an attacker ciphertext only: no password hash to attack, no seed to read. This is also why passkeys are appealing for daily access in general — they sidestep phishing and password reuse while keeping the server away from the identity secret entirely.

What about quantum attacks on the vault?

Here it pays to be precise rather than dramatic.

The hosted vault deliberately contains no asymmetric public-key recipient stanzas. That matters because the large-scale quantum attack people worry about — Shor's algorithm — targets public-key systems. The vault's confidentiality is symmetric-only: a passkey's 256-bit PRF output wraps it, and there is no public key in the design for a Shor-style attack to aim at.

Against a symmetric key, the relevant generic quantum speedup is Grover-style search, usually described as roughly halving the effective security margin. For a 256-bit key that leaves about a 128-bit effective margin — still an enormous number.

So the honest claim is not "quantum attacks are impossible." It is narrower and sturdier: the hosted vault has no password-derived brute-force surface, no public-key target for Shor, and a symmetric-key margin that stays very high even under generic quantum-search assumptions. Less flashy, but it is the claim a security reader can actually trust.

Why not just use a Cardano wallet to unlock?

Because signing a challenge is not a stable vault key.

A wallet signature is genuinely useful for some public claims, but it is a poor primitive for re-deriving a secret that has to decrypt the same vault across devices, browsers, wallet versions, and changing hardware support. Tie your vault to a wallet and you have quietly turned wallet behavior into account recovery.

CardanoWall keeps these roles separate:

the Identity Seed derives your Label 309 signing and receive keys;
passkeys unlock the hosted vault;
a Cardano wallet signature is reserved for explicit, wallet-bound records when you deliberately choose that path.

Synced passkey or hardware key — which should I use?

Both work; the right choice depends on the value of the identity.

Synced passkeys are the convenient default. They can reappear on a new device through your provider — an operating-system keychain or a password manager, depending on your setup — which makes ordinary recovery much easier. A synced passkey inherits the security and recovery model of whatever provider holds it.

Hardware keys are more controlled. Because access requires the physical device, they suit high-value or shared team identities where you want the factor bound to something you can lock in a drawer.

A reasonable rule: match the passkey style to what the identity is worth. For most people, a synced platform passkey is a fine daily driver. For sensitive team identities, a hardware key plus a carefully stored seed is often the better trade-off. The article on synced passkeys versus hardware keys walks through the differences in detail.

What if my browser or key doesn't support PRF?

Then CardanoWall falls back to the seed path — by design.

WebAuthn PRF support depends on the combination of browser, operating system, and authenticator. CardanoWall feature-detects whether that combination can do PRF before enrolling a vault factor, so you are never walked into a vault you would be unable to unlock later.

Seed-only access is not a degraded mode. It is the sovereign path: the seed is the identity, and everything else is convenience layered on top when the platform can support it safely.

What can still go wrong?

Passkeys close off a large class of risks, but a few realities remain, and it is better to name them plainly.

A stolen seed is full identity compromise. Whoever holds your Identity Seed is that identity. The response is to create a new identity and deactivate the old one — not a password reset, because there is no password.
An unlocked session is a live target. While the vault is unlocked, your seeds and derived private keys live in browser memory so you can sign and decrypt. CardanoWall keeps that material outside React state and zeroizes it on lock and sign-out on a best-effort basis, but a malicious script or extension in an unlocked session can still read in-memory secrets. A strict content-security policy and minimal scripts reduce that risk; they cannot eliminate it. On a machine you don't fully control, lock the vault when you step away rather than leaving an open session behind.
Removing a passkey is not retroactive. When you remove a factor, the client re-encrypts the vault to the remaining factors and the old ciphertext row is hard-deleted, so the removed key can no longer open the current vault. But if an attacker already used that passkey before you removed it, removal cannot undo what they did. See what happens if you remove a passkey.
Lose everything and the door is gone. If you lose every copy of the seed and every unlock factor, future use of that identity is gone. Proofs you already published still verify forever — they live on Cardano, not in your vault — but you can no longer act as that identity.

Passkeys reduce risk. They do not remove your responsibility to protect the seed and the device.

The short version

Passkeys make CardanoWall usable without making CardanoWall a custodian.

The server stores encrypted vault ciphertext and nothing it can decrypt. Your passkey lets your browser derive the material that unlocks it. Your Identity Seed remains the portable root of the whole identity. Save the seed, then lean on passkeys for daily access. Convenience on top, sovereignty underneath. If you want to understand why the seed still matters even with passkeys enrolled, read why the identity seed still matters.