5 ms·

What does this solve exactly? We already have client-side certificates in TLS, am I missing something?

tialaramex 8y ago
Aside from the awful UX of client certs, which we could imagine being fixed, FIDO tokens are very narrowly conceived to solve the exact second factor problem - and nothing else. If you do client certs you've got this whole identity thing baked into the certs. But the FIDO token doesn't have an identity, it only knows how to prove it's still the same FIDO token you had before. So that's immediately much better. If I use a client cert to sign into GitHub and Facebook, it's a matter of moments for that to be correlated. If I share the client cert with my sister or a colleague, again easily correlated. But with WebAuthn there's nothing to correlate. The only way to check that Bill and Suzy are using the same FIDO token is to wait until say Bill tries to log in, and ask his token to prove that it's still Suzy's token. This requires a physical interaction (e.g. button press) from Bill. If the guess was wrong you learn nothing but Bill notices it didn't work. So, maybe, if you're nearly certain but just want to be 100% that could work, but ordinarily it's not viable at all.
- Freak_NL 8y ago
  Also with a decent WebAuthn implementation (e.g., FIDO U2F hardware tokens, or using a TPM), the private key material cannot be copied by a compromised device, or even by someone with direct access to the hardware (unless they actually disassemble the hardware with quite professional hardware). Client-side certificates are a great technology, but you can copy the certificates without the owner knowing it. Getting the password is just a matter of social engineering or (further) compromising the device. It beats plain username plus password though!
  - MrStonedOne 8y ago
    You tout it as an upside that it can't be copied. But its really not. How to prepare for losing tokens is the major barrier to entry for 2fa, and it will be why it never sees mass adoption.
  - baybal2 8y ago
    Well, that has been solved by smartcards for 2 decades already... More importantly, PKCS11 layer is completely independent of the browser internals, and works with just anything relying on common pk crypto: http, imap, smtp, sip...
- baybal2 8y ago
  Nothing prevents delaying auth with a client cert until the user enters a login. That's what a great lot of people don't understand about TLS. Your cert ID don't have to amount to user ID. You can let your user enter login as usual in a web form, or use a stored cookie for that, and only then look up if client cert matches the user record. Moreover, for as long as you can be confident about cookie security, you can forego authenticating every connection in favour of using a session cookie once you did a smartcard auth. One last tip: ensure keepalives are handled properly, so you don't have to reauth TCP connections over and over. That's the not so secret sauce to fast client side certificate auth.
- baybal2 8y ago
  > FIDO tokens are very narrowly conceived to solve the exact second factor problem - and nothing else. Well, just that has been done completely flawlessly by smartcards for two decades already. Introducing a competing standard may just end with neither of them getting enough support.
  - emj 8y ago
    Smartcards are not flawless, they never just work, there is always something that fails, I'm not saying that USB is flawless, but there is absolutely room for improvement here.
    - baybal2 8y ago
      My experience on windows was just plug and play. I plug my bank's usb smartcard, wait for drivers to install, and just open its online banking page in Edge. As simple as that.

Aside from the awful UX of client certs, which we could imagine being fixed, FIDO tokens are very narrowly conceived to solve the exact second factor problem - and nothing else. If you do client certs you've got this whole identity thing baked into the certs. But the FIDO token doesn't have an identity, it only knows how to prove it's still the same FIDO token you had before. So that's immediately much better. If I use a client cert to sign into GitHub and Facebook, it's a matter of moments for that to be correlated. If I share the client cert with my sister or a colleague, again easily correlated. But with WebAuthn there's nothing to correlate. The only way to check that Bill and Suzy are using the same FIDO token is to wait until say Bill tries to log in, and ask his token to prove that it's still Suzy's token. This requires a physical interaction (e.g. button press) from Bill. If the guess was wrong you learn nothing but Bill notices it didn't work. So, maybe, if you're nearly certain but just want to be 100% that could work, but ordinarily it's not viable at all.

Freak_NL 8y ago
Also with a decent WebAuthn implementation (e.g., FIDO U2F hardware tokens, or using a TPM), the private key material cannot be copied by a compromised device, or even by someone with direct access to the hardware (unless they actually disassemble the hardware with quite professional hardware). Client-side certificates are a great technology, but you can copy the certificates without the owner knowing it. Getting the password is just a matter of social engineering or (further) compromising the device. It beats plain username plus password though!
- MrStonedOne 8y ago
  You tout it as an upside that it can't be copied. But its really not. How to prepare for losing tokens is the major barrier to entry for 2fa, and it will be why it never sees mass adoption.
- baybal2 8y ago
  Well, that has been solved by smartcards for 2 decades already... More importantly, PKCS11 layer is completely independent of the browser internals, and works with just anything relying on common pk crypto: http, imap, smtp, sip...
baybal2 8y ago
Nothing prevents delaying auth with a client cert until the user enters a login. That's what a great lot of people don't understand about TLS. Your cert ID don't have to amount to user ID. You can let your user enter login as usual in a web form, or use a stored cookie for that, and only then look up if client cert matches the user record. Moreover, for as long as you can be confident about cookie security, you can forego authenticating every connection in favour of using a session cookie once you did a smartcard auth. One last tip: ensure keepalives are handled properly, so you don't have to reauth TCP connections over and over. That's the not so secret sauce to fast client side certificate auth.
baybal2 8y ago
> FIDO tokens are very narrowly conceived to solve the exact second factor problem - and nothing else. Well, just that has been done completely flawlessly by smartcards for two decades already. Introducing a competing standard may just end with neither of them getting enough support.
- emj 8y ago
  Smartcards are not flawless, they never just work, there is always something that fails, I'm not saying that USB is flawless, but there is absolutely room for improvement here.
  - baybal2 8y ago
    My experience on windows was just plug and play. I plug my bank's usb smartcard, wait for drivers to install, and just open its online banking page in Edge. As simple as that.