First, let’s look at what Multi-Factor Authentication or MFA is. Most applications use a username/password combination to authenticate or log in their users. Some of them use a second method on top of the first, like a token or code sent via SMS. That is commonly called 2FA or two-factor authentication.

In light of countless security breaches across the industry, 2FA is becoming increasingly popular In the event that one of the methods used for authentication is compromised, an additional check will make it more difficult to impersonate a user.

The methods of authenticating users are also called factors, or pieces of evidence required for authentication, which is where the term multi-factor authentication originates.

Multi-factor implies more than one factor is used, so technically 2FA is the minimum number of factors to be used for MFA. Depending on your application’s security level, you can choose to increase the number of factors used to authenticate your users. Before we get ahead of ourselves and ask for ten pieces of data, let’s look at the available options.

The options for authentication factors

Here are the different types of evidence you can ask users to provide: :

• Knowledge - Something the user knows — a password, for example. Most authentication mechanisms use this factor. And, usually, it's the only one. Or at least the first one.
• Location - Somewhere the user is — the office building, for example. Most corporate networks used to be geofenced back in my day. Still, with the rise of remote work, especially during the pandemic, this factor has severely fallen out of favour. Not to mention, most use cases for MFA work from anywhere in the world, so being locked inside a geographical area might be irrelevant. Location might not necessarily mean geolocation though. In some cases, you can use the IP address as a factor instead. Think about all your “intranet” websites that are only accessible from inside the corporate VPN.
• Possession - Something the user has — a token or a phone number, for example. This is the second most commonly used factor. When people talk about 2FA, this factor is usually the second factor (e.g., a second password that is sent via SMS to your phone). Sadly, having worked with SMS for a while, it's only as secure as your phone service provider. While this factor is preferred by someone like your banking provider, that also makes it a great incentive to bypass it, for many bad actors. It's also not free to use, as there is usually a fee associated with sending an SMS.
• Proximity - Something the user has — unlocking a Macbook when an Apple Watch is nearby, without using a password, for example. While it's usually used in physical devices, this factor stops being useful for web apps, requiring sensors to work. It also has the inherent flaw that both devices that are supposed to be close to each other can be stolen at the same time.
• Biometric - Something the user is or some physical characteristic the user has — the fingerprint or the face, for example. You'll see this as the most commonly used authentication mechanism for phones. When coupled with physical sensors, it's tough to beat. Since biometrics are free, they should be the default mechanism in 2FA. Unfortunately, you need advanced sensors to provide a high degree of security. Earlier versions of Face Detection on phones could be fooled with a person’s picture instead of the actual person, for example.

Again, depending on your application’s security level, you can choose how many factors you need — hence the multi-factor authentication mechanism involved.

What about risk-based authentication?

There is another trend emerging in application security called risk-based authentication (RBA). It relies on multiple factors and spreads out the authentication points based on the current user transaction and the security level needed for that.

RBA is used by companies like Google, Facebook, LinkedIn, and Amazon. For example, posting on Facebook only requires a user to be logged in but accessing profile settings requires an additional factor. The additional factor is usually an IP address or some other data if the IP address you’re using at the moment is not the one you commonly use for your account.

One of the factors that's well suited in both cases, and trending recently, is the biometric authentication factor. It turns out that some other things are just as unique as a fingerprint or your face.

For example, the way you type is pretty unique. So why not use that as an authentication mechanism? It doesn’t seem as easy to compare as a face or a fingerprint. No worries, someone else has done all the heavy lifting for you.

TypingDNA’s typing biometrics technology

Cue TypingDNA. That's right, there is an API that fingerprints people by the way they type. That makes biometric authentication accessible without a physical sensor — and just as secure as a fingerprint. It also happens to be free for your users (e.g., compared to possession factors).

Let's look at how you can add this extra layer of biometric authentication to your multi-factor authentication process.

The TypingDNA API allows you to recognize people by the way they type, both on a keyboard or a mobile device. It also doesn't require any particular hardware or sensor. The SDKs act as recorders for the way users type on web apps and mobile apps. You can check those recordings against a previously saved typing "DNA" — hence the name.

Personally, I've been watching TypingDNA for a while, and I'm impressed with how natural and simple it is to add on top of a traditional username/password authentication model.

An average username/email combination has around 30 characters. That’s plenty of characters to use typing biometrics with a high degree of confidence. You can record and store the typing pattern when a user signs up and then verify the pattern every time they log in. It has the benefit of being a seamless experience. You’re checking two factors in the same step instead of traditional MFA, where each factor requires an extra step.

Implementing with the TypingDNA API

In terms of implementing it, it's a three-part system. The first part is a recorder (TypingDNA provides this) that lives in your application and records the way users type when they perform a certain action, like logging in. The second part is your own back-end server application, and that's where the recorder sends the biometrics data. For the final step, you check that data against the saved biometrics TypingDNA has, using their REST API.

It sounds pretty easy, doesn't it?

It is.

One of the advantages of using this in an MFA flow is that — as opposed to most 2FA solutions — the second step here is invisible to the user. You're using two factors that you're gathering at the same time, so there is no extra step for your users — meaning there are fewer reasons to not complete the verification process. I'd say that is a big user experience win.

This approach can also replace some other existing forms of text or typing verification currently used — like Captcha. Instead of asking someone to type a single garbled word that’s hard to read or click several pictures of bikes, you can ask them to type a provided passphrase.

This way, you’re not only improving the accessibility of your application, but you’re also going the extra mile in verifying the user is “not a robot.” In other words, you’re not only verifying a user is a person but with matching typing patterns, you’re verifying the user is the right person to access your application.

What’s next?

If I’ve convinced you biometric authentication is the future, here are some resources that will help you integrate your application with the TypingDNA API.

First, sign up here. And then use the:

• Tutorials to help you get started.
• API Documentation to help you when you’re implementing this into your application.
• GitHub Repositories full of demos and example implementations.
• Case Studies, Webinars, Blog, Whitepapers (and others) in case you need to sell this to your Product Manager first.

Here’s to adding MFA to your applications — the easy way — with TypingDNA!