Ofte CA Technical Information

The need to use second-factor authentication (2FA) systems to secure web applications is obvious. The exploitation of weak and stolen credentials perennially tops the list of intrusion methods from reported data breaches.

So why don't more web applications use second-factor authentication?

We believe a common answer is, "It's too hard." It can be difficult to integrate 2FA solutions into existing architectures. Another answer might be, "They aren't as secure as I thought." That's because some 2FA techniques are vulnerable to exploits such as SIM cloning and social-engineering. And most cannot prevent Man-in-the-Middle (MITM) attackers from accessing resources on behalf of a compromised session.

The Ofte Platform was built to provide a highly secure authentication solution for web applications. We do this by extending FIDO to support continuous authentication using our own USB-based hardware keys and backend services.

A Typical Authentication Scenario

Figure 1. A typical authentication scenario using bearer tokens

To better understand how Ofte CA works, it's helpful to review a typical authentication scenario. In this credential-only application, the backend--which could be an identity management platform (IDM)--authenticates a username/password pair and produces a "Credential" token. This token usually takes the form of a JSON Web Token (JWT), the contents of which can be parsed by anyone. Typically these tokens have an expiration time. The application typically stores this token in the browser's local storage and then presents it when accessing or modifying application data.

Several vulnerabilities exist for this authentication technique.

  1. Passwords can become compromised or guessed/brute-forced
  2. Someone eavesdropping (for instance a MITM attack) could reuse the "Credential" token
An example application for this sort of authentication can be found at https://portal.ofte.io

A Typical FIDO Authentication Scenario

Figure 2. A typical FIDO authentication scenario using bearer tokens and a FIDO key

The scenario shown in Figure 2 introduces a FIDO 2FA authentication step. While this addresses the compromised/guessed/cracked credentials issue, it does nothing to address:

  1. Passwords can become compromised or guessed/brute-forced
  2. Someone eavesdropping (for instance a MITM attack) could reuse the "Credential" token

Ofte FIDO Continuous Authentication

Figure 3. Continuous Authentication with Ofte

Ofte Continuous Authentication introduces the concept of an authenticated session. When a user authenticates with an Ofte Key, an authenticated session for the user and Ofte Key is created in the Ofte Services. Every 20 seconds or so, Ofte JS revives this session by interacting with the Ofte Key and the Ofte Services. If not "kept-alive" in this manner, the session will expire and subsequent validation attempts will fail.

Access to your application's protected resources is authorized with

  1. your "Credential" token (no change here)
  2. the Ofte Session Identifier
  3. a one-time token created by the Ofte Key

With the introduction of these addition protections, a MITM attack will fail because they do not possess the Ofte Key which creates the one-time token necessary to access the protected data.

  1. Passwords can become compromised or guessed/brute-forced
  2. Someone eavesdropping (for instance a MITM attack) could reuse the "Credential" token

Ofte Keys

Ofte Keys are FIDO1 and FIDO2-compliant. Both USB Type-A and Type-C based keys are available. They implement Ofte CA, but they can also be used at other sites/apps in which FIDO 2FA is supported.

Other FIDO key brands can be used in a application that employs Ofte CA, however those keys won't enjoy the additional security benefits that Ofte CA gives.

Ofte JS

Ofte JS is responsible for registering and logging in Ofte Keys. It's also responsible for implementing the continuous authentication process which keeps the Ofte Session active in our Services layer.

Importing the JS code:

<script src="https://cdn.ofte.io/js/latest/ofte.js"
	data-auth-service-url="https://[ADDR-OF-YOUR-OFTE-AUTH-SVC]:2357"
	data-debug="true"></script>										
					

All functions return Promises.

Registering an Ofte Key:

ofte.registerKey(username)
  .then(key => {
    console.log('key registered', key)
    // go to next step
  })
  .catch(err => {
    console.log('error registering key', err)
  })		  
					

Logging in with an Ofte Key:

ofte.loginKey(username)
  .then(resp => {
    console.log('logged in', resp)
    // go to next step, Ofte Session will be active
  })
  .catch(err => {
    console.log('error logging in key', err)
  })		  
					

Fetching data protected by an Ofte Key (requires the user be logged in with their Ofte Key):

ofte.fetchStrong('/your/api/items')
  .then(resp => resp.json())
  .then(json => {
    console.log('data retrieved', json)
  })
  .catch(err => {
    console.log('error fetching data', err)
  })		  
					

Ofte Services

Ofte Services is the collection of backend services that implement the functionality of our continuous authentication platform. Depending on your needs, we can provide these services in a variety of configurations:

  • a collection of containers that you can deploy using your preferred container orchestration mechanism
  • a remote instance that we manage as PAAS for you
  • a loaded and configured Linux-based server (hardware) that you install in your managed data center

An important aspect of the Ofte Platform is that no private or secure information is stored in our services or data layer.

Ofte Services also include:

  • an admin REST api with which you can manage sessions, principals and keys
  • adapters for message bus architectures to forward Ofte-specific authentication events to your backend
  • a demo admin GUI that you can use as a basis for your own admin

Integration

Your backend needs to make a small accommodation for Ofte. For those resources that are to be protected by Ofte CA, your code needs to verify (using Ofte Services) that the request is valid. In a nutshell, this basically involves enforcing the existence of specific Ofte HTTP headers, and presenting the values of those headers to Ofte Services for validation.

See our code repository for full integration details.