alt Hacker NewsI kinda like client certificates, and have made simple uses of them, for Web services and occasionally corporate-internal humans.
But with the current browser support, client certs haven't seemed viable for consumer sites. Unless the browser developers are inspired to offer better support for mass consumer users, but I couldn't make a strong case why they should.
(I'd rather most consumer sites resume making password authn work well, and then have them integrate 2FA judiciously and well. And stop with some of the counterproductive surveillance capitalism mechanisms.)
> (I'd rather most consumer sites resume making password authn work well, and then have them integrate 2FA judiciously and well. And stop with some of the counterproductive surveillance capitalism mechanisms.)
OK, I agree, stop with the counterproductive surveillance capitalism mechanisms.
Making password authn work well (using the ideas you mention about improving it) and integrating 2FA (also improving it in the ways you mention), would also be OK, although that should be an alternative choice, so that users who do want to use X.509 and are able to do so, can use that more secure mechanism and not requiring other mechanisms. The 2FA really shouldn't be required especially when it causes problems (such as the ones mentioned in the "SMS 2FA is not just insecure..." article, but also such things as the set-up for 2FA not working very well in GitHub, some mechanisms requiring JavaScripts, etc); those who want to and are able to use X.509 should use X.509 instead.
Another thing that I dislike is the "security questions" such as your date of birth or your mother's maiden name or whatever, which do not help with security at all, and those should not be used at all.