Client-based (mAccess) and browser-based (Helium)
A mobile App for MFA is definitely more convenient than a key fob or USB dongle to carry, but it requires that all users have a smartphone and have downloaded the MFA App, then activated it. Since there are many situations when this is not the case, how could we remove this constraint?
This question led us to the idea of in-App MFA: instead of using a stand-alone ‘token’ (hardware or App) and have the user enter an OTP in an authentication interface (a desktop client, a mobile App, a page in a browser), why not generate the OTP directly in that interface? That would alleviate the need for tokens but also for smartphones, MFA Apps, and even short-text codes.
inWebo in-App authentication methods and how to implement them
Fast-forward: since the idea of in-App MFA in 2010, inWebo has developed 2 authentication methods and successfully deployed them with numerous customers:
- inWebo mAccess, a library for client-based MFA for native applications (mobile Apps as well as desktop clients). mAccess is available for all platforms (iOS, Android, Windows Phone, desktop clients). To implement it, the library needs to be added to the code of the application.
In-App libraries and their documentations are available from inWebo developer website. Note that since the in-App library comes built in with the application, native or web, there’s nothing extra to install by the user: no App or plugin or extension. We also call it “tokenless MFA”.
How does it work?
The App, client, or browser initially needs to be activated and linked to a user. This is done exactly the same way as with a MFA soft-token. That App or client or browser then literally becomes an MFA token, storing credentials that will be used for authentication. The library manages these credentials: issuance or exchange with the inWebo authentication server, update, protection, and use.
At sign-in in an App, a client, or a web browser, the user is prompted for a password or a biometric trait (or not even in a 2-step authentication scenario). The library uses this information, as well as the the App / client / browser authentication credentials to generate a one-time password (OTP). The OTP is used in the authentication request sent to the server.
There’s very little change for the user compared to a normal, non-MFA authentication. The lack of friction is one of the great benefits of in-App authentication. This is illustrated in the short inWebo explainer video available on the home page.
What’s the security model?
In-App MFA is disconcerting at first since it doesn’t display the OTP and it really looks like a password-based authentication. The user experience is great, but what’s the security?
The short answer is: this is exactly the same as the security of a 2FA token. There are 2 aspects to consider for this:
- To forge a valid OTP and access a user account, a hacker needs the user’s “library credentials” and the user’s secret (or biometric trait). The fact that the library credentials are stored with the user’s App, client, or browser instead of a separate MFA App or hardware token doesn’t make it easier or harder.
- If the App, or client, or browser is compromised, the hacker will be able to create transactions and go unnoticed once an authenticated session has been initiated, not before. This is true whatever the authentication method, in-App or out-of-band (to prevent this, you need to seal user transactions with a second authentication channel). In this regard, in-App MFA, like other authentication methods, is as secure as the App, client, or browser used to sign in.
Tokenless secure MFA for any App, native or web