Tutorials

Various types of authentication factors

Multi-Factor Authentication (MFA) means using a combination of factors of different types to authenticate a user when she signs in to an application. Factor types include knowledge (“what you know”, a secret, a password), possession or ownership (“what you have”, a key-fob, a USB key, a phone, a smartcard…) and inherence (“what you are”, biometry).

The trouble with ownership

The possession / ownership factor is actually not the plastic or the smartcard itself. It’s a secret information (aka seed) stored in a memory chip called a secure element. Because of the need for secure elements to implement MFA, it has long been too expensive and inadequate for many use cases, especially but not only, the consumer facing ones.

The situation has improved in recent years when hardware secure elements have been progressively replaced with software on a smartphone. inWebo, as many other vendors has an MFA App, inWebo Authenticator. Once activated for a user, inWebo Authenticator stores a seed key specific to that user and uses it, possibly combined with other authentication factors, to generate one-time passwords (OTP).

inWebo Authenticator can seamlessly switch between a connected mode, a stand-alone mode (useful for roaming situations, in-flight, no or bad signal…), and a notification-based mode that prompts the user for her confirmation or additional authentication factors (PIN, fingerprint…) and completes the authentication and sign-in without asking the user to copy-paste an OTP. Nice…

We need MFA, but why do we need a token?

A mobile App is definitely more convenient than a key fob to carry around, but it requires that all users have a smartphone and have downloaded the MFA App, then activated it. There are many situations when this is not the case. Actually, when you think about it, it’s almost never the case. How could we remove this constraint?

This question led us to the idea of In-App MFA, as early as 2010. Instead of using a stand-alone ‘token’ (hardware or App) and have the user enter OTP in an authentication interface (a desktop client, a mobile App, a page in a browser), why not generate the OTP directly from that interface? That would alleviate the need for tokens but also for smartphones, MFA Apps, and even short-text codes.

inWebo mAccess (for native clients) and inWebo Virtual Authenticator (for web applications) are the In-App authentication technologies developed for this. They are available and documented on inWebo developer website.

How does it work?

With In-App MFA, the OTP generation is done by a software library instead of a standalone App. That library – inWebo mAccess for native clients – can be integrated in any mobile App or desktop client. That App or client literally becomes an MFA token. inWebo mAccess manages the user’s unique seed key, i.e. the possession / ownership factor.

At sign-in, the user is prompted by the client for her usual credentials (username and password). There’s no experience change compared to a normal, non-MFA sign-in. Then, the client silently makes a call to an inWebo mAccess function to request an OTP. This call is local to the client.

In a 2-factor authentication scenario, the password is used as an input argument for the OTP calculation function of the mAccess library. That function also uses the user’s unique seed key attached to the user’s App – hence “2-factor”. The client uses the multi-factor OTP returned by mAccess for authentication to the back-end.

In a step-up or 2-step verification scenario, the user’s unique seed key is used to calculate the OTP. The client uses both the user password and the single-factor OTP for authentication to the back-end. It’s also 2-factor but in a different way (for more on that, you can read a blog post about 2FA vs. 2SV)

Secure MFA that users can’t see

The obvious benefit of inWebo mAccess compared to a stand-alone MFA App or ‘token’ is that the user doesn’t copy-paste, interact, or even see one-time passwords.

What are the downsides, if any?

At first, when discovering In-App or in-browser MFA, most people are confused. Since there’s no experience change, they say, what’s the difference with a password-based authentication? Why is that MFA? Here, what you see is not what you get. As explained above, authentication is based on several factors. If someone has hacked the user password but doesn’t have the possession / ownership factor (stored with the client), his authentication attempt fails. 100%.

Ha ha, they say next, but what if the device with the client and the possession / ownership factor is stolen? Well, there’s no difference with stealing a smartcard, a key fob, or a smartphone with an MFA App. If the hacker steals the ownership / possession factor AND somehow manages to guess or phish the user password (which is truly independent because it’s not stored with the client), he will successfully access the user account, whether or not the ownership / possession factor is a library, a key fob, a smartcard, or a smartphone App. There’s no difference.

Mmmm, well, but what if the client is compromised, they say next, hoping that this one is the trump card. If the client is compromised, the hacker will succeed, whatever the authentication method, even the most ‘extreme’ ones such as connected smartcard readers: once the door is open (i.e. the user has logged in), it’s open bar for whoever controls the client.

inWebo mAccess is as secure as the clients used to sign in.

Tokenless secure MFA for any App, native or web

To sum it up, In-App MFA and browser-based MFA bring an optimal security to any mobile App, desktop client, or web application, at no cost in terms of user experience, unlike all other 2nd factor methods such as smartcards, key fobs, MFA Apps, or short-text messages.

As discussed, inWebo mAccess turns any native App or desktop client into a secure ownership / possession factor. inWebo Virtual Authenticator is to web browsers what inWebo mAccess is to native clients: it turns the user’s browser into a secure ownership / possession factor.

With a call to the Log API, you can specify start and end dates, make page requests, or filter results by log category. Each record in the result is provided as a JSON table containing the following data:

Method used (authenticate, loginCreate…)

Result (OK, KO…)

User login

Time and date

IP address (when available)

Authentication device used

Authentication device identifier

…

Contact inWebo if you would like to activate this option for your authentication service.

Following Apple’s introduction of a fingerprint sensor on iPhone 5s in 2013, smartphones increasingly come with a biometric sensor. Market research firms expect that 100% of the installed base will have some form of embedded biometrics by 2020 – this is not yet a commodity, but it will come fast. inWebo has therefore upgraded its solutions to support biometry as a second factor. This option is available on request to all customers, existing as well as prospects still evaluating inWebo (free trial).

Upon activation of this option, it offers 2 alternatives, “biometry enabled” or “biometry forced”. The former applies to services that require users to enter a PIN as a second factor. Users who opt for it replace that PIN with biometrics. The latter mandates biometry as the second factor, therefore adding the authentication service on a smartphone will succeed only if that smartphone has a fingerprint sensor.

Biometry as a second factor can implemented with

inWebo Authenticator version 4.2.0 or higher. The App supports Apple TouchID, as well as fingerprint sensors on Android Marshmallow (6.0+) smartphones.

inWebo mAccess version (0.)2.8 or higher. Developers can use mAccess library to support fingerprint biometry in their App but also virtually any kind of biometry (voice, face…), as long as it is implemented with a “match on card” mechanism (i.e. the biometric data is stored and verified locally on the smartphone). The mAccess library documentation on inWebo developer website provides a complete implementation for fingerprint sensors.

The biometry as a second factor option can be requested by checking a box when you create an evaluation account (here), or when you upgrade a basic plan to a premium one (there). You can also ask our solutions experts about it.

We have a blog post on why browser-based authentication makes sense, explaining why and how we came to develop Virtual Authenticator.

A new and convergent authentication method

Virtual Authenticator is the latest authentication method added by inWebo to its solutions, and the successor of Helium, a browser-based authentication method released in 2012, used to protect millions of identities.

The name refers to inWebo Authenticator, the smartphone App available for iOS, Android, and Windows Phone, which supports on-demand OTP (one-time passwords) as well as OTP triggered by push notifications. The reference goes beyond the name, since Virtual Authenticator proposes a unique and converged user experience with inWebo Authenticator.

In particular, users have the same PIN for a given service on Virtual Authenticator and on inWebo Authenticator. This is the same experience on web and mobile, in both cases just a PIN to enter, no ‘security codes’ or copy-paste or App to launch.

What’s in for me?

From an organization perspective, deploying Virtual Authenticator is, actually, not a deployment. There is no software to install or to distribute to the users. You only need to make a change to your authentication page and to authorize Virtual Authenticator from your inWebo administration account. This is described here.

All things considered, this is the easiest to roll out authentication method.

A smooth transition from inWebo Helium

For those already familiar with inWebo Helium, Virtual Authenticator is not a revolution. It comes with features already available with Helium, such as:

1- or 2-factor OTP generation; it can therefore be used both in step-up authentication and multi-factor authentication scenarios

PIN change

PIN reset

a security self-check based on a secret sentence optionally defined by the user, which can be verified by the user whenever he is asked to enter his PIN in Virtual Authenticator.

As it was the case for Helium, the secret sentence is only displayed after a successful and automatic browser authentication with inWebo servers. It cannot be obtained by phishing. We have slightly changed the way it is presented and made it similar to how websites using SSL certificates are displayed in browsers, since users are now familiar with that.

Virtual Authenticator antiphishing

Additionally, Virtual Authenticator has a keyboard for the PIN-entry, which is especially useful with touch screens.

Helium is still supported!

New customers are now proposed Virtual Authenticator and inWebo Authenticator as a default. Customers already using Helium will not see any change since there is no automatic or required migration to Virtual Authenticator. Helium will continue to be supported for existing customers, but also for new customers needing more customization (e.g. branding or PIN policy).

Can I see it?

Yes, we would love to! You are only 3 clicks away. Just sign up for a free trial account for your organization here. You will be able to use Virtual Authenticator to access your administration account, but also to provide it to users so that they access your applications safely and conveniently.

One of the main difficulties faced when deploying a multi-factor authentication solution (MFA) is to define the “optimal” form factor. For a given level of security, you would like the solution to be both convenient and universal Read More