

Ask HN: Why does no one use client certficates for auto-authentication?  - mars

client certs can get generated hassle-free in the browser without user interaction:<p>http:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;9197484&#x2F;generating-client-side-certificates-in-browser-and-signing-on-server<p>implementing this into an authenticator seems straight forward: generate client certs after first login and link it to a user&#x27;s account. the next time that user visits the website the browser will automatically pick the right cert to authenticate itself. depending on the browser settings a confirmation dialog might pop up.<p>thinking even further the authenticator could also require the user to enter a password after manually logging out and accessing the site again. in that case i&#x27;m assuming that the user doesn&#x27;t want other people using the same machine to be logged in automatically.<p>why do we still have to fill out login forms?
======
tptacek
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.

------
Spooky23
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.

~~~
mars
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

------
danpalmer
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.

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

~~~
mars
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.

~~~
martinml
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 :)

~~~
mars
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.

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

