Pass the Passkey: A Novel Attack Surface in Passwordless Authentication(unit42.paloaltonetworks.com) |
Pass the Passkey: A Novel Attack Surface in Passwordless Authentication(unit42.paloaltonetworks.com) |
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.
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 the unseal operation is tagged by the OS (software TCB) as having a certain identity. The latter part is entirely missing from the TPM spec. (The identity could be a hash of the process, just a UUID, or just about anything else as long as it was reasonably well associated with the process in question. Obviously there are subtleties here.)
If the TPM worked the way I wanted, an unprivileged process running alongside Chrome would be completely unable to use the TPM to pretend to be Chrome.
The TPM validates the state of the software TCB, and the software TCB validates the state of the lower layer, and so on.
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.
UPD. nvm, that's not what's happening
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.
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.
> 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
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".
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 them for disclosing them. But this does not prove that passkeys are terrible. This does not make them less secure than random passwords.
If it wasn’t for the fact that they just happen to be getting passkeys, seems like this wouldn’t be worth a headline or discussing at all. And if they have this level of access, then they also get all the standard password credentials in the vault too, right?
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 threat model here, that synced passkeys should be secure in even in situations involving compromised clients? How?
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 at a minimum as secure as passwords in a local compromise situation.
But I largely agree, if they're able to do this on your system you're already hacked and they can do a ton of very bad things.
I can think of at least a dozen easier ways to do nefarious things with this level of access that are at least that simple. As an example, faking user attribution would be trivial.
How could Google patch this? If the client is compromised and the attacker can manipulate the local TPM or it's equivalent there's no defense.
Of course I also have to trust that whatever service I'm authenticating to does their part correctly, but that's the same either way.
I'm going to continue to use passwords.
1. All sites/services would allow the registration of 5 or more keys, which can be tracked/revoked separately. That way if one device is stolen, you can invalidate that key without affecting others.
2. There are two sets of keys: "Regular Use" and "Backup/Recovery".
3. Attempting to use a Backup/Recovery key prompts to user to confirm that they want to invalidate the Regular keys and promote the backup key(s) to the new regular. In this way, a compromised backup cannot be used in secret.
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.
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.
This would be quite bad from usability or privacy pov, I guess.
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 2fa. Not the case with passkey, glad I never set it up on any of my accounts, pass+mfa is good for 99% of accounts (not sms obviously), rest are public private keys.
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?
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...
The actual reason is people have many devices. I assume this is at least somewhat common, but I still avoid passkeys so IDK.
You're designing a system where we should just be able to backup our own keys if we want to.
It's even worse if you're self-hosting the signing, to the point that despite a ton of work put into making it safe and understood I wouldn't do it with the current design; a bare-state unlock is more predictable and reliable but I'll make sure to regularly exercise my backup key and header.
You can observe the kernel. It’s just extremely awkward because upgrading the kernel will change the kernel.
I thought application talks to the OS and the OS that check before it do the TPM thing.
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.
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.
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.
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.
"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!"