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
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.