Tests E2E automatisés avec Authentification Multi-facteur – Jonathan Bernales

Nous poursuivons notre série d’articles consacrés aux tests de systèmes intégrant des mécanismes de sécurité Multi-Facteur (MFA ou 2FA).

Dans notre précédent article, nous avons exploré pourquoi les entreprises opérant dans des secteurs réglementés doivent impérativement adopter ces mécanismes pour renforcer leur sécurité.

Bien qu’il existe une grande variété de solutions MFA, la majorité des entreprises privilégient celles qui offrent une expérience utilisateur fluide et simple, comme le MFA via SMS, email ou TOTP.

Dans cet article, nous nous pencherons sur un sujet crucial : quelles sont les contraintes liées au test des flux intégrant du MFA, et quelles stratégies peut-on adopter pour les surmonter ?

1. Contraintes liées à l’automatisation des tests avec MFA

1.1 Dépendance à des dispositifs externes

Le MFA requiert, comme son nom l’indique, l’utilisation de dispositifs externes, tels que des téléphones pour recevoir des SMS ou des applications générant des codes TOTP. Cette exigence complique l’automatisation des tests, surtout lorsque plusieurs comptes sont impliqués. Concrètement, cela a des impacts sur les systèmes suivants :

• Les emails : Bien souvent les équipes QA utilisent des alias (utilisateur+alias@domaine.com) pour la création de comptes en illimité, cependant cela ne résout pas le problème d’automatisation des tests et la fonctionnalité est parfois désactivée en entreprise.
• SMS MFA : Si chaque compte doit être associé à un numéro unique, cela implique potentiellement une carte SIM par compte, et donc un téléphone associé. Cela rend difficile le partage de comptes de test et on peut finir par se retrouver à partager des téléphones de test entre collègues…
• TOTP : Nécessite la gestion d’une clé secrète, rendant l’automatisation complexe car celle-ci n’est plus disponible une fois initialisée.

1.2 Des tests difficilement automatisables

Les flux MFA impliquent des interactions avec des systèmes externes, rendant l’automatisation difficile et souvent déconseillée, notamment pour des services tiers comme Outlook ou d’autres systèmes de messagerie. En effet, lancer un chantier d’automatisation pour récupérer des informations sur des services tiers peut s’avérer coûteux et souvent pas accepté par ces providers (qui mettent tout en œuvre pour détecter et bloquer les connexions de robots).

1.3 La (mauvaise ?) approche adoptée #1 : Désactiver l’envoi de MFA en environnement de recette

Bien souvent, certaines équipes choisissent de limiter le temps consacré à la mise en place du MFA. Lorsqu’il devient un obstacle dans les processus de test et d’automatisation, il est fréquemment désactivé, ce qui engendre plusieurs risques importants :

• Risque de sécurité accru :
  • Le MFA devient optionnel, affaiblissant la protection des comptes sur l’environnement de recette, car, même si l’impact semble limité, cela introduit la présence de comptes moins sécurisés.
  • Cette approche conduit à tester des comportements divergents de ceux de l’environnement de production, ce qui compromet la validité des tests.
• Tests moins représentatifs :
  • Les tests effectués dans l’environnement de recette ne reflètent plus les conditions réelles de production car une partie du processus est manquante.
  • Cela augmente le risque de défaillances en production, où des bugs peuvent émerger pour la première fois alors qu’ils n’avaient pas lieu en recette.
• Risque d’erreurs humaines :
  • La divergence des configurations entre les environnements de recette et de production complique la gestion des déploiements.
  • Cela peut entraîner l’application involontaire de politiques de sécurité incorrectes en production, comme par exemple la désactivation de l’envoi de codes MFA.
• Tests incomplets :
  • En ignorant des étapes clés, comme le processus de connexion ou la validation des transactions, les tests deviennent partiels.
  • Cette omission limite la capacité à détecter des problèmes liés à des fonctionnalités critiques comme le processus de login ou de validation de transactions.

1.4 La (mauvaise ?) approche adoptée #2 : Interception du MFA en environnement de recette :

Bien que meilleure que la première approche, celle-ci introduit tout de même le risque de divergence de configuration entre environnements et un risque de déploiement en production d’une configuration erronée.

1.5 Une approche coûteuse permettant d’atteindre la cible : S’interfacer avec les providers tiers :

Cette méthode, bien que parfois onéreuse et complexe, peut s’avérer très bénéfique si vos fournisseurs de services (emails ou SMS) offrent des APIs ou des interfaces compatibles avec des outils d’automatisation comme Cypress ou Robot Framework. Des outils comme Eggplant peuvent permettre d’atteindre ce but aussi. Ces intégrations permettent d’extraire directement les codes MFA pour les intégrer dans vos scripts de test automatisés. Toutefois, il est souvent nécessaire de communiquer de manière proactive avec ces fournisseurs, car ils peuvent être réticents à autoriser un accès robotisé à leurs systèmes. Malgré ces défis, cette approche garantit des tests réalistes et conformes aux scénarios de production.

2. Mécanismes pour automatiser et tester des flux E2E avec MFA

2.1 S’outiller pour aligner les environnements de test sur la production

Il est crucial de maintenir une parité entre les environnements de test et de production pour détecter efficacement les problèmes potentiels. Pour cela, il peut valoir le coup de s’interfacer avec un prestataire vous permettant de récupérer les codes MFA (email, téléphone (SMS ou voix), API) afin de bénéficier des avantages suivants :

• Détection accrue des problèmes UX/UI : En reproduisant fidèlement l’environnement de production, les tests peuvent identifier des anomalies dans l’expérience utilisateur ou l’interface. Ainsi, l’investissement fait sur l’automatisation de tests d’interface sera rentabilisé en apportant la certitude que le comportement en recette est identique à celui de production.
• Gestion du throttling et des limites : Tester dans des conditions similaires à la production permet de comprendre comment le système réagit à des contraintes telles que la charge ou des quotas d’utilisation. Par exemple, cela peut permettre de détecter des faiblesses sur les services d’envoi de codes MFA par email ou téléphone.
• Validation des services tiers : Si vous travaillez avec des tiers, cela garantit que les intégrations fonctionnent correctement et que les messages ne sont pas perdus. On peut d’ailleurs en profiter pour effectuer des tests de charge pour détecter d’éventuelles pertes.

2.2 Approches pour les tests manuels en équipe

Pour les tests manuels, des solutions collaboratives peuvent faciliter la gestion des MFA au sein d’une équipe QA.

• Email : Utiliser des alias dans une boîte mail partagée, tels que testing+xyz@entreprise.io, permet de centraliser la réception des codes MFA envoyés par email et d’y avoir accès au sein de l’équipe QA. Si cela n’est pas autorisé voire trop lourd sur vos processus, des services tiers proposant des mailboxes virtuelles comme GetMyMFA (https://get.mymfa.io) proposent ce type de boîtes mail.
• SMS : Des solutions comme GetMyMFA offrent des numéros de téléphone virtuels privés pour recevoir les codes MFA, évitant ainsi la nécessité de multiples dispositifs physiques. D’autres solutions gratuites existent comme Receive-SMS-Free.cc, mais celles-ci proposent des numéros de téléphone partagés et publics sur internet. Cela pose le risque de voir sa société référencée sur Google à travers ses codes MFA… Pas terrible à mon sens.
• TOTP : Partager les clés secrètes via des gestionnaires de mots de passe sécurisés comme Bitwarden ou 1Password facilite l’accès aux codes temporaires pour l’équipe. Ainsi, plus besoin de garder un QR Code TOTP sur un téléphone physique partagé. Ces outils permettent aussi de gérer finement les accès aux différents secrets.

2.3 Stratégies pour l’automatisation des tests

L’automatisation des tests MFA nécessite des outils capables de gérer efficacement les différentes méthodes d’authentification, tout en évitant de perdre du temps sur l’interfaçage manuel. Comme évoqué précédemment, certains prestataires, comme Microsoft Outlook, sont souvent réticents à permettre une récupération programmatique des codes MFA, ce qui complique les tests.

Pour surmonter cette difficulté, une approche consisterait à utiliser des outils spécialisés. Ces derniers offrent des API dédiées, permettant d’extraire et de récupérer les codes MFA directement sans avoir à se soucier d‘efforts d’intégration. Voici quelques exemples par type de support :

• Email : Des services tels que MailSlurp, Mailosaur ou GetMyMFA permettent de générer des adresses email temporaires et de recevoir les messages. Les codes MFA sont donc extraits directement des emails et exposés via API. En voici un exemple :

• SMS : L’utilisation de numéros de téléphone virtuels via des services comme GetMyMFA permet de recevoir des SMS de vérification sans nécessiter de cartes SIM physiques, simplifiant ainsi l’automatisation des tests de flux MFA par SMS. Il est alors possible de partager un ou plusieurs numéros de téléphone entre plusieurs utilisateurs facilement.
• TOTP : De la même façon que vu précédemment, des prestataires offrent la possibilité d’importer des clés TOTP privées afin d’en exposer le code OTP via API.

Conclusion

Tester efficacement des flux intégrant des mécanismes de sécurité Multi-Facteur (MFA) reste un défi pour les équipes QA, qui vont bien souvent désactiver la chose en environnement de recette. Cependant il est essentiel de les tester pour garantir la fiabilité et la sécurité des systèmes en production. Les contraintes liées à l’automatisation et aux tests manuels, notamment la gestion des dispositifs externes et l’interaction avec des services tiers, montrent qu’une approche simpliste ou bâclée peut engendrer des risques importants, que ce soit en termes de sécurité, de validité des tests, ou d’expérience utilisateur.

L’utilisation d’outils spécialisés, tels que des services de gestion de boîtes email ou de numéros virtuels, et des stratégies collaboratives pour les tests manuels permettent de s’approcher au plus près des conditions de production. Ces approches non seulement réduisent les divergences entre les environnements de test et de production, mais elles renforcent également la capacité des équipes à identifier des problèmes critiques avant le déploiement des solutions.

En conclusion, l’adoption d’une stratégie réfléchie pour tester le MFA, combinant outils adaptés, processus collaboratifs et bonnes pratiques d’automatisation, est essentielle pour relever ce défi. Cela permet de garantir que le fonctionnement des flux MFA au sein des systèmes répond à l’attendu de façon précise et réplicable. Ainsi

Non seulement cela garantit la robustesse des flux MFA, mais cela protège également les utilisateurs finaux tout en permettant une meilleure détection des anomalies. Avec une telle démarche, les entreprises peuvent s’assurer que leurs systèmes sont à la fois sécurisés et fiables, tout en offrant une expérience utilisateur de qualité.

A propos de l’auteur: Jonathan Bernales

Je suis CTO chez Germen, une InsurTech mettant en place des solutions à destination de clients entreprises et particuliers. Je m’intéresse particulièrement à l’automatisation et aux mécanismes garantissant la livraison de code de qualité dans des environnements complexes, tout en assurant un haut niveau de sécurité.