* caveat: HSMs providing FIDO/U2F/WebAuthn eliminate phishing, which provides a lot of value, but you don't need an HSM for that, a software-only implementation would work about as well, and i have no idea why isn't that deployed everywhere yet
Conversation
Replying to
Because folks are using Windows clients and infosec ppl just assume any Windows box is full of malware that would scoop up and exfiltrate the private keys.
1
1
Replying to
everyone recommends password managers and what i describe is strictly better than a password manager
2
5
Replying to
Agree totally. Password manager is probably less hassle/learning curve and more likely to work with all sites though.
1
1
Replying to
what i'm saying is that as a browser vendor -and- website maintainer, adopting webauthn makes authentication flow both more secure and less annoying, so these parties should adopt it
1
4
This is why they included attestation capabilities. They want a solution that can’t be key extracted via a general mechanism. If this catches on, sites will start approving token per manufacturer/model.
1
Browsers should ensure that sites can't determine that information to discriminate based on it.
2
Site you're authenticating to should know nothing except the public key.
1
Generally that’s all they know. And even then, it’s a per-origin public key. But they can also request the key be signed by the pre-installed attestation certificate. And they can chase that cert to a mfgr chain.
2
Attestation doesn't imply a security model based on chaining to known intermediate or root certificates. It's not a strong form of verification and as you mention it can be used to implement user hostile features. That's not true of attestation in general though, just that kind.
Pairing-based attestation isn't user hostile and has compelling security properties. Chaining to an intermediate or root is broken by an adversary extracting the provisioned batch key from even a single device. At best it's a weak way to bootstrap a more meaningful pairing model.
1
1
For example, attestation.app/about is based on pairing and would work fine without chaining to a root as a way to bootstrap. It includes that since it's available, but it's not relevant after the initial pairing is complete. On the other hand DRM depends entirely on doing that.
1
1
Show replies