6 ms·
Pass the Passkey: A Novel Attack Surface in Passwordless Authentication
- ted_dunning 2mo agoIt is hard to find the content for all of the glitzy ads on this site.
- ikidd 2mo agoThere's ads?
- ted_dunning 2mo agoBut when you do, there are glaring holes these people uncovered.
- Groxx 2mo ago"You must enable DRM to play some audio or video on this page" pops up in the strangest places...
- Terr_ 2mo ago"Oh no, someone might pirate my advertisement, and show it make even more people see it for free!"
- colemannugent 2mo ago>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 threat model here, that synced passkeys should be secure in even in situations involving compromised clients? How?
- ted_dunning 2mo agoIt's not that simple. The stolen file has no clear text passwords and ideally, these passwords can only be decrypted on the right hardware with user confirmation. Of course, eternal and repeated confirmation requests are an anti pattern all their own, but the cloud attestation service not verifying the hardware sounds like a really glaring omission.
- colemannugent 2mo agoIt kinda is. If they use Chrome and it's cloud backed password manager, odds are they use GMail. That plus full access to a trusted device (which you have in this scenario) allows you to change their Google account password. Boom, full persistence. 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.
- vel0city 2mo agoAt least for accounts you want to keep very secure, session cookies are probably very time-limited. Stealing a passkey ensures persistent access in the future. 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.
- Gigachad 2mo ago>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 at a minimum as secure as passwords in a local compromise situation.
- Briannaj 2mo agoThis 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.
- MBCook 2mo agoBoy 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 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?
- nixpulvis 2mo agoHave we standardized a way to backup and export passkeys yet? Do websites commonly allow multiple passkeys to be registered?
- ecesena 2mo agoThere’s FIDO CXF/CXP: https://fidoalliance.org/specs/cx/cxf-v1.0-ps-errata-20260309.html 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.
- tptacek 2mo agoThese are endpoint malware attacks, not attacks on Passkeys per se. This is already a game-over position for an attacker to be in.
- lostmsu 2mo agoYes, there's no security bug here of any kind. The "novel attack surface" already assumes the attacker can execute code as your user.
- asqueella 2mo agoI 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.
- jesseendahl 2mo ago>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".
- asqueella 1mo agoSure, 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/nihn9vo/ 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...
- amluto 2mo agoThis 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 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.
- Nextgrid 2mo agoWouldn’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)? The TPM validates the state of the software TCB, and the software TCB validates the state of the lower layer, and so on.
- amluto 2mo ago> 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.
- j16sdiz 2mo agoUgh? I thought application talks to the OS and the OS that check before it do the TPM thing.
- GauntletWizard 2mo agoThe 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 but the TPM doesn't actually ratchet to prevent downgrade attacks (and would be even worse if it did, because then you'd inevitably brick machines again and again). Instead you trust a long-lived CA and God help you when you need to rotate it. 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.
- SoftTalker 2mo agoIt seems like I have to trust more things that aren't very intuitive and are out of my control for passkeys to really be secure. For passwords, I only need to trust myself. I trust that I don't lose them, don't re-use them, and don't fall for phishing attacks. 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.
- loeg 2mo agoThis is an insane and uninformed take. The malware described in TFA can even more trivially harvest passwords, which have never lived in a TPM. Passwords offer no security benefit over passkeys.
- sandeepkd 2mo agoGood 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.
- mhrsntrk 1mo ago[dead]