[samus]

> The service has no way to know whether my browser is talking with a hardware token or emulating one, and it is not privy to the details of how my browser communicates with my token.

The service doesn't necessarily have to know that for the scheme to work. If the user is fine with the browser keeping the keys, then so be it. Browsers have been featuring password managers for a while now, and people happily use them because they have a convenient user experience.

However, if the user wants to use a hardware token, all the browser has to do is be the middle man between service and token. The actual protocol is MITM-proof. Unless you assume your browser is compromised and will screw with your data and your account as soon as you log in. But that's a problem different from user authentication :)

These features are actually nothing new - browsers have supported client certificates and hardware security modules for ages. The features are not in the spotlight and have a horrible user experience though.

[loup-vaillant]

The server can trust that once the user is registered, they’ll be able to detect any key change. After registration, MitM is as you say not possible. And I agree that if the private key came from the hardware token itself, switching back to a password manager without telling the server is impossible, because we’d have to change our private key.

First though, the user must register their key. My claim here is that without a PKI (the sister thread speaks of what I think of attestations) the server has now way to tell where that new key comes from. Could be a hardware token, could be derived from `/dev/urandom`.

This is where it gets interesting: we could generate the user’s key outside the hardware token and copy it somewhere safe¹. The hardware token would then encrypt that key, and we’d keep that encrypted blob somewhere convenient (we don’t care if the blob leaks). Before the token does its end of the protocol, it must first decrypt the blob and extract the key (for internal use only). If we lose the token, we can switch back to a password manager (or set up a new hardware token) by retrieving the original key from its safe location. Since we didn’t change the key, the server doesn’t have to know.

[1] The definition of "somewhere safe" is is left as an exercise for Bruce Schneier. Me, I’ll just wave my hands.

[samus]

You're completely right about everything you wrote. But this is only a problem if the browser is assumed to be malicious. In this case, remote attestation can prove that we are indeed talking with a TPM.

However, if the browser is assumed to be malicious, then authenticating the TPM is pointless. As soon as the user establishes a session via that browser, the user account would be compromised.

[loup-vaillant]

You're correct, a malicious browser can wreck havoc in the user's account. The advantage of a hardware token is that it can limit the damage: if log in and important operations require the hardware token, we can make sure that a compromised browser cannot exfiltrate the user's long term secrets, and cannot permanently hijack the account. Done well enough, the account would only temporarily be compromised (which I reckon is still bad), and the user can easily reclaim control by turning off their computer and log in with another.

As for why I care about compromised browsers, well… I hear malware is still a thing. I'm relatively safe, but I'm one bad vulnerability or bad decision away from letting a Trojan in. So I quite like the idea of protecting my most important long term secret with something that's immune to that. Maybe I'll even get there.

As for the service, most of the time their own stakes are pretty low. They ought to offer good security options, but I'm not sure it's their place to mandate stuff like 2FA.