Live data from Hacker News

Pass the Passkey: A Novel Attack Surface in Passwordless Authentication

unit42.paloaltonetworks.com

51–54 of 54 posts

Re: Pass the Passkey: A Novel Attack Surface in Passwordless Authentication

#51
post #48

Earlier quoted context omitted.

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…

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, m…

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?

Re: Pass the Passkey: A Novel Attack Surface in Passwordless Authentication

#52
post #50

Earlier quoted context omitted.

Why is a password manager a "service" it should really just be a program and as many encrypted backups as you want. Maybe you pay for them to host those backups, but that's a choice you should be able to make.

> Why is a password manager a "service" it should really just be a program "Okay, my password manager is now a program. Oh no, program won't run. Not sure why!" "Glad I have these physical passkeys! Also helps with those airgapped servers at work!"

I'm not against physical keys at all. I have one on my keychain. I'm against making things hard to maintain ourselves. Being dependent on Apple and Google to agree before we can own our own keys is what bothers me.

Re: Pass the Passkey: A Novel Attack Surface in Passwordless Authentication

#54
post #23

Earlier quoted context omitted.

> Wouldn’t that be the job of the software TCB to ensure only the appropriate user is given access (and prevent the user from accessing the TPM directly obviously)? This only works with the current TPM design if there is one “appropriate user”. The real world contains Chrome, BitLocker, various VMs and containers, etc. The TPM does not properly accommodate this world.

The primitives of a tpm ("observations", which in practice map to ca-signing keys of various levels of boot stage) are a very poor match for the real world. In order for them to be usefully consistent, you have to have consistent inputs. That means you can't observe the kernel itself, but instead you observe a key that signs a kernel. This is awful when it's Microsoft signing a series of kernels that advance one-way…

> That means you can't observe the kernel itself, but instead you observe a key that signs a kernel.

You can observe the kernel. It’s just extremely awkward because upgrading the kernel will change the kernel.

Post reply on HN