With the multitude of data breaches of large databases exposing user credentials over the past several years, multi-factor/two-factor (MFA/2FA, referred to as MFA throughout the remainder) authentication deployment is on the rise.
The purpose of this article is to demonstrate how to deploy MFA for your OpenVPN server. We will demonstrate both a deployment using TOTP on a private server and how to integrate with the popular enterprise MFA vendor, Okta.
What is Multi-Factor Authentication?
Basic devices like a handheld GPS, the radio in your automobile, or the toaster in your kitchen, have no authentication necessary. The simple fact that you have physical access to the device is sufficient to utilize the device. Early computer systems also did not require any authentication. As computer systems and other devices have matured, authentication capabilities have been added.
Authentication can serve a few purposes, including support for multiple users (and their associated settings and preferences) and authorization to determine which features are available to the user. To authenticate these systems, a simple user selection may be required, or a username and password prompt may be presented. Systems that have MFA configured require what is essentially a second password, often referred to as a token.
Why do I need MFA?
Many users have reused their username and password across multiple systems, namely popular websites (LinkedIn, Facebook, Twitter, many others). These sites are attractive targets for hackers who seek ways to steal data or leverage an account as a resource to generate spam. For a sample of such breaches, go to Google and type in “large credential leak” in the search box.
To combat these leaks, a couple of things can be done. First, using unique passwords for every site and system means a leak on one doesn’t directly impact another. This can extend to not just using the same username, as well.
The other thing a user can do is enable MFA. Many sites already offer this capability, Reddit, various web hosting companies, etc. Some businesses require it. Implementation across these services can vary.
Multi-factor authentication is typically accomplished with a “something you have” token. This can be something like an RSA SecureID hardware token, or it can be an item such as your mobile phone.
The initial implementation using cell phones, was a 4 to 6 digit number calculated by the vendor or site, sent as a text message. The end-user enters this number after already successfully entering their username and password as a validation code. This code can use either a random number generator that the site tracks temporarily or one of the HOTP/TOTP methods discussed later.
A more modern approach with cell phones is to use an app to generate a code. Google Authenticator is common, along with commercial MFA vendor tools like Okta. Both of these services use a protocol TOTP (Time-based One-Time Passwords) and HOTP (HMAC-based One-Time Passwords). These are covered in depth in RFC 6238 and RFC 4226, respectively. Our examples in this article will leverage TOPT.
The important difference between these mechanisms is how and where the validation code or one-time password is communicated or calculated. The former method, SMS messages can be stolen via SIM hijacking or other methods and relies on a functional cellular or data connection to the receiving device. The latter mechanism requires no network connection on the device, calculating either the challenge or the response.
If you’re using OpenVPN for username and password authentication, in addition to individual client certificates, you technically have MFA. The thing you have, the client certificate, and the username and password (the thing you know). Effectively, the certificate is your second factor.
In practice, however, a rolling code of some sort, or one-time use code, is better.
Enabling multi-factor authentication can significantly improve the security of your authentication flow by requiring additional information each time a user logs in to your VPN. OpenVPN provides some of those protections with client certificates and, optionally, --tls-auth. In both the case of our DIY setup and the commercial vendor Okta, the script we provided and the API functionality Okta provides serve the same purpose – validating the authentication token selected.