TLS Client Authentication is much more than a strong password

I've heard an important point made in correcting people when they identify certificate authentication as two-factor.  It isn't out of band so a single machine compromise amounts to account compromise.  I am concerned however, when people draw the analogy of certificate auth being a strong password and I'll explain why.

Certificate authentication differs substantially from strong passwords:

  1. ​Server side never gets a password of any kind
  2. Server side never stores user passwords in any form

Number 1 is important because it removes the ability of a attacker with access to impersonate the server side from impersonating the user on other services where they use a common password.  This is important in the event of TLS MitM (Superfish), DNS poisoning or the compromise of any unrelated system where users might use the same password.

Even with a fully decrypting TLS MitM the attacker cannot obtain the client's private key because the authentication is done with D-H (Diffie-Hellman Key Exchange), just as the original TLS auth is (thus the attacker can't directly impersonate the server, but must rely on client-compromise like the Superfish root cert).

Number 2 is important because the difficulty of cracking a certificate's private key is the same as cracking the private key of given its certificate.  In other words, it's impractical to the point of not even being considered.  This removes a major concern in breaches leading to password hash dumps, because there are no password hash dumps to obtain, just certficates which are effectively public record.

Certificate auth is non-trivial both on the server and on the client and is not sufficient for two-factor even in combination with a password.  It is, however, a worthwhile option in reducing risk for highly privileged accounts where desired.

Certificate auth combined with managed two-factor is an ideal combination, but why do that directly at all.  SAML integration is the best long-term solution since it gives your customers control of how strong they want their authentication to be (including client certs).  I would go so far as to say it makes the most sense to implement even the integrated login service of an application as a SAML IdP.  Why reinvent the wheel and introduce two code paths to maintain?

Returning to my original point, certificate auth is way more than a strong password.