Hacker News Reader

Comment by brewdad | Hacker News Reader

OTP verification can largely be worked around because so many sites still use SMS codes which a dumb phone can handle. Similarly, 2FA codes can be handled on a PC without requiring a smart phone. It adds hurdles but can be done.

Where it becomes challenging is situations where smart phones truly are required. When I attended college football games last fall, all tickets were e-tickets. You were required to present a QR code on your device or your ticket stored in Apple Wallet or Google Wallet. I ran into the same situation with my local theater's ticketing. You haven't lived until you've witnessed an audience with an average age of 70 try to figure out their tickets on their smartphones when they've never used them for that before nor had any notion that was even POSSIBLE.

View on HN

I don't understand why client certificates aren't way more common as a second factor. They have existed forever, are available on all platforms, they are phishing resistant (unlike OTP, and don't get me started on SMS), browsers or OSs could generate them during setup, and you could enroll them seamlessly with one click. Instead we had to invent new things like passkeys which do essentially the same thing.

You can use client certificates even with IMAP and SMTP.

The main reason that PGP did not catch on, as only the most tech savy were able to understand how the chain worked.

Okay, I know that and I agree, but I wasn't talking about PGP. Client certificates are much easier to use. They can be self-signed and the whole trust issue disappears.

>they are phishing resistant

But can be easily stolen by malware (unless someone adds a client cert OS support? intriguing idea). But so can passkeys stored on the same device, so I don't know.

Long time ago browsers even had a widget to generate client certs natively! But it was removed, probably because of lack of use.

All is lost the moment you have malware on your device. It can just steal the session key after authentication.

Because certificates are too complex for non-techies. Most of my sysadmin and dev colleagues have no clue how they work. Most of them have have access to SECTIGO CERTIFICATE MANAGER, a web UI to sign and issue certificates. Yet, every time someone needs a certificate, I get a call and asked the same questions over and over again.

Now expect aunt Lottie to use certificates? Yeah, sure.

All we need is a magic button that says "enroll this browser". I'm sure aunt Lottie can handle that.

And yet, PGP still sucks, so it's not that easy, no?

I don't follow. I wasn't talking about PGP.

> I don't understand why client certificates aren't way more common as a second factor.

I think there are some significant limitations to client certificates as a general-purpose 2FA mechanism.

Reusing the same certificate would make you trivially trackable across the web. You could create a unique certificate for every origin, but you need a way to permanently store the certificate. That becomes a problem if you want to secure them with hardware tokens where storage is limited. Yubikey 5 series can only store a handful of certificates.

Passkeys (i.e. resident FIDO2 keys) aren't intended to be a second factor, they're intended to be the only factor but they also require storage. Yubikey 5 can only store 25 resident keys, for example.

Non-resident FIDO2 keys (previously U2F) are what's traditionally used for 2FA. The hardware token derives key material from its master key and credential ID provided by the browser and the server, so it doesn't require any storage.

What exactly is the issue with permanent storage? The idea with certificates is that the private key stays put.

When you want to use another browser or reinstall one, just re-enroll the new one. Ten one time recovery keys act as an alternative second factor, just like it's commonly done now.

I'm not saying there aren't any tradeoffs at all, but in my opinion they're minor when compared to OTPs, SMS or Yubikeys. Not nearly enough downsides to explain why no major services supports client certs.

Client certs were amazing, wholeheartedly agree!

I see you are suffering from something that always happened to me when championing them: they were so unknown that people assumed you meant PGP…sigh.

Client certs are great, but the UI for them is bad and browser vendors are making it worse, for example they killed <keygen> so you have to tell people to run OpenSSL commands in a terminal during signup.

>required to present a QR code on your device

I so hate this. I have repeatedly seen PDFs containing nothing but a QR code and text like "not valid if printed" - this is truly silly. QR codes were created to form a bridge between the physical and the digital world, exactly so people can print them out. If you want it to be digital-only for some reason, use NFC or Bluetooth or whatever.

I've used several similar services, but usually you can print out the QR code and present that instead (yes, I know: you have to have a way of receiving and printing that, but you don't need to have a smart phone). This is also handy if you might run out of battery or network on your phone.

Reply on news.ycombinator.com