MFA In-App (Token-less)

Authentification intégrée au navigateur / à l'App

L'utilisation d'une application mobile pour l'authentification des utilisateurs est plus facile à mettre en œuvre que les token hardware ou dongle USB.

Cependant, cette solution exige que tous les utilisateurs possèdent un smartphone et qu'ils aient installé et activé l'application de MFA.

Visual Guard utilise donc une solution qui contourne ce problème et permet une adoption plus large de l'authentification forte.

Plutôt que d'utiliser un token autonome (Application ou hardware) et de faire saisir le password à usage unique par l'utilisateur dans un client lourd, une application mobile ou une page dans un navigateur, l'in-App MFA permet de générer l'OTP (one time password = mot-de-passe à usage unique) directement dans l'interface d'authentification.

Cette approche élimine l'utilisation de token, smartphone, soft-token et même l'envoi de code par SMS pour l'authentification.

Méthodes d'authentification in-App et implémentation

Il existe deux méthodes pour implémenter l'in-App MFA :

• Pour les applications Natives (applications mobiles ou clients lourds) : une bibliothèque MFA, disponible pour toutes les plateformes (iOS, Android, Windows Phone, clients lourds), doit être intégrée dans le code de l'application.
• Pour les applications Web : des bibliothèques javascript MFA pour lesquelles il suffit d'ajouter quelques lignes de HTML au code de la page de connexion de l'application.

La bibliothèque MFA étant intégrée à l'application, native ou web, il n'y a plus rien à installer par l'utilisateur : ni application, ni plugin, ni extension. C'est la raison pour laquelle ce mode est nommé "tokenless MFA" (MFA sans token).

Comment ça marche ?

L'application, le client, ou le navigateur doit d'abord être activé et lié au compte d'un utilisateur.

Le processus est le même qu'avec une App d'authentification ou avec un token hardware. L'application / le client / le navigateur devient littéralement un outil d'authentification, stockant les informations d'identité qui seront utilisées pour l'authentification (le facteur d'authentification "ce que j'ai"). La bibliothèque MFA gère ces informations pour le compte de l'application : émission, échanges avec le serveur d'authentification, mise à jour, protection et utilisation.

Au moment de la connexion à l'application via l'App, le client lourd ou le navigateur, l'utilisateur est invité à entrer un mot de passe ou un caractère biométrique (ou "rien" dans le cas d'un scénario "2e facteur"). La bibliothèque utilise cette information ainsi que les informations d'identité de l'App / client lourd / navigateur pour générer un mot de passe à usage unique (OTP).

L'OTP est utilisé dans la demande d'authentification envoyée au serveur par l'application.

Il y a très peu de changement pour l'utilisateur par rapport à une authentification classique, non-MFA. La facilité d'utilisation est l'un des principaux avantages de l'authentification in-App.

Modèle de sécurité

Comme les OTP ne sont pas affichés, l’authentification multi-facteur intégrée à l’application (in-App MFA) étonne du fait de sa ressemblance avec l’authentification par mot de passe

L'expérience utilisateur est exceptionnelle, mais qu'en est-il de la sécurité ?
Pour faire simple, c'est exactement la même chose que la sécurité d'un token 2FA (two-factor authentication), hardware ou App :

• Pour créer un OTP valide et accéder à un compte d'utilisateur, un hacker a besoin des informations d'identité de la bibliothèque MFA et du code secret (ou caractère biométrique) de l'utilisateur. Le fait que ces informations d'identité sont stockées avec l'App, le client lourd ou le navigateur de l'utilisateur au lieu d'une application MFA distincte ou d'un token matériel ne rend cela ni plus simple ni plus difficile.
• Si l'App, le client lourd ou le navigateur est compromis, le hacker sera capable de se connecter au compte de l'utilisateur et pourra créer des transactions en son nom en passant inaperçu seulement quand une session authentifiée aura été lancée. C'est le cas quelle que soit la méthode d'authentification, in-App ou out-of-band (pour éviter cela, vous devez sceller les transactions utilisateur avec un deuxième canal d'authentification). À cet égard, le MFA intégré aux applications, comme les autres méthodes d'authentification, est autant sécurisé que l'App, le client lourd ou le navigateur utilisé pour se connecter.

L'authentification forte pour n'importe quelle application, native ou web

Contrairement à toutes les autres méthodes de second facteur tels que des cartes à puce, tokens hardware, applications MFA ou SMS, l’authentification multi-facteurs in-App – basée sur une App, un client lourd ou un navigateur – apporte une sécurité optimale à toute application sans dégrader l’expérience utilisateur.