• Rob Allen, Technical Pre-Sales Manager at Swivel Secure.


• 15.09.2016 02:15 pm
undisclosed

Multi-factor authentication is already being used by enterprises around the world to protect their digital gateways to remote access VPN and cloud services. ‘Why then are so many others still using digital certificates to do the same job?’ asks Rob Allen, Technical Pre-Sales Manager, Swivel Secure.

For some reason, the notion that ‘we don’t need multi-factor authentication – we’re already protected by digital certificates’ continues to pervade corporate IT departments. But in today’s multi-device and hyper-connected world, battling on with certificate-based authentication is, frankly, certifiably insane. Compared to its multi-factor alternatives it is more vulnerable to attack and also costs a fortune, in wasted time and administration, or worse, in the fallout from a security breach that was detected too late. 

What is a digital certificate?

A digital certificate is a user identity assigned to an individual’s connected device which can be used to confirm their authenticity when logging into a network gateway, such as a remote access VPN or the login page for a cloud service.

Certificates rely on two cryptographic keys to confirm authenticity, both of which are created by the user’s device. Firstly, a ‘public key’ is created and sent to the registered Certification Authority (CA) or a firm’s IT department, where it is digitally signed using their own root key. The public key is then shared by the user’s device with all the required service providers and network admins that will use the certificate to verify the user’s authenticity. A second ‘private key’ is also created and stored locally on the user’s device, commonly in a secure hardware zone like a smartcard. When the user is challenged to authenticate, cryptographic procedures marry the public and private keys, verify the certificate’s legitimacy and grant access.

So, what’s the problem?

Certs authenticate the device, not the person

The biggest failing of certs-based authentication is that the system verifies the identity of the device, not the person using it. Sure, personal information is required in order to obtain the original certificate, but this information is not re-confirmed at the point of login. Unlike multi-factor authentication, the process never challenges the individual to confirm who they are – it simply checks the certification against an authorised list. The implication here is simple: Anyone with access to a user’s certified device could use it to gain authorised access completely undetected.

Lost or stolen devices can still be used up to 24hrs after being reported

To make matters worse, when a user’s device is lost or stolen, an online query must be sent to the IT department (or CA) which will then update a Certificate Revocation List, which participating network admins and service providers download and cross check against certified device access requests. This list must be downloaded and stored locally, a process that is typically done every 24hrs. This means that it can take up to 24hrs for a certificate to be recognised as invalid by gateway admins and cloud service providers, giving more than enough time for the device to be misused should it fall into the wrong hands.

Given that each digital certificate is necessarily tied to a device not to a user, if an employee wishes to use a smartphone, tablet and laptop to access protected network gateways and cloud services, they will need three different digital certificates, tripling the per-user administrative overhead needed to maintain the model. In this case, the user is also operating with three different digital identities, making it harder for the employer to track which certificates should be re-issued each year, and which should be retired as older devices are abandoned or replaced.

Certificate expiration

Finally, there is the thorny issue of certificate expiration. To ensure their security, certificates are issued with an expiration period. These periods can vary, but the longer a public/private key pair is in use, the greater the chance that it will be compromised. Private keys are commonly granted a twelve-month expiration period. This means that after just one year, a new certificate will need to be created for each user/device before authentication to any remote-access network gateways can continue. In an enterprise organisation with hundreds, possibly thousands, of employees, this presents a huge administrative challenge, particularly when the reissuance of certificates relies on personal information taken from physical documents (passport, driver’s license etc.,) in order to confirm the user’s ID.

The IT department’s (or the CA’s) ability to issue and administer the system is enabled via another certificate, one that is self-signed and self-issued. This also carries an expiration period - five years is the industry norm. When this expires, all the user certificates that rely on this root key will automatically be invalidated, simultaneously preventing all corresponding device users from authenticating until they have been re-enrolled and reissued with a new certificate, married to a new root key. In an enterprise environment this, again, requires a massive administrative overhaul to be undertaken once every five years, purely to keep the system up and running. Should the department fail to ‘keep up’, then the system is more than capable of paralysing the business overnight.

In many instances, re-enrolment for new certificates can be authorised by employing tokenless two-factor authentication (2FA). This begs a big question: if tokenless 2FA is deemed secure enough to underpin the creation of digital certificates, shouldn’t it just be deployed instead of the whole model?

A saner approach: adaptive multi-factor authentication

A simpler (saner?) approach is surely to deploy an adaptive multi-factor authentication (MFA) platform that can respond in accordance to the precise needs of each user, as determined by the nature of their role and the technical risks associated with their access request. Not only can this approach verify a user’s identity consistently across multiple devices, it also puts them right at the heart of the authentication process. By building ‘something you know’ into the verification process, for example, together with ‘something you have’ (like a recognised device), unauthorised attempts to access network gateways simply cannot succeed should the device fall into the wrong hands. The hacker simply doesn’t have what they need to get through.

Compared to certificate-based models, these systems are cost effective and simple to deploy and maintain, particularly in a tokenless environment where the token inventory is administered virtually. The latest adaptive features offered by leading MFA platforms also adopt a rules-based approach, ensuring the authentication challenge is commensurate with the gravity of the access request, ensuring the right balance of ease-of-access and security is applied each and every time. Access to a low-risk cloud service, for example, attempted by a user that has already logged into the corporate network via their work laptop, may only need trigger a username and password request. A financial director, on the other hand, trying to access restricted revenue forecasts from their personal device while abroad would be automatically identified as ‘high risk’ and required to authenticate using a series of stronger, multi-factor challenges before access is granted.

Try doing that with a certificate-based model. It’s enough to drive you mad.