Live data from Hacker News

Pass the Passkey: A Novel Attack Surface in Passwordless Authentication

unit42.paloaltonetworks.com

31–40 of 54 posts

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

#31
post #25
post #20

This is someone related to a major TPM pet peeve of mine: the TPM only really cares about global device state and has no concept that a device may be a multi-user system, have multiple processes with different security levels, have multiple tenants, etc. For example, it really ought to be possible to seal a secret such that it can only be unsealed if PCRs have certain values (the usual TPM thing) and the requester of…

I'm not even sure why OS exposes TPM directly to applications instead of having a virtual store for credentials that could be backed by whatever. UPD. nvm, that's not what's happening

> having a virtual store for credentials that could be backed by whatever.

An OS can do this. But it’s extremely awkward for an OS to do so in a way that is itself TPM-backed without kludging something disgusting on top of the TPM2 formats using OS-managed state, severely restricted functionality, and probably losing compatibility with the broader TPM ecosystem.

It didn’t have to be this way. The TPM authorization format could have had a field like “OS-managed identity” that the OS’s TPM stack would validate. And maybe even cool features like a standardized way for the OS to measure an application and for the application to use those measurements in its authorization. But none of this exists.

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

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

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

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.

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

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

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.

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

#34

>4. Using the hash of that handshake, the attacker interacts with the victim’s TPM and uses the extracted identity key to sign the handshake hash together with the assertion request Huh? If you have this level of local privileges you can just read session cookies from the browsers store? I guess stealing all the keys is notable, but you can manipulate any password manager with this level of access right? What's the t…

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

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

#35
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 elevated privileges.

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

#36
post #32

Earlier quoted context omitted.

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

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 implies there's another form of recovery, which likely means that key is only as secure as the other recovery options. And when it comes all the way back to the master key to your manager itself the loop falls somewhat apart.

It's a hard problem, but passkeys aren't ready for me yet.

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

#37
Good for awareness but its not Novel at all. Its an incomplete, sensational and one sided PR by a given company

1. There is nothing novel about this, its a known behavior and has been in public domain for a while

2. The article talks about syncable passkeys, however it fails to bring into discussion about the concept of Backup eligible and Backup state which are core to this topic.

3. The core selling point for passkey is its phishing resistant capability which is not even discussed once in the article

4. The authenticator implementation gives a lot of flexibility to the party implementing it and it also creates a room for abuse. There is a trade off between usability (synching credential between devices) and security.

5. Its just a glorified managed password which is PHISHING RESISTANT so still a lot better choice than using passwords alone.

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

#38
post #13

Earlier quoted context omitted.

There’s FIDO CXF/CXP: https://fidoalliance.org/specs/cx/cxf-v1.0-ps-errata-2026030... To my understanding both Apple Passwords and the Android equivalent allow you to export passkeys to a different app (password manager), but I haven’t tried it yet. If anyone has direct experience I appreciate to know how it was.

I can confirm it works on iOS 27. I haven’t tried elsewhere though

I think it’s a 27 feature.

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

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

There is nothing stopping people from using passkeys with MFA. I’ve seen them do it. It’s against the suggestion, but they can do it.

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

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

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

Post reply on HN