TLS client certificate authentication is technically quite good, better than anything else you have available in a browser.

Unfortunately:

* The UX for installing a certificate on a Windows or Mac machine is atrocious; it's incomprehensible even to people who understand X.509, and might as well not exist for laypersons.

* The browser UX for matching certificates to sites is not much better; the mechanism basically only works if you have a single client cert you use for every site.

* Getting certificates from a CA introduces yet another nearly incomprehensible UX element, and leaves your site to the mercy of the CAs you trust.

* Issuing your own certificates involves you building a hopefully- less- incomprehensible UX for getting certs into the hands of users, and also implicates a chicken/egg problem of figuring out when it's OK to issue a cert to whom.

What security does this provide that another token like a cookie does not?

Certificates provide value where you can independently attest that the client is who or what it appears to be.

Client certificates are the basis of MDM solutions, for example. In a corporate setting, I enroll my iPhone with the MDM, linking that device and phone number to my identity. The MDM solution issues certificates identifying my device and my identity to that device. That allows subsequent interactions with corporate systems to be authenticated.

If I drop the phone in the toilet, get a new one and restore it, I must re-enroll, as the phone serial number changed. The old certs are revoked. The key assumption is that the mobile device platform can be trusted to provide an accurate serial number, phone number, etc.

Browsers cannot be trusted much, if at all. A modestly clueful attacker can spoof all of the metadata provided to the website. I can take that client certificate and copy it to any other browser.

1. you would require access to the user's system in order to gain access to the private key of the cert

2. it provides better security than username/password authentication

3. it makes our lifes easier because you wouldn't have to remember passwords

It's used extensively in finance from what I've seen. Not personal or even business banking, but trading, investment portfolio management, financial advisors, those sorts of area. Everyone is given a certificate they install, and that's to identify them.

I've also used it in client-server applications, not on the web, and it was very effective as a transport layer security mechanism, but in that case it was devices talking to devices in an automated way, so there was never a problem with user experience or education of users.

How do you solve multi-device login? Also, that seems to require JS, which may or may not me a problem.

first of all, it doesn't have to be mandatory. classic auth via user/pw entry could still co-exist.

multi-device auth is possible too: each device could generate a client cert. the authenticator would have to be able to link multiple certs to a user account.

If you can use a password to generate/link a new certificate, wouldn't that mean the weakest link is again the password? Sorry if I am misunderstanding, it's a very interesting topic but I'm not sure I get it :)

it depends on how it gets implemented. if you decide that classic user/pw auth should co-exist it is of course still the "weakest link". sharing certificates across devices is also possible. os-x mavericks supports this natively with the new icloud keychain. although that might not be what you want, security-wise.

There's an issue with switching between using a password and a certificate: the password will end up being forgotten. You can probably solve this with email resets, but it's worth thinking about.

I use it on a personal project as a kind of two factor authentication method.