2FA : Pourquoi la CNIL va l’imposer, comment le tester, les pièges à éviter

Principes du 2FA et variantes courantes

Le 2FA (two-factor authentication) consiste à valider une identité via deux facteurs distincts, parmi :

• Ce que je sais, par exemple un mot de passe ou code PIN ;
• Ce que je possède comme un smartphone, token physique ou app d’authentification ;
• Ce que je suis tel qu’une empreinte digitale ou reconnaissance faciale.

L’objectif est simple : empêcher qu’un accès ne soit accordé sur la seule base d’un identifiant et d’un mot de passe, potentiellement compromis ou réutilisé.

Plusieurs méthodes existent ainsi pour mettre en œuvre un second facteur. Le choix dépend du contexte métier, des contraintes techniques et du niveau d’exposition des interfaces, voici quelques exemples :

• OTP (TOTP/HOTP) : code à usage unique généré par une application (Google ou Microsoft Authenticator) ;
• SMS ou email : code transmis par message ou courrier électronique, encore largement utilisé ;
• Push notification : validation via une alerte reçue sur smartphone (Google ou Microsoft Authenticator) ;
• Clés FIDO2/U2F : dispositif physique (Yubikey, Passkeys, etc.) utilisé sans transmission de mot de passe ;
• Biométrie : empreinte ou visage reconnus via un appareil personnel sécurisé.

Mais ce principe est désormais cadré. Dans sa recommandation de mars 2025, la CNIL recommande la mise en œuvre d’une authentification multifacteur dès lors que :

• les données traitées présentent un caractère sensible ;
• l’accès permet d’agir sur les données personnelles d’un tiers (par exemple : compte utilisateur, dossier de santé) ;
• les comptes utilisateurs sont accessibles en ligne via un portail ;
• l’accès ouvre sur des fonctionnalités à risque (modification de données, changement d’email, suppression de compte, etc.) ;
• ou que l’accès s’effectue depuis Internet (exemple : interface d’administration ou accès distant).

Autrement dit : si une interface en ligne permet d’accéder à des données personnelles ou de les manipuler, la simple combinaison identifiant/mot de passe ne sera plus considérée comme suffisante.

Le 2FA dans la vraie vie : entre affichage et sécurité réelle

Lors de nos audits, la présence du 2FA devient fréquente. Mais comme souvent en sécurité, ce n’est pas la présence qui compte, c’est l’implémentation.

Ainsi, lors de nos tests, nous étudions également ce vecteur d’authentification en profondeur, en nous posant généralement les questions suivantes :

• Le 2FA est-il déclenché sur tous les parcours sensibles (connexion, réinitialisation, modification de compte, ajout d’appareil) ?
• Protège-t-il toutes les interfaces (web, mobile, API, support) ?
• Est-il lié à la session, ou peut-il être contourné via un token, un cookie ou une session persistante ?
• Les OTP peuvent-ils être interceptés, rejoués ou validés hors contexte ?
• Existe-t-il des mécanismes de contournement via des parcours alternatifs ou des canaux secondaires ?
• Y a-t-il des protections contre les abus (push bombing, bruteforce OTP, alertes) ?
• Les sessions, tokens ou appareils déjà validés sont-ils invalidés après une modification critique ?
• Le mécanisme « Se souvenir de moi » est-il correctement encadré (durée, empreinte, révocation) ?

Vulnérabilités courantes rencontrées en audit

Il n’est pas rare de constater que le second facteur n’est pas infaillible, surtout quand il est mal intégré. Voici quelques-unes des vulnérabilités les plus courantes que nous rencontrons en conditions réelles :

OTP réutilisable

• Contexte : Application web protégée par OTP.
• Problème : Le serveur accepte plusieurs fois le même OTP, même pour des sessions ou des appareils différents. Aucun lien entre le token et une session unique.

• Technique : Interception de la requête de validation OTP via BurpSuite, puis rejeu dans le Repeater ou depuis un second navigateur.
• Résultat : Un attaquant interceptant un OTP valide (via phishing ou accès temporaire) peut le rejouer plusieurs fois, sans déclencher d’alerte ni d’invalidation.

Workflows ou fonctionnalités non couverts par le 2FA

• Contexte : L’authentification principale impose un second facteur, mais certains workflows (réinitialisation de mot de passe, changement d’email, ajout d’appareil) ou routes (API, mobile) ne le déclenchent pas.
• Problème : Ces parcours acceptent une authentification simple (login/mot de passe, token, email), sans exiger le second facteur.

• Technique : Cartographie des flows via BurpSuite et appels directs à l’API, parcours de réinitialisation ou modification de compte testés sans 2FA.
• Résultat : Un attaquant peut contourner totalement le second facteur via un flux secondaire non sécurisé ou une fonctionnalité oubliée.

Implémentation maison vulnérable

• Contexte : Le 2FA a été codé « en dur », sans utiliser de solutions éprouvées ou standardisées
• Problème : Plusieurs erreurs critiques sont fréquentes :
  • OTP transmis en clair dans les réponses HTTP (JSON, HTML ou JS), exposant le code OTP côté client ;

• •  Vérification locale sans appel serveur (possible via manipulation réseau) ;

• • Algorithme maison non audité ou prévisible. Exemple : OTP généré en Python via random.seed(int(time.time())). Comme la graine (seed, valeur initiale du générateur pseudo-aléatoire) est basée uniquement sur l’heure, la suite de codes est prédictible : un attaquant peut régénérer les mêmes OTP côté client, et deux requêtes faites dans la même seconde retourneront le même OTP.

• • Absence d’expiration du code ou fenêtre de validité trop large.

• Technique : Inspection du DOM/JS, reverse d’app mobile, interception et modification des requêtes dans BurpSuite.
• Résultat : L’authentification semble présente mais peut être triviale à contourner une fois la logique technique comprise.

Push bombing (SPAM MFA)

• Contexte : L’authentification repose sur une notification push à valider depuis un smartphone.
• Problème : Aucun mécanisme ne limite ou ne supervise le nombre de requêtes MFA envoyées.
• Technique : Envoi massif de requêtes d’authentification (via script ou outil), jusqu’à ce que la victime accepte par erreur, fatigue, automatisme ou en combinant avec des attaques par ingénierie sociale.
• Résultat : Une simple pression ou une inattention suffit à valider une session malveillante. Exploitable même avec un second facteur en place.

Exemple d’envoi multiple de requête d’authentification 2FA avec Intruder de Burp

Recommandations et bonnes pratiques

En audit, ce que l’on recommande souvent c’est :

• Privilégier les solutions éprouvées (TOTP, FIDO2, push bien intégré), pas de code maison ;
• Couvrir tous les parcours sensibles : login, reset, changement d’email, ajout d’appareil ;
• Lier l’OTP à la session, pour éviter les rejeux.
• Ne pas oublier les interfaces secondaires : API, mobile, support ;
• Encadrer les comportements suspects : push multiples, changements d’appareil.

Limites des tests automatisés

Les failles liées au 2FA échappent souvent aux scans automatisés, car elles requièrent des analyses manuelles approfondies, comme celles que nous réalisons lors de nos audits.

Les tests automatisés passent souvent à côté des failles 2FA. En effet, beaucoup de vulnérabilités viennent de mauvaises intégrations ou de contournements qui ne se détectent qu’en explorant manuellement les différents parcours. Il faut aussi tenter des attaques ciblées comme le rejeu d’OTP ou le push bombing pour vraiment mesurer la robustesse. C’est ce genre de test manuel orienté que nous menons pour révéler ces failles souvent invisibles aux scans automatiques.

Conclusion

Le 2FA n’est plus une sécurité « bonus » : c’est une exigence, à la fois réglementaire et sécuritaire. L’identifiant et le mot de passe seuls ne suffisent plus et ne devraient plus suffire depuis longtemps.

Mais sur le terrain, on peut voir des 2FA incomplets : activés sur l’interface web, mais absents des APIs, contournables via un reset, vulnérables au push bombing. Ce type d’implémentation ne protège pas, il donne une illusion de sécurité.

Une authentification forte, c’est un dispositif cohérent, aligné sur les usages et résistant aux attaques logiques. Chez Sysdream, c’est ce qu’on teste sous tous les angles : web, mobile, API, comportement utilisateur, rejeu de jetons, abus de fallback.

Le 2FA ne doit pas simplement cocher une case RGPD. Il doit tenir face aux vraies attaques. Et ça, ça se vérifie.