In-App MFA: l’authentification intégrée à un navigateur ou à une App

in-App MFA  

Utiliser une application mobile pour authentifier des utilisateurs est certes plus pratique que de les équiper avec un token hardware ou un dongle USB qu’il leur faudrait toujours avoir avec eux, mais cela exige que tous les utilisateurs aient un smartphone et qu’ils aient téléchargé puis activé l’application MFA. Comme il y a beaucoup de situations où cela ne peut pas être le cas, il serait souhaitable de contourner cette contrainte limitant l’adoption de l’authentification forte.

Cette question nous a conduit à l’idée d’in-App MFA : au lieu d’utiliser un «token » autonome (hardware ou App) et de faire saisir les OTP par les utilisateurs dans une interface d’authentification (un client lourd, une application mobile, une page dans un navigateur), pourquoi ne pas générer l’OTP directement dans cette interface? Cela permettrait de se passer – pour l’authentification – de “token”, mais également de smartphones, de soft-token, et même de codes envoyés par SMS.

Les méthodes d’authentification inWebo in-App et comment les implémenter

Depuis l’idée de MFA in-App en 2010, inWebo a développé 2 méthodes d’authentification selon ce principe et les a déployées avec succès auprès de nombreux clients:

  • inWebo mAccess, une bibliothèque MFA pour les applications natives (applications mobiles comme clients lourds). mAccess est disponible pour toutes les plateformes (iOS, Android, Windows Phone, clients lourds). Pour l’implémenter, la bibliothèque doit être incluse dans le code de l’application.
  • inWebo Virtual Authenticator and inWebo Helium, des bibliothèques javascript MFA pour les applications web. Pour les implémenter, quelques lignes de HTML doivent être ajoutées au code de la page de connexion de l’application.

Les bibliothèques In-App et leurs documentations sont disponibles sur le site développeur inWebo. Notez que puisque la bibliothèque MFA est intégrée à l’application, native ou web, il n’y a rien de plus à installer par l’utilisateur: pas d’application, de plugin ou d’extension. C’est la raison pour laquelle nous appelons aussi ce mode « tokenless MFA » (MFA sans token).

Comment ça marche?

L’application, le client ou le navigateur doit initialement être activé et lié au compte d’un utilisateur. Cela se fait exactement de la même manière qu’avec une App d’authentification ou avec un token hardware. Cette application / client / navigateur devient alors 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 inWebo gère ces informations pour le compte de l’application: émission, échanges avec le serveur inWebo, 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. L’absence de désagrément est l’un des principaux avantages de l’authentification in-App. Ceci est illustré dans la courte vidéo inWebo explicative disponible sur la page d’accueil.

Quel est le modèle de sécurité?

L’authentification multi-facteur intégrée à l’application (in-App MFA) est de prime abord déconcertante car les OTP ne sont pas affichés et cela ressemble vraiment à une authentification par mot de passe. L’expérience utilisateur est exceptionnelle, mais quelle est la sécurité?

La réponse rapide est la suivante: c’est exactement la même chose que la sécurité d’un token 2FA, hardware ou App. Il y a 2 aspects à considérer pour cela:

  • 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 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 pas 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 une fois qu’une session authentifiée aura été lancée, pas avant. Cela est vrai 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

Pour résumer, l’authentification multi-facteurs in-App – basée sur une App, un client lourd ou un navigateur – apporte une sécurité optimale à toute application et cela ne se fait pas au détriment de l’expérience utilisateur, contrairement à toutes les autres méthodes de second facteur tels que des cartes à puce, tokens hardware, applications MFA ou SMS.

ESSAI GRATUIT       DEMANDER UNE DEMO       CONTACTER NOS EXPERTS