4 ms·

Silly question: (I have been meaning to dive deeper on this but ...) If I am in a small company, I can give everyone a yubikey and have some process that veri

Silly question: (I have been meaning to dive deeper on this but ...) If I am in a small company, I can give everyone a yubikey and have some process that verifies everyone. Now I want to eliminate cookies / sessions keys. (just go with me). I want to use client certificates - but I only trust the yubikey. I am noodling ways that I can generate client certs, install them fairly easily and sign them with the yubikey. The goal here is that client certs are a really good idea- every request can include one, as opposed to every request including a session cookie / nonce that is open to interception / playback etc etc. And now we have billions of hardware security modules (am including secure enclaves in phones) - so there really ought to be a way through here. My problems include "generating client certs client side" - not something many browsers support and signing that in some sensible fashion But is all seems quiet possible

zie 5y ago
Give up on TLS client certs. The UI for client certs in browsers are miserable, terrible, horrible and insert every other awful adjective you can imagine. Seriously, it's so broken as to be unusable. Everybody knows it, nobody wants to fix it.
- anonymousDan 5y ago
  Interesting - can you give some specific examples of the major UI problems?
  - zie 5y ago
    The scars still haven't healed. ;) see: https://textslashplain.com/2020/05/04/client-certificate-authentication/ https://textslashplain.com/2020/05/04/client-certificate-aut...
- lifeisstillgood 5y ago
  But it is the right way. With a client certificate the end server knows, you don't need to fuck around with cookies and TLS binding and so on. Add a new end point - great to use that during your "session". it just works. One day I will work it out.
  - zie 5y ago
    eh. Client certs are better in theory. Client certs have lots of complexity that's not necessarily easily solved. If you control both ends, then most of the complexity is easily solved, but if you don't, then client certs get much harder. FIDO2 is arguably a much better way to deal with this provable identity problem. The UI for FIDO2 has been worked out and is good enough, etc. The big problem is, it requires handing people Yubikeys(or similar devices).
DenseComet 5y ago
You may be able to go the Webauthn route instead. It won't completely eliminate sessions, but you could instead sign short lived JWTs. The main benefits would be the ability to use any compatible device (ios and andriod natively support it backed by a secure enclave) and the ability to attest that the authenticating device is from a trusted manufacturer, such as Yubico, Apple, Google, etc. I'm not sure if it's possible to sign a request without user input, but if so, you could include a signature with every request.
- lifeisstillgood 5y ago
  I cannot trust JWTs - look the maximum I want to send from a client to a server is a single nonce. Anything else is just adding attack surfaces. Add that one 128bit number has too many already :-)
  - chipsa 5y ago
    Webauthn if no client cert is presented, then generate one on the server and present to the client to be installed. After that, use the client cert?
  - DenseComet 5y ago
    What in the world is your threat model? You need some concept of sessions somewhere, even if it's just a list of which client certs (aka sessions) are valid in case someone looses a yubikey. Those certs should also be short lived, since they don't live in the yubikey itself. And a TLS client cert absolutely adds more than just a nonce. Instead of generating client certs client side, generate a elliptical curve key pair who's public key you sign with the yubikey and send to the server. Then, sign every request with that key and the server can verify it using the public key sent previously. All that can be done in js, without a jwt or sending anything other than a request and signature. It's essentially a client cert. I still don't really understand how much more security it'd get you than bog standard webauthn, especially considering it'd be a custom, less tested system, but you can already do something similar to your idea using standard cryptographic primatives.

zie 5y ago

Give up on TLS client certs. The UI for client certs in browsers are miserable, terrible, horrible and insert every other awful adjective you can imagine. Seriously, it's so broken as to be unusable. Everybody knows it, nobody wants to fix it.

anonymousDan 5y ago
Interesting - can you give some specific examples of the major UI problems?
- zie 5y ago
  The scars still haven't healed. ;) see: https://textslashplain.com/2020/05/04/client-certificate-authentication/ https://textslashplain.com/2020/05/04/client-certificate-aut...
lifeisstillgood 5y ago
But it is the right way. With a client certificate the end server knows, you don't need to fuck around with cookies and TLS binding and so on. Add a new end point - great to use that during your "session". it just works. One day I will work it out.
- zie 5y ago
  eh. Client certs are better in theory. Client certs have lots of complexity that's not necessarily easily solved. If you control both ends, then most of the complexity is easily solved, but if you don't, then client certs get much harder. FIDO2 is arguably a much better way to deal with this provable identity problem. The UI for FIDO2 has been worked out and is good enough, etc. The big problem is, it requires handing people Yubikeys(or similar devices).

DenseComet 5y ago

You may be able to go the Webauthn route instead. It won't completely eliminate sessions, but you could instead sign short lived JWTs. The main benefits would be the ability to use any compatible device (ios and andriod natively support it backed by a secure enclave) and the ability to attest that the authenticating device is from a trusted manufacturer, such as Yubico, Apple, Google, etc. I'm not sure if it's possible to sign a request without user input, but if so, you could include a signature with every request.

lifeisstillgood 5y ago
I cannot trust JWTs - look the maximum I want to send from a client to a server is a single nonce. Anything else is just adding attack surfaces. Add that one 128bit number has too many already :-)
- chipsa 5y ago
  Webauthn if no client cert is presented, then generate one on the server and present to the client to be installed. After that, use the client cert?
- DenseComet 5y ago
  What in the world is your threat model? You need some concept of sessions somewhere, even if it's just a list of which client certs (aka sessions) are valid in case someone looses a yubikey. Those certs should also be short lived, since they don't live in the yubikey itself. And a TLS client cert absolutely adds more than just a nonce. Instead of generating client certs client side, generate a elliptical curve key pair who's public key you sign with the yubikey and send to the server. Then, sign every request with that key and the server can verify it using the public key sent previously. All that can be done in js, without a jwt or sending anything other than a request and signature. It's essentially a client cert. I still don't really understand how much more security it'd get you than bog standard webauthn, especially considering it'd be a custom, less tested system, but you can already do something similar to your idea using standard cryptographic primatives.