Hacker News Reader

Comment by lifeisstillgood | Hacker News Reader

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

View on HN

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.

Interesting - can you give some specific examples of the major UI problems?

The scars still haven't healed. ;)

see: https://textslashplain.com/2020/05/04/client-certificate-aut...

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.

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).

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.

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 :-)

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?

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.

I am guessing you are suggesting this as an absurdist argument (even if it is feasible !?!!) but I don't get why using client certs is bad? The downsides to session keys in cookies is immense and I don't see JWTs as being materially different.

It appears to me there are two options :

use out of band method to verify a HSM "belongs" to a given person (which has loads of issues) then

1. Use that HSM to establish a bearer token for future requests

2. use that HSM to establish a client certificate which at least avoids the problems of bearer token.

I may of course be very wrong.

PS To me the problems of "replacing passwords with something stronger" boil down to the fact that the vast majority of web sites out there are not protecting anything valuable. I have 300+ entries in my password vault and if I had to walk down the street to a "PKI office" and get my passport stamped to access each one, I would choose maybe five.

I suspect that the vast amount of crap sites out there trying to find ways to make authentication stronger without actually making it less convenient for people i case they stop bothering to sign in, is just undermining the infrastructure we would need to have trustable authentication.

If it's valuable to you, you will make the effort.

Reply on news.ycombinator.com