What are the benefits and limitations of using a certificate for authentication as opposed to a username and password? I am aware of several, but I would value a methodical and thorough response.

Not all people are geniuses

A password is an item that the user selects and keeps in mind. Since authentication involves remotely (from the verifier’s perspective) confirming the user’s physical identification, user behavior is inevitably included in the process; nevertheless, passwords rely on the user’s brain, which is the component of the user that is most infamously lousy at managing security. People just don’t understand the concept of password entropy. I don’t hold that against them; this is a specialty and a technical subject that is not likely to become “common sense” anytime soon. The security of a physical token, on the other hand, is far more “tangible,” and regular users may get rather good at it. Evolutionists claim that during the past million years, humans have been positively chosen for this because those who were unable to hold onto their flint tools did not live long enough to produce children.

If only such people also watch movies, Hollywood productions can serve as a paradigm for how users should think about passwords. The Arch Enemy always has a brief password, loves to brag about it, and drops hints whenever he gets the chance. Every time, a British secret agent manages to figure out the password in time to disable the fusion bomb that was hidden beneath the Queen’s most cherished flower bed. Although movies depict a skewed and exaggerated version of reality, they still capture the mindset of regular users, who view passwords as security measures because they are more “witty” than the attacker. And most of them always come up short.

Mandatory requirements (at least eight characters, at least two numbers, at least one capital and one lowercase letter, etc.) can help to increase “password strength” in some way. However, users view these regulations as a hardship and occasionally as an intolerable restriction on their inherent freedom. As a result, users creatively rebel against the regulations, starting with the custom of jotting down passwords on sticky notes. Generally speaking, password-strengthening guidelines have the opposite effect.

However, since user certificates imply a storage system, security depends (to some extent) on how well the typical user maintains the security of a physical object, which they typically do fairly well. If that system is a physical device that the user carries around with his house or car keys, that is better than when it comes to selecting a strong password. Thus, one major benefit of certificates is that.

2. Certificates use asymmetric cryptography

That “asymmetry” has to do with the division of roles. When using a password, the person who verifies it eventually knows the password or data that is equivalent to a password (well, that’s not true for PAKE protocols entirely). A certification authority issues user certificates, ensuring the connection between public key cryptography and a physical identity. Without being able to assume the identity of the user, the verifier—which might be a separate entity—can validate such a link and use it to authenticate the user.

To put it briefly, the purpose of certificates is to distinguish between those who authenticate users and those who define the user’s digital identity (i.e., the entity that maps the physical identity to the computer world).

This makes non-repudiation possible with digital signatures. This is of particular interest to banks that accept financial orders from customers who shop online because they would like to have a convincing trail of the orders so that a judge would be persuaded, even though they need to authenticate customers (we are talking about money, which is a very serious matter). Simple authentication gives the bank some reassurance that it is speaking with the correct customer, but it is powerless to prove it to outside parties. The bank could fabricate a transcript of the connection, leaving it defenseless against a customer who alleges the bank is behind them. Even with a certificate, users cannot always access digital signatures instantly. However, most of the effort is already done if the user can use a certificate for authentication.

Additionally, user certificates are immune to phishing assaults, but passwords are not. That’s precisely because of asymmetry: an attacker posing as the server cannot gain any valuable information by using a certificate that never requires disclosing any secret material to the peer.

Photo by Christopher Gower on Unsplash

3. Certificates are complex

User certificate deployment is complicated and, hence costly:

1. Any PKI provider (and, in fact, I do tell you) will warn you that issuing and administering certificates is a very dangerous endeavor. in particular, the handling of revocation. PKI consists of 95% processes and 5% cryptography. It is possible, but not at a low cost.
2. It is implied by user certificates that users keep their private key under “exclusive access” in some manner. Either specific hardware or software (available operating systems and/or Web browsers) can accomplish this, but each approach has a unique set of usability problems. The two primary issues that can occur are:
   1. the user misplaces the key; and
   2. an attacker manages to get a duplicate of the key. Key loss is a real possibility due to software storage (it might be caused by a failing hard drive), and sharing a key across several systems (such as an iPad and a desktop computer) necessitates certain manual processes that are probably not properly secured against hackers. Hardware tokens suggest the complex world of device drivers, which may be far worse.
3. Although using a user certificate requires rather complicated mathematical calculations on the client side, you won’t be able to utilize certificates from some JavaScript slapped into a generic Web site. This won’t even pose a difficulty for a Pentium II. Client-side software must actively cooperate in order to obtain a certificate, and this software is often, to put it mildly, ergonomically subpar. The majority of users can typically learn how to use client certificates to establish an HTTPS connection to a website, but doing so comes at the expense of learning how to ignore the warning popup that appears from time to time. This leaves them far more open to various types of attacks, such as active attacks in which the attacker tries to feed them a fake server certificate.

However, password-based authentication is fairly simple to incorporate into almost any system. Of course, it is just as simple to go wrong, but at least there aren’t always unaffordable additional expenses.

In brief

Passwords cannot provide the role separation that user certificates can. They are costly because they accomplish this at the cost of creating a plethora of additional installation and deployment problems. But since they make sense to humans, passwords continue to be inexpensive, which suggests low security by default. Password security can be partly alleviated by a few tricks (such as PAKE protocols) and, most importantly, by placing the blame for any error squarely on the shoulders of the user (yes, we know that most users are not able to choose strong passwords, but that’s still how banks do it).

Tomas Manas