.
@NCSC's latest advice is to use
#passkeys everywhere you can and rely on a
#passwordManager elsewhere. Chris Hosking
@SentinelOne goes further and suggests passkeys remove entire classes of attack.
dailymail.com/news/article-1…
It sounds like great advice and it's technically accurate in many respects, but the gap between theoretical security standards and real-world implementation is significant.
Passkeys are unlikely to see world-wide adoption for many, many years to come; with large companies & government upgrade cycles measured in years.
In theory, that's fine... just use a password manager where passkeys aren't available.
But, it's more nuanced than that and the devil's in the detail.
The vast majority of password managers, particularly in a desktop context, shim the navigator.credentials call and don't just place themselves inside the trust chain, they entirely replace it.
When time permits, I'm about to write up a detailed
#security review of
#Roboform - which until very recently, contained many critical security flaws, including the ability to silently obtain signed passkey challenges via XSS.
Granted, that's a worst-case scenario... but the issue remains even if the password manager is "secure".
The trust a relying party places in passkeys is far greater than
#passwords... but the majority of password managers nullify passkey safeguards.
1. Origin binding
The origin binding aspect is nearly always nullified completely, or severely downgraded. The point of enforcement is no longer the browser, but in Javascript inside an extension.
2. User consent/interaction
FIDO-compliant tokens require both user presence & user interaction. In the native flow, the browser shows a system-level UI prompt that no javascript can supress/access, spoof or dismiss.
Once the navigator.credentials call is shimmed, again, this protection is nearly always nullified or downgraded; replaced with a javascript popup accessible in contexts beyond the current domain. They can fake user consent & presence - and often do.
3. Attestation
After shimming, it's an entirely false attestation... the very premise of passkeys. Private keys are often reduced to JSON objects, accessible across contexts. Their security collapses to the security of the password manager itself.
Many simply fake their AAGUID. Roboform, for example, pretends to be a Microsoft Authenticator for Android. Even if a relying party blacklists untrusted AAGUIDs, the ability to spoof them means any trust placed upon tokens signed by them is misplaced.
The entire AAGUID model is trust-based anyway, to an extent.
4. Phishing resistance
Passkeys are phishing resistant by design, because the browser binds the credential to the relying party's origin.
After shimming, origin checks are handled by javascript inside the extension and are regularly broken. Again, the security of the passkey collapses to the security level of the password manager. Even if it's entirely "secure", the assertion is false. The attestation suggests AAL2 (or 3) but in reality, it's AAL<1.
5. Credential isolation
The native flow isolates credentials across relying parties, such that total failure should only ever affect one origin.
After shimming, the extension has access to all passkeys at once, regardless of the current domain. Any XSS in the site/extension potentially exposes every single passkey assertion - all at once.
The same is true of a password manager with passwords, but it's a regression from the isolation guarantees passkeys are supposed to provide.
6. Replay protection
In the native flow, the browser generates clientDataJSON including the challenge, which the authenticator signs over.
Once shimmed, the entire ceremony is handled in code. If the relying party or extension doesn't implement session-bound challenges, the bearer token could be replayed/stolen.
7. Credential exporting
Private key material is supposed to be stored in a secure enclave or equivalent - such that key material cannot be exfiltrated under any circumstances.
Password managers typically do not leverage these trusted environments, instead using JSON or similar to persist and disseminate key material across devices.
That's (arguably) fine for AAL1/AAL2 requirements, but materially fails for AAL3. Crucially, it fails silently to the relying party.
In summary, using a password manager to manage passkeys nearly always degrades or entirely nullifies the benefits of passkeys themselves, all while making you & the site feel safer.
That might be an acceptable risk to you, but do not assume passkeys remove entire classes of attack. Implementation/deployment matters.