>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?
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 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?
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 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.
It 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.
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.
9 comments
[ 0.23 ms ] story [ 12.1 ms ] threadHuh? 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?
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?
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.
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. 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.