Le MFA bombing (ou MFA fatigue) : voilà une attaque particulière dont on a beaucoup entendu parler suite au hack de la société Uber. Si la méthode est encore peu répandue, il est important de comprendre comment elle fonctionne, et comment l’éviter, tant du côté utilisateur que développeur d’application.
Table des matières
Qu’est-ce que le MFA Bombing ?
Le MFA bombing (ou MFA fatigue) porte en réalité mal son nom. Elle ne concerne pas l’ensemble des authentifications multifacteur, et marche d’ailleurs mieux contre le passwordless que contre la MFA. C’est la notification push envoyée sur votre téléphone qui est sensible à cette attaque.
Le problème de ces notifications push d’authentification, c’est que leurs implémentations est souvent simples : elles vous demanderons simplement de cliquer sur « oui » sans informations supplémentaires quant à la provenance de la demande. Une erreur de clic peut être vite arrivée. Et c’est sans compter l’inventivité des hackeurs, qui se sont dit qu’en envoyant de nombreuses demandes l’une après l’autre, l’utilisateur fatigué allait finir par en accepter une, par erreur ou par résignation. Processus qui, comme on l’a vu dans le cas d’Uber, fonctionne plutôt bien.
Comment s’en protéger ?
La MFA toujours préférable au pur passwordless
On en parle dans l’article L’authentification dans les applications, mais assurez-vous d’avoir toujours deux méthodes d’authentification. Un mot de passe complexe, protégé dans un gestionnaire de mot de passe, et régulièrement changé. C’est la base, mais une base importante !
Si vous vous connectez uniquement via une notification push, c’est très confortable pour vous, mais cela vous met fortement à risque sur une attaque de MFA Fatigue.
De même, avoir un mot de passe trop simple, ou inchangé depuis trop longtemps, ne vous protège plus. Restez toujours vigilant·e·s, et au moindre doute, n’hésitez pas à changer le(s) mot(s) de passe à risque.
Soyez exigeants sur la méthode de MFA
Toutes les méthodes de MFA ne se valent pas. Par exemple, la notification push d’authentification de Microsoft se veux plus sécurité que le simple « oui / non » habituel. Elle vous propose un numéro, qu’il faudra faire correspondre avec l’authenticator de votre téléphone pour autoriser la connexion. Cela empêche par exemple que vous acceptiez par inadvertance la demande d’un pirate qui la lance au même moment que vous.
Un bon point de départ pour savoir si la sécurité mise en place est suffisante, c’est d’e’essayer de se mettre à la place de quelqu’un de mal intentionné qui voudrait retourner le système contre vous. Si ça vous semble difficile, c’est un bon point de départ.
Privilégiez les tokens physiques
On l’a évoqué sur l’article L’authentification avec FIDO et WebAuthn, les clés de sécurité physique sont un excellent moyen d’apporte une authentification multifacteur sécurisé. Et avec ce type d’équipement, vous n’êtes plus sensible aux attaques de MFA Bombing / MFA Fatigue.
Il est important de noter que les comptes Microsoft et Google, ainsi que les machines Windows sont déjà compatibles avec ce type de device. Voir la liste des produits certifiés FIDO.
Comment protéger son application du MFA Bombing ?
Implémenter le protocole WebAuthN
Le protocole WebAuthN est un excellent moyen de proposer une double authentification sécurisée à l’utilisateur. Pour plus de renseignements sur le protocole et ses possibilités, n’hésitez pas à consulter les sites https://webauthn.io/ et https://webauthn.guide/.
Préférez les OTP aux notifications push
Les OTP (avec Microsoft Authenticator ou Google Authenticator par exemple) ne sont pas exempts de défauts non plus. Cependant, ils ont le mérite d’être faciles à implémenter, et de ne pas être sujet au bombardement de demande externe.
Évitez les notifications push trop simples
Le principal problème du MFA fatigue est la possibilité d’envoyer de nombreuses requêtes illégitimes en peu de temps à l’utilisateur. Si vous choisissez tout de même d’utiliser les notifications push, vérifiez que la notification en question apporte un maximum d’information à l’utilisateur (localisation, ip, heure précise) et possède un minimum de sécurité supplémentaire (OTP, énigme, etc.). Dans l’idéal, de multiples demandes rejetées devraient amorcer un blocage temporaire.