Hacker News Reader

Comment by colemannugent | Hacker News Reader

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

View on HN

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

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.

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

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

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

Reply on news.ycombinator.com