Yes, but that’s not the threat model I was alluding to. The threat model was, you get tricked into executing malware, that will steal your passkey (and your entire password database in fact), and log your master password as soon as you use it.
When the passkey is protected behind an HSM (TPM, Yubikey, Tkey…), even a compromise of your main computer can’t steal it. Attackers can still temporarily log in on your behalf, but they can’t do anything with your passkey as long as your computer is turned off. Which means you can un-pwn yourself out of this situation by reinstalling everything (but do keep your HSM!).
Overall, we have several levels of security here:
- Weak password, (potentially reused everywhere). Fished once, pwned everywhere. Not to mention password database leaks.
- Very strong unique password from your password vault (KeepassXC). Note that with automatic login, password managers may provide good phishing resistance. Manual copy pasta is still vulnerable, but at least you only compromise that one account.
- Passkey stored in your password database. Phishing proof as you say, but falls to a keylogger.
- Passkey sorted in a hardware security module. Can’t be stolen ever, save for a vulnerability in the HSM itself, or, if you haven’t set up a password for your HSM, theft.
Clearly that last option is the most secure. Clearly it would be nice if everyone could do that, though we do need a way to recover from the loss or destruction of the HSM (which in the case of the TPM may mean something as mundane as changing your graphics card). Yet often, other ways are more convenient.
Still, I strongly believe companies should not force people into one method or another. Okay, I could maybe tolerate passkeys being forced on me, but not the remote attestation part. Let me manage my own security, with my own tools (preferably open source), thank you very much. There is one use case for which I may approve of remote attestation: work accounts. Because at this point it’s not about the safety of the customer, it’s about the safety of the company itself. It makes sense then that the company (or government agency) impose whatever stringent restrictions on how to access their network. They do have to provide any required tool (company laptop, company palmtop, company dongle…), same way many companies are required to provide individual safety equipment to any of their employees working in hazardous environments.
Yes, I agree that device-bound credentials (DBC?) are a really big deal here. Just wanted to get the story straight.
When it comes to the notion of requiring DBCs without also requiring remote attestation, how do you deal with solving the problem of virtualized credential devices, e.g. swtpm? If some application wants to leverage DBCs, it will make some DBC API call, e.g. call out to a TPM. However, without some sort of attestation scheme, there's no way to verify who/what is on the other end of that API call.
Maybe it's not important for applications to be able to require DBCs without attestation. But at first blush it seems like a valid thing to want.