HI version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
63% Positive
Analyzed from 1162 words in the discussion.
Trending Topics
#tpm#passkeys#access#passwords#key#password#user#secure#vault#backup
Discussion (26 Comments)Read Original on HackerNews
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.