Certificate based authentication vs Username and Password authentication

  • What are the advantages and drawbacks of the certificate based authentication over username and password authentication? I know some, but I would appreciate a structured and detailed answer.


    I am interested as well in knowing what attacks are they prone to, e.g. as so far mentioned brute force, while nothing is mentioned for certificates... what about XSRF? A certificate is expected to have shorter lifetime and be able to be revoked while a password would live longer before an admin policy ask to change it...

  • 1. Users are dumb

    A password is something that fits in the memory of a user, and the user chooses it. Since authentication is about verifying the user physical identity remotely (from the point of view of the verifier), the user behavior is necessarily involved in the process -- however, passwords rely on the part of the user which is most notoriously mediocre at handling security, namely his brain. Users simply do not grasp what password entropy is about. I am not blaming them for that: this is a technical subject, a specialization, which cannot realistically become "common sense" any time soon. On the other hand, security of a physical token is much more "tangible" and average users can become quite good at it. Evolutionists would tell that humans have been positively selected for that for the last million years, because those who could not hold to their flint tools did not survive enough to have offspring.

    Hollywood movies can be used as a model of how users think about passwords -- if only because those users go to movies, too. Invariably, the Arch Enemy has a short password and just loves to brag about it and distributes clues whenever he can. And, invariably, a British Secret Agent guesses the password in time to deactivate the fusion bomb which was planted under the Queen's favorite flower bed. Movies project a distorted, exaggerated reality, but they still represent the mental baseline on which average users operate: they envision passwords as providing security through being more "witty" than the attacker. And, invariably, most fail at it.

    "Password strength" can be somewhat improved by mandatory rules (at least eight characters, at least two digits, at least one uppercase and one lowercase letter...) but those rules are seen as a burden by the users, and sometimes as an insufferable constraint on their innate freedom -- so the users become to fight the rules, with great creativity, beginning with the traditional writing down of password on a stick-up note. More often than not, password strengthening rules backfire that way.

    On the other hand, user certificates imply a storage system, and if that system is a physical device that the user carries around with his house or car keys, then security relies (in part) on how well the average user manages the security of a physical object, and they usually do a good job at it. At least better than when it comes to choosing good password. So that's a big advantage of certificates.

    2. Certificates use asymmetric cryptography

    The "asymmetry" is about separating roles. With a password, whoever verifies the password knows at some point the password or a password-equivalent data (well, that's not entirely true in the case of PAKE protocols). With user certificates, the certificate is issued by a certification authority, who guarantees the link between a physical identity and a cryptographic public key. The verifier may be a distinct entity, and can verify such a link and use it to authenticate the user, without getting the ability to impersonate the user.

    In a nutshell, this is the point of certificates: to separate those who define the user digital identity (i.e. the entity which does the mapping from the physical identity to the computer world) from those who authenticate users.

    This opens the road to digital signatures which bring non-repudiation. This particularly interests banks which take financial orders from online customers: they need to authenticate customers (that's money we are talking about, a very serious matter) but they would love to have a convincing trace of the orders -- in the sense of: a judge would be convinced. With mere authentication, the bank gains some assurance that it is talking to the right customer, but it cannot prove it to third parties; the bank could build a fake connection transcript, so it is weaponless against a customer who claims to be framed by the bank itself. Digital signatures are not immediately available even if the user has a certificate; but if the user can use a certificate for authentication then most of the hard work has been done.

    Also, passwords are inherently vulnerable to phishing attacks, whereas user certificates are not. Precisely because of asymmetry: the certificate usage never involves revealing any secret data to the peer, so an attacker impersonating the server cannot learn anything of value that way.

    3. Certificates are complex

    Deploying user certificates is complex, thus expensive:

    • Issuing and managing certificates is a full can of worm, as any PKI vendor can tell you (and, indeed, I do tell you). Especially the revocation management. PKI is about 5% cryptography and 95% procedures. It can be done, but not cheaply.

    • User certificates imply that users store their private key in some way, under their "exclusive access". This is done either in software (existing operating systems and/or Web browsers can do that) or using dedicated hardware, but both solutions have their own set of usability issues. The two main problems which will arise are 1) the user loses his key, and 2) an attacker obtains a copy of the key. Software storage makes key loss a plausible issue (at the mercy of a failed hard disk), and sharing the key between several systems (e.g. a desktop computer and an iPad) implies some manual operations which are unlikely to be well protected against attackers. Hardware tokens imply the whole messy business of device drivers, which may be even worse.

    • A user certificate implies relatively complex mathematical operations on the client side; this is not a problem for even an anemic Pentium II, but you will not be able to use certificates from some Javascript slapped within a generic Web site. Certificate requires active cooperation from client-side software, and said software tends to be, let's say, ergonomically suboptimal in that matter. Average users can normally learn to use client certificates for a HTTPS connection to a Web site, but at the cost of learning how to ignore the occasional warning popup, which makes them much more vulnerable to some attacks (e.g. active attacks where the attacker tries to feed them its own fake server certificate).

    On the other hand, password-based authentication is really easy to integrate just about everywhere. It is equally easy to mess up, of course; but at least it does not necessarily involve some incompressible extra costs.


    User certificates allow for a separation of roles which passwords cannot do. They do so at the expense of adding a horde of implementation and deployment issues, which make them expensive. However, passwords remain cheap by fitting in a human mind, which inherently implies low security. Security issues with passwords can be somewhat mitigated by some trickeries (up to an including PAKE protocols) and, most of all, by blaming the user in case of a problem (we know the average user cannot choose a secure password, but any mishap will still be his fault -- that's how banks do it).

    "users are dumb" - no they aren't. Users aren't dumb. They are rationally ignorant: they have better things to do with their time than to learn the mathematics of password entropy. There is an important difference (and a very important difference in mindset, for security folks). Users are also rationally non-compliant: as Cormac Herley has argued, given that it is relatively rare for a user's security to be breached, the benefit to users to spending time on annoying security measures tends to be outweighed by the time it takes to do so.

    @D.W. I love that term "rationally ignorant"! I see a lot of usage of it coming up...

    users are users. Users are primarily interest in their tasks, some of which operate in the security domain. Security often degrades usability, and users are intentionally non-compliant in their efforts to improve their own usability. Makeing a system secure requires the cooperation of the users. To get cooperation, they need to understand why specific measures are in place. Not just ‘passwords are more secure when they are longer’, but typical attackers have tools that assume passwords of eight characters or less, so we made the minimum length nine. (I made up the eight character length).

    And you issue the PKI cert to ... oh yeh a "dumb user" and rely on them looking after it and not putting it somewhere like the company file share.

    "Password strength" argument is wrong. Rules like the minimum number of characters, uppercase and numbers do not actually do much for entropy, but rather simply make the passwords easier to crack as the attacker can know exactly what the passwords will be like, as well as making the password harder to remember for the users. A password written on a sticky note is as secure as a same-length certificate, when all the attackers have no physical access to the machine.

    I signed up for stackexchange to upvote D.W.'s comment. "Rationally Ignorant"! - very nice.

    *"Passwords are inherently vulnerable to phishing attacks, whereas user certificates are not."* Sorry, why can't someone phish me for a copy of my certificate rather than a copy of my password?

License under CC-BY-SA with attribution

Content dated before 6/26/2020 9:53 AM