3 ms·
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 phishi
by mr_mitm 1y ago
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.
- nabeards 1y agoClient 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.
- Max_aaa 1y agoThe main reason that PGP did not catch on, as only the most tech savy were able to understand how the chain worked.
- mr_mitm 1y agoOkay, 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.
- poincaredisk 1y ago>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.
- mr_mitm 1y agoAll is lost the moment you have malware on your device. It can just steal the session key after authentication.
- 7bit 1y agoBecause 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.
- dns_snek 1y ago> 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.
- mr_mitm 1y agoWhat 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.
- pabs3 1y agoClient 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.