Live data from Hacker News

Pass the Passkey: A Novel Attack Surface in Passwordless Authentication

unit42.paloaltonetworks.com

41–50 of 54 posts

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

#41
post #32

Earlier quoted context omitted.

From account security POV, it is better to disallow backup or export passkeys. Each device should get their unique key. This would be quite bad from usability or privacy pov, I guess.

It's ao comically bad it proves the while thing is a joke unless you're trusting Apple or Google to sync and back them up for you. One cynical angle at why the backup is being slow-rolled is because the major players have an incentive to not do it. They want you dependent on them and locked into their ecosystem. It's completely insane to treat a credential to an account as something that cannot be backed up. It impli…

>They want you dependent on them and locked into their ecosystem.

This is a strange conclusion to come to when clearly a lot of effort was put into developing an open standard (Credential Exchange Format) to make it easy and secure to move credentials between vendors/ecosystems, without opening end-users up to phishing attacks on credential export.

If big tech wanted to lock people in, it seems like it would have been a lot easier to just... not create an open standard.

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

#42
post #22
post #9

Boy I’m so tired of people trying to make clever attack names. They don’t help remember things, there are too many. So all 3 “pass-ta-key” attacks are not attacks on passkeys, they’re attacks on the Google vault. And if you get access to the vault, then you get everything. OK. And if you get access to a synced traditional password vault, then you get everything. So… meh. These are bugs, they will be fixed. Good on th…

> And if you get access to the vault, then you get everything. OK. And if you get access to a synced traditional password vault, then you get everything. No? It’s why 2FA exists. I have an email with password of 5 characters only and the password leaked decade ago, never changed it and no one accessed it because it has 2fa. I can share my whole password vault and I would not care about it because it’s useless without…

Majority of second factors are phishable. If you are using a password (phishable) + a phishable second factor (any kind of 6 digit code that you need to type or paste into a text box), you are less secure than if you were using only a passkey.

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

#43

Earlier quoted context omitted.

>that synced passkeys should be secure in even in situations involving compromised clients? I think that is the idea actually. By using secure hardware features it is in theory possible to secure the passkeys even in the case of compromised clients. Like how the iphone uses a security coprocessor to store the decryption keys and face id info out of the reach of iOS. But this isn't overly concerning since it's still a…

This is how I assumed it worked as well. I wasn't aware of the non User Verification method. I thought the passkey was tied to hardware. I thought that was the entire point. How wrong I was it seems.

As far as I can tell, Passkeys is just like ssh keys for normal people. But there's a lot of implementation details which get confused with the base specification. They can be tied to hardware, they can be stored on a secure zone that malware can't reach, but at the core they are pretty much just a pub/private key pair.

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

#44

Earlier quoted context omitted.

It's ao comically bad it proves the while thing is a joke unless you're trusting Apple or Google to sync and back them up for you. One cynical angle at why the backup is being slow-rolled is because the major players have an incentive to not do it. They want you dependent on them and locked into their ecosystem. It's completely insane to treat a credential to an account as something that cannot be backed up. It impli…

>They want you dependent on them and locked into their ecosystem. This is a strange conclusion to come to when clearly a lot of effort was put into developing an open standard (Credential Exchange Format) to make it easy and secure to move credentials between vendors/ecosystems, without opening end-users up to phishing attacks on credential export. If big tech wanted to lock people in, it seems like it would have bee…

Bug tech isn't a single entity. But I strongly believe a different group would have finished this obvious gap by now.

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

#45
post #33

Earlier quoted context omitted.

Have we standardized a way to backup and export passkeys yet? Do websites commonly allow multiple passkeys to be registered?

> backup / export Last I heard this was a major point of contention between two groups, and last I checked, both had extremely valid concerns. > Multiple passkeys I commonly have two software and two hardware keys registered per site.

How is this easier than just using a password manager? Why not standardize the password input mechanism so they reliably update, etc.

I feel like all of the security of passkeys could have been build in a compatible way with new standards and enhancements to existing password interactions.

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

#46
post #33

Earlier quoted context omitted.

> backup / export Last I heard this was a major point of contention between two groups, and last I checked, both had extremely valid concerns. > Multiple passkeys I commonly have two software and two hardware keys registered per site.

How is this easier than just using a password manager? Why not standardize the password input mechanism so they reliably update, etc. I feel like all of the security of passkeys could have been build in a compatible way with new standards and enhancements to existing password interactions.

> How is this easier than just using a password manager?

Easy and Secure are often at odds.

I am using a password manager, I have a passkey saved in it. Should that service go down or have some kind of software problem with that passkey, I have physical ones which also can work for offline services such as my OS logins.

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

#47
post #46

Earlier quoted context omitted.

How is this easier than just using a password manager? Why not standardize the password input mechanism so they reliably update, etc. I feel like all of the security of passkeys could have been build in a compatible way with new standards and enhancements to existing password interactions.

> How is this easier than just using a password manager? Easy and Secure are often at odds. I am using a password manager, I have a passkey saved in it. Should that service go down or have some kind of software problem with that passkey, I have physical ones which also can work for offline services such as my OS logins.

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.

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

#48
post #12

These are endpoint malware attacks, not attacks on Passkeys per se. This is already a game-over position for an attacker to be in.

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

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

#49

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…

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

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...

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

#50
post #46

Earlier quoted context omitted.

> How is this easier than just using a password manager? Easy and Secure are often at odds. I am using a password manager, I have a passkey saved in it. Should that service go down or have some kind of software problem with that passkey, I have physical ones which also can work for offline services such as my OS logins.

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!"

Post reply on HN