Comment by loup-vaillant
2 days ago
> Passkeys absolutely do not need TPM.
They do not, but how does the service you’re using know your passkey is secure? For all they know you’re just some gullible user that clicks through every fishing email you get. You’re dumb, weak, helpless, they gotta protect you from this scary world out there, and maybe yourself as well.
They can’t do that if they allow your passkey to be stored anywhere you control. KeepassXC? The second you type in your master password the keylogger will snatch it, and your entire database with it!
Okay, maybe you’re some hot shot cryptographer, you’re using a TKey (think Yubikey, except you have full control), and there’s no way your secret key leaves it even if your main computer is fully compromised. Well, the service doesn’t know that. All they see is your public key and a matching signature.
So, sorry Mr. Security Researcher, we’re gonna have to be safe, and require you to use approved hardware only. Too many (wo)men children out there must be protected, we have no way to tell you’re not one of them, so it’s remote attestation or you’re out. What’ online buying worth for anyway, when you can just cross the ocean?
---
Just so we’re clear, I agree with you here. But don’t forget there are two kinds of passkeys out there: with or without the evil remote attestation. And many companies will push for the remotely attested kind, using the exact argument I used above, except with a straight face.
Or they will just present a false dichotomy: remotely attested passkeys on the one hand, short easy to guess reused everywhere passwords on the other.
> how does the service you’re using know your passkey is secure
That's my business, not theirs. If my password gets stolen, that's my problem, not my bank's. Same deal if my passkey gets stolen. They're welcome to try to educate me on good security hygiene if they want, but what hardware I use to secure my credentials is not something they should get to decide.
On principle I agree with you. And for me I totally want that, in part because I know how to take care of myself and avoid phishing (I got pwned once, but thankfully it was my company’s honey pot, not actual phishing).
Many people aren’t like us. Give them freedom to chose their password without mandating 2FA, and some will lose money to a password database leak & offline guessing. The policy maker knows this, at which point they have a choice: stricter annoying rules with fewer victims, or looser rules with more victims?
Yes, we can mitigate much of this with education, as can we limit vendor lock-in by mandating that the bank does not require any particular device they do not themselves distribute, for free, to their users. (My bank for instance gave me a little device that has a camera, a small screen and a key pad. Upon payment I use the device to scan some QR-code, the device gives me a one-time code that I type, and done.) My point is, some kind of tradeoff remains.
Also banks kinda have to deal with fraud, which presumably costs them money. Stolen passwords mean more fraud, increased costs… that may be incentive enough to enforce stricter rules. And to be honest I’m okay with that, as long as it is accessible. Which in my case means no phone app of any kind.
Come to think of it, there is one law I would pass: for important stuff like banks, no amount of security justifies a lack of accessibility. If I don’t have a smartphone, I should still be able to do online payments. Same if I’m blind. Or both. When I hear all around me about people being utterly unable to do banking, or worse, accessing government online services, without a locked down Android or iOS phone, I’m horrified.
> they have a choice: stricter annoying rules with fewer victims, or looser rules with more victims?
Yep, there's a reason freedom vs safety (or libertarianism vs authoritarianism) is an axis on many political spectrum charts. This is a very common source of tension in politics. As you can probably guess, I usually find myself on the libertarian side of such debates. Freedom is worth the price.
> Give them freedom to chose their password without mandating 2FA, and some will lose money to a password database leak & offline guessing
To be clear, I have no issue with secure defaults. There's only an issue when you start trying to make it impossible for users to compromise their own security, because accomplishing that requires you to take away their freedom to make choices, which I don't think is an acceptable thing to do to mentally sound adults.
There's plenty of competition in the banking space, so normally I'd be fine letting banks and their customers sort this out on their own. But there's not a lot of competition in the OS space, and allowing banks to limit your choice of OS exacerbates that problem.
The fix I've been floating in my head for some time now for a lot of these types of problems in the digital space is some sort of software freedom law guaranteeing users the right to modify software running on devices they own. It would fix so many issues with the software industry, including probably this one, since many common uses of hardware attestation would probably fall afoul of such a law.
2 replies →
> For all they know you’re just some gullible user that clicks through every fishing email you get.
Passkeys are non-phishable. That's part of their schtick. I'm not a huge passkey fan myself, but this is a real benefit.
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.
1 reply →