Client Certificates for Dummies

Over the years we have written a number of secure web systems for clients that require client user authentication. The technically ideal pattern for this is a "Multi Factor Authentication" (MFA) model which requires that the system interrogate the user on login for:

  • A knowledge factor ("something only the userknows", e.g. password/pin)
  • A possession factor ("something only the userhas", e.g. token, key),
  • An inherence factor ("something only the useris", e.g. fingerprints).

A System's authentication process needs to validate these before authorising further system access to a user.

In practice the costs of developing and supporting a solution that covers all these factors soon makes the operational process for some businesses prohibitive. For example, the distribution costs of hardware (tokens, smart cards or biometric readers) or the logistical costs involved in the biometric enrolment process. Support costs must also be assessed as there will unquestionably be an increase in support calls due to technical issues and dealing with understandably confused (non-technical) customers. These costs are often either under-estimated or are not taken into account at all during system design.

The management of client certificates is complex and therefore expensive as:

  • Issuing and managing certificates is dark art! Many (reputable) Public Key Infrastructure (PKI) vendors will confirm this. PKI is about 5% cryptography and 95% user and support procedures. It can't be achieved on a tight budget.
  • User Certificates require that a user stores their private key on their machine in some way (either on the browser or some other hardware). Often this will result in:
  1. The user losing their key.
  2. An attack from someone with a copy of the user's key.
  • Software storage makes key loss a serious possibility, e.g. failed hard disks. Hardware tokens imply the whole messy business of device drivers, which may be even worse.
  • A User Certificate requires the client's machine to perform complex mathematical operations - not simple JavaScript code. Certificates require active cooperation from client-side software, and said software tends to be unreliable.
  • Average users can normally learn to use client certificates for an HTTPS connection to a website, but at the cost of learning have to ignore the occasional warning popup.  This makes them much more vulnerable to some attacks (e.g. active attacks where the attacker tries to feed them its own fake server certificate).

User Certificates can work well, but they do so at the expense of adding a multitude of implementation and deployment issues, which make them expensive and inherently unstable due to the inevitable involvement of multiple 3rd party systems.

Simple password-based authentication is easy to integrate just about everywhere and remains more in reach of SME budgets. Provided users are encouraged to use sensible passwords that are sufficiently complex to avoid being hacked but easy enough to remember. These systems are cheaper, easier to implement, bypass technical platform and third party software changes and are easier for the average user to understand and manage.

When faced with a choice as to whether to implement user certificates, a serious costs/benefits review should take place. A good and thorough understanding of the development, support, licencing and hardware costs involved is imperative during the solution design stages of product development.


Nick 18 Aug 2014