Hacker News Reader

Comment by asqueella | Hacker News Reader

I thought the point of storing secrets in hardware TPM and not giving them out into userspace (i.e. passkeys instead of passwords) is protecting against malware as well.

And they claim that for Chrome on Windows:

> Unlike a legitimate user flow that requires user interaction and device unlock, this attack shows how malware can obtain the required signature silently, without user consent, biometrics, device unlock or elevated privileges.

View on HN

The reason why the attack works without “biometrics or device unlock” is because it only works on passkeys that were issued without requiring user verification:

> The Pass-ta-key attack is effective when the relying party does not strictly require user verification. Many relying parties configure WebAuthn’s userVerification parameter as preferred rather than required to support diverse devices and user experiences, making them susceptible to this attack.

So it’s possible for a relying party to mitigate this attack by requiring user verification and checking that the proper bit was set.

Later on, the article outlines an issue with the way that Chrome interacts with Windows Hello during passkey registration and another issue where Chrome dumps the TPM’s master key in process memory, but these are endpoint concerns and have since been patched

While you are technically correct, I know for sure that an RP might be unaware that not requiring user verification means Chrome is free to let malware steal the passkey... (Our Keycloak is (mis)configured like that.)

Do you happen to know if this is because Google had to implement sync in userspace, or is it an inherent limitation that could also affect Apple?

>I thought the point of storing secrets in hardware TPM and not giving them out into userspace (i.e. passkeys instead of passwords) is protecting against malware as well.

This was never a design goal of passkeys as far as I'm aware, and normally passkeys are not generated or stored in a TPM. The primary design goal of passkeys was to make a phishing-resistant primary factor that could compete with the user experience and convenience of passwords, so that folks would actually be interested in using them.

I think you are thinking of security keys, which generate key material in e.g. a YubiKey which offer similar protections to a TPM.

YubiKeys can also be used to generate/store passkeys, but when they are used for passkeys typically they'd be referred to as "device-bound passkeys" rather than just "passkeys".

Sure, not giving out the secrets to userspace was the design goal of security keys and later TPM+Secure enclave. Passkeys happen to enable the use of such hardware for authentication on the web.

This post claims that before 2025 passkeys used to default to device-bound for Windows Hello and Chrome: https://www.reddit.com/r/Passkeys/comments/1o1j3fk/comment/n... — so it doesn't seem as clear-cut as you claim.

I thought it was maybe a case of convenience trumping security, as by definition you can't sync device-bound passkeys. But it's not clear why synced passkeys must be available for malware to steal (especially without user interaction).

I'm not sure now if the Apple's implementation has similar flaws with stealer malware on macOS: you don't see passkeys explicitly mentioned in mac stealer reports, but I couldn't quickly find a confirmation they are safe either...

Reply on news.ycombinator.com