zlacker

I was messing with implementing webauthn the other day, mainly because I like public key authentication. I was hoping for something sort of like ssh keys. and they were close, so close, to having something good that could replace password auth. and then they break it by requiring a hardware token, Yes, a hardware token is better, but I am not going to require users get a hardware token. there are working software token systems built into the browser but they are gated behind dev tools, again something I am not going to ask of users. and just to spit in whatever goodwill they have left, to make it really unusable, there is this weird mandated "no user interface" policy in the standard. making near impossible to manage keys. The keys are critical in a public key auth system. but "no, we are disallowed, by the standard, to give you an easy mechanism to back up and restore keys"

If I were more conspiracy minded, I would suspect some sort of agent provocateur ruining our standards. However, I am unable to come up with a profit motive, so my only conclusion is incompetence.

>>somat+(OP)
You used to be able to generate X.509 client authentication certificates (well technically CSR) right in the browser with the since removed <keygen> tag. Ergonomics weren’t that bad, until a user forgot they had a certificate on their broken PC.

>>somat+(OP)
> I was hoping for something sort of like ssh keys

SSH keys (and any other keypair shared across services) are a non-starter on the web for privacy reasons. (See also: `ssh whoami.filippo.io`.)

>>former+M8
As somebody that used to use them for a while: The ergonomics of TLS client authentication in the browser were abysmal. And that's to say nothing about the privacy consequences.

>>lxgr+Jp
iirc managing them was buried super-deep in the browser settings (just like managing resident keys, browsers don’t even do that), but enrollment was fairly simple from a user PoV - submit a form and the server sent back the certificate, iirc you had to confirm a scarily worded dialog (or maybe import it manually? Not sure). Login was smooth if I remember it - just a pop-up if you want to use the installed certificate. Privacy should be fine with TLS 1.3 but would’ve been nonexistent with the contemporary SSL/TLS versions of course.

>>former+Wz
> Login was smooth if I remember it

That's unfortunately not how it works. TLS sits at the transport layer, so it's not possible for a website to use these certificates for a "login-like flow". The site doesn't get to present to the user why and to whom they are authenticating, since transport layer authentication has to happen before HTTP even gets a single request in.

There is also no "logout" button. It shares these UX problem with HTTP "basic authentication" (even though that's technically an application layer protocol).

On top of that, TLS is these days often terminated by a load balance or even a completely separate entity like Cloudflare. Not sure if you can configure these to request client certificates at all; even if you can, it makes things pretty awkward if you want to have closer control of the authentication flow.

> Privacy should be fine with TLS 1.3

It's not fine at all. Any HTTP server can request your client certificate, and most users would probably not think twice before clicking "authenticate", which then reveals their long-time stable certificate and public key to a potentially malicious server.

Compare that with WebAuthN, which makes it intentionally impossible to accidentally present the certificate for a.com at b.com.

>>lxgr+xp
The implementation ends up being a new key gets generated per domain, which is actually what you should be doing with your ssh-keys as well something like "ssh -i server.domain.net server.domain.net"

Because webauthn is such a nonstarter I am actually going to try and half-ass it using SubtleCrypto.sign() and friends. sort of mimic the webauthn api. This is really just a weekend project, nothing important. but I feel really stupid every time I work on it, mainly because of how ridiculous it is to have your key infrastructure managed by the service you are logging into.

However due to domain sandboxing I have half convinced myself it is as secure as using a cookie to auth the person, perhaps even a little better because I never have to see a secret. then fall into despair again on how stupid this whole endeavor is, because I could see the keys anytime I want to. (sighs, shakes fist at the sky) why could you have not made webauthn usable?

>>somat+zT
What specific gripes do you have with WebAuthN that makes you want to reimplement it?

All the problems I have with it as a user originate from either reyling parties doing dumb/user-hostile things (enforcing resident keys even though I'm perfectly capable of remembering my email address or my username, improperly layering WebAuthN with existing second factors etc).

These are possible because WebAuthN is trying to provide for many use cases at once, but I've never felt like it was missing something, and user-friendly behavior is definitely possible. I've seen many examples at this point.

>>lxgr+O81
No good way to manage(save/restore) the keys. but the real killer for me was that it requires a hardware token to work, while a hardware token is better, it sort of sucks as a hard requirement for all users.

Really, I don't want to reimplement webauthn, I will will probably be sticking with basic auth as it just works. However, I was hoping to finally get decent public key auth. and webauthn is close, really close, but it is like the designers gave up at the last second and said "no, we don't want this to work in the general case", all it would have took was to say software token are an ok fallback. I was so close that out of frustration I spent a weekend with an experiment to make public key auth work for everybody. It works, but is a bit pointless as then I, the service needing to authorize somebody, is the same person providing them their public key management system. I might as well cut out the all the ridiculous bit twiddling and just use cookies for all the security that grants the end user.