GlobalSign Blog

Heartbleed - A Case for Two-factor Authentication

Heartbleed - A Case for Two-factor Authentication

I read a great blog over the weekend from Sophos on how Heartbleed worked and whether two-factor authentication (2FA) could have helped protect users.  The blog focused on One Time Passwords (OTP) as their method of 2FA, but I wanted to point out another option that’s a little closer to my heart - using digital certificates as the second factor.  

Quick recap...what's two-factor authentication?

There are three main authentication “factors”

1. something you know - e.g., username/password, ATM PIN
2. something you have - e.g., mobile phone with OTP code, debit card, digital certificate
3. something you are - e.g., fingerprint, retina scan

Two-factor authentication involves using at least two of these factors to access something (e.g., your computer, your email, a cloud application like Salesforce, your bank account via ATM).  

Where do digital certificates fit in?

Digital certificates fall into the second type of factor outlined above - something you have.  Generally digital certificates are either stored locally on your machine in your certificate store, or they can live on a token or smart card.  Whenever you go to log into a service that is configured for certificate-based authentication, the service will automatically check your certificate store and/or any tokens or smart cards for available certificates.  

For example, our customers use certificate-based authentication to access our Enterprise PKI Management portal.  EPKI requires administrators to present a special GlobalSign-furnished digital certificate to manage the life cycle of the certificates associated with their organization.  

When you try to access the secure area of the GlobalSign Certificate Center, you are automatically presented with a list of certificates and need to choose the correct one before you can access.  This means even if someone had knowledge of your username and password, he still wouldn’t be able to make any changes to your organization’s certificates (e.g., order,  issue, revoke) unless he also had your digital certificate.

Example list of certificates presented when trying to access a service configured for certificate-based authentication.

Could certificate-based authentication have helped with the Heartbleed bug?

One of the biggest, and most publicized, threats to end users from Heartbleed was the risk that their usernames and passwords may have been visible to attackers taking advantage of the bug. (For an easy-to-understand explanation about how Heartbleed works, check out this other fantastic Sophos blog.)  

Because certificate-based authentication requires a second factor beyond usernames and passwords, even if your credentials were compromised via Heartbleed, a hacker would not be able to access your account without your private key associated with your certificate.  

No sensitive information about your certificate (i.e., the private key) is sent during the authentication process.  The private key resides with your original certificate file, either on your machine or on a token/smart card.  Unlike a password your private key is secured locally and not presented to the server, so it would not be vulnerable to the Heartbleed bug.

Heartbleed is the latest evidence that single factor means of authentication aren’t sufficient any more.  I wholeheartedly recommend using two-factor authentication, certificate-based or otherwise, wherever possible. 

Cert Based Authentication for Access Control

Share this Post

Recent Blogs