Certificate Based Authentication

2nd Factor or Not?

Pete
SecurityBytes
4 min readFeb 20, 2018

--

I took January off for non security based pursuits and I’ve been a bit quiet on here as of late, however I had an interesting (YMMV) conversation, admittedly it fell out of a chat around the eminently dull PCI-DSS 3.2 security requirements for access into Card Data Environments (CDE) which I decided was worth a small post.

Bonus sleep inducing link for anyone interested in PCI-DSS: https://www.pcisecuritystandards.org/

That conversation boiled down to ‘Does a certificate constitute a second factor of authentication’. I said no, my colleague says yes.

Turns out the answer is not the exactly straight yes/no answer most people would assume, except it sort of is, but sort of isn’t! To add context, access into a CDE for console/administrator functionality now(soon) requires Multi Factor Authentication (MFA). So then, would a user credential / password and certificate combination be multi factor from a compliance stand point, there are definitely multiple factors at play, right?

Have a think and take a stance then read on and see if we agree:

To dig deeper we need an understanding of what MFA is. Wikipedia describes it as:

Multi-factor authentication (MFA) is a method of confirming a user’s claimed identity in which a user is granted access only after successfully presenting 2 or more pieces of evidence (or factors) to an authentication mechanism: knowledge (something they and only they know), possession (something they and only they have), and inherence (something they and only they are).

The key point with regards to the certificate is something, they, and only they have. A certificate can be tied to a specific user, tied to a specific device or both of the above, have a password or not, or conversely none of the above. In any of these scenarios it’s entirely possible I am the only ‘owner’ of a certificate. Let’s investigate the scenarios a little closer.

Active Directory (AD) account + Specific user tied certificate:

This combination is both something I have and something I own, but if the host is lost (theft/malware) and account is compromised, the certificate is going with it. This can happen just by losing the AD credentials, and not the cert itself (from what ever authority generated it in the first place). If the machine is lost and the AD creds are known and the cert is without password OR matches the password of the AD creds, this scenario stops being a multi factor authentication (yes even if the cert is marked un-exportable and deployed by GPO, cos that means nothing in this scenario).

Active Directory (AD) account + Specific device tied certificate:

Again, something I have and something I own (device with a cert on). In this scenario if the device was to be lost, and cert stored within the system certs, which would make sense if tied only to the system, any loss of an individual account with access to this machine would grant access to a resource without the second factor being effective, unless it is password protected. Again this would rely on the password being different from the login credentials to maintain the MFA aspect of this approach.

Active Directory (AD) account + Specific device/user tied certificate:

The risk is getting smaller and smaller, here we would need the loss of the physical machine, loss of the AD credentials and the cert to be the same password as the AD account or not password protected at all, but if this scenario occurs, you are once again in a situation where you are not technically offering MFA.

Active Directory (AD) account + Generic certificate:

You have no assurance that you are the only owner of the cert and compromise of the AD account would result in access to the resource in question via export of a certificate, unless it was using a password different from the AD account, but if this generic cert was in use in several places the password for the cert will be shared, removing the something only you know element, technically rendering it not PCI compliant.

In short there are ways to make a certificate, look and behave like a second factor with correct and proper configuration. However a certificate in of itself is NOT a second factor because it is not something a user ever ‘knows’ or ‘has’. A certificate sat on a device that generates a one time password, be it hardware or software token generator, is not the second factor, it is purely a way of validating the device upon which it sits. I stand by my assertion that certificates cannot be considered a MFA solution. If you are of a mind and want to contest this, there are various compliance requirements that confuse the issue and really cloud the waters, ultimately though, using certs AND some for of OTP is going to be more secure than just certs, even if you are of the opinion that is does constitute a true second factor.

--

--

Pete
SecurityBytes

InfoSec architect, analyst and researcher. Suffering from full time imposter syndrome.