2FA : comment fonctionne l’authentification à deux facteurs

Le 2FA (authentification à deux facteurs) exige deux preuves d’identité prises dans deux familles différentes : ce que vous savez, ce que vous possédez, ce que vous êtes. Un mot de passe suivi d’un code à six chiffres généré par une application couvre la majorité des cas, mais seule une clé FIDO2 résiste à un site de phishing qui relaie vos saisies en direct.

Sommaire

Deux facteurs, pas deux mots de passe

Un facteur d’authentification appartient à l’une des trois familles : la connaissance (mot de passe, code PIN, réponse secrète), la possession (téléphone, clé cryptographique USB, carte à puce), l’inhérence (empreinte, visage). Le 2FA impose d’en présenter deux qui ne viennent pas de la même famille. Mot de passe suivi d’une question secrète, ce n’est pas du 2FA : les deux tiennent dans la même case, et un attaquant qui a fouillé vos réseaux sociaux franchit les deux avec le même effort.

Le vocabulaire flotte. « Double authentification » et « validation en deux étapes » (2SV) désignent en général la même chose commercialement, mais la nuance compte : un code envoyé sur une boîte mail protégée par le même mot de passe réutilisé, c’est deux étapes et un seul facteur réel. MFA est le terme générique pour deux facteurs ou plus ; le 2FA en est le cas particulier à exactement deux.

Quelle méthode choisir, et ce qu’elle encaisse

Toutes les méthodes ne protègent pas contre les mêmes attaques. Le tableau ci-dessous se lit par colonne d’attaque, pas par note globale.

Le NIST classe l’envoi de code par SMS comme « restricted » dans la publication SP 800-63B (section 5.1.3.3), en raison du détournement de numéro et de l’interception réseau. Ça ne veut pas dire inutilisable : une étude publiée par Google avec l’université de New York et UC San Diego en mai 2019 mesurait qu’un code SMS bloquait 100 % des bots automatisés et 96 % du phishing de masse, mais seulement 76 % des attaques ciblées. Un SMS vaut donc largement mieux que rien face au bourrage d’identifiants, et ne vaut pas grand-chose face à quelqu’un qui vous vise nommément.

La clé FIDO2 (ou son équivalent logiciel, la passkey) est la seule à casser le phishing par construction : la signature produite est liée au nom de domaine affiché dans le navigateur. Sur un faux domaine, l’authentificateur ne trouve aucune clé enregistrée et ne signe rien. Ce n’est pas de la vigilance de l’utilisateur, c’est le protocole qui refuse.

Méthode	Résiste au détournement de SIM	Résiste au phishing en temps réel	Remarque
Code par SMS	Non	Non	Classée « restricted » par le NIST (SP 800-63B)
Code par e-mail	Oui	Non	Retombe entièrement sur la sécurité de la boîte mail
TOTP (application)	Oui	Non	RFC 6238, secret partagé stocké des deux côtés
Notification push	Oui	Partiellement	Sans code à recopier, vulnérable au harcèlement de notifications
Clé FIDO2 / passkey	Oui	Oui	La signature est liée au domaine, un site clone n’obtient rien

Ce qu’il y a réellement dans un code à six chiffres

Le code de votre application d’authentification suit la RFC 6238 (TOTP), qui n’est qu’une variante de la RFC 4226 (HOTP) où le compteur est remplacé par le temps. Le téléphone calcule un HMAC-SHA1 du secret partagé et du nombre d’intervalles de 30 secondes écoulés depuis le 1er janvier 1970, applique une troncature dynamique, puis prend le résultat modulo 1 000 000. Rien ne circule sur le réseau : les deux côtés font le même calcul en aveugle, ce qui explique pourquoi ça fonctionne en mode avion.

Le QR code de l’enrôlement n’est pas magique, c’est une URI en clair du type otpauth://totp/Serveur%20prod:lucas?secret=JBSWY3DPEHPK3PXP&issuer=Serveur%20prod&period=30&digits=6. Le champ secret est en base32, typiquement 160 bits. Conséquence pratique : une capture d’écran de ce QR dans un dossier partagé équivaut à un double permanent de votre second facteur. Conséquence utile aussi, puisque conserver ce secret hors ligne permet de ré-enrôler un téléphone perdu sans passer par le support.

Pour vérifier qu’un secret est bon avant de mettre un service en production, oathtool le calcule en une ligne : oathtool --totp -b JBSWY3DPEHPK3PXP. Si le code obtenu ne correspond pas à celui du téléphone, le problème est presque toujours l’horloge, pas le secret.

Période : 30 secondes (paramètre period)
Longueur : 6 chiffres, soit 1 000 000 de valeurs possibles
Algorithme par défaut : HMAC-SHA1, encore majoritaire malgré SHA-256 disponible
Tolérance serveur : souvent une fenêtre avant et après, soit environ 90 secondes d’acceptation

Ajouter un second facteur à SSH sans se verrouiller dehors

Sur Debian ou Ubuntu, le module PAM de Google Authenticator suffit. Installez libpam-google-authenticator, puis lancez la commande google-authenticator sous le compte concerné : elle génère le secret, affiche le QR et écrit cinq codes de secours dans ~/.google_authenticator. Ce fichier appartient à l’utilisateur, il n’y a pas de base centrale.

Ajoutez ensuite auth required pam_google_authenticator.so dans /etc/pam.d/sshd, et dans /etc/ssh/sshd_config : UsePAM yes, KbdInteractiveAuthentication yes (l’ancien nom ChallengeResponseAuthentication est déprécié depuis OpenSSH 8.7), puis AuthenticationMethods publickey,keyboard-interactive.

Attention à la ponctuation de cette dernière ligne, c’est le piège classique. La virgule signifie « les deux, dans cet ordre » ; un espace aurait signifié « l’une ou l’autre au choix », c’est-à-dire aucun second facteur. Validez la syntaxe avec sshd -t, rechargez avec systemctl reload ssh, et gardez impérativement votre session courante ouverte pendant que vous testez la connexion depuis un second terminal. Un rechargement ne coupe pas les sessions établies : c’est votre filet de sécurité si la configuration est fausse.

Ce qui casse en production

La panne numéro un n’a rien de sophistiquée : l’horloge. Une VM restaurée depuis un snapshot ou un serveur dont chronyd est arrêté dérive de quelques minutes, et tous les codes sont refusés d’un coup, pour tout le monde, sans message explicite. Avant de suspecter le module PAM, lancez timedatectl et regardez la ligne « System clock synchronized ».

Le contournement le plus courant côté attaquant est le proxy inverse de phishing. La victime saisit son mot de passe puis son code TOTP sur une page qui relaie tout vers le vrai site en temps réel, et l’attaquant récupère non pas le code (déjà expiré) mais le cookie de session émis après authentification. Le 2FA a fonctionné comme prévu, la session est volée quand même. Seul un facteur lié au domaine, donc FIDO2, coupe cette chaîne.

Vient ensuite le harcèlement de notifications : l’attaquant qui possède déjà le mot de passe déclenche des dizaines de demandes push jusqu’à ce que la personne accepte par lassitude ou pour dormir. C’est la méthode utilisée lors de la compromission d’Uber en septembre 2022. La parade est le code à recopier affiché sur l’écran de connexion (number matching), qui rend l’acceptation réflexe impossible.

Restent deux causes de blocage administratif : le détournement de numéro chez l’opérateur, qui vise les comptes protégés par SMS, et les codes de secours que personne n’a rangés. Générez-les au moment de l’enrôlement, imprimez-les ou mettez-les dans un gestionnaire de mots de passe distinct du téléphone qui porte l’application. Un gestionnaire qui stocke à la fois le mot de passe et le TOTP est pratique, mais il ramène vos deux facteurs derrière une seule serrure.

Testez vos connaissances

Quiz rapide Question 1 sur 3

Un mot de passe suivi d'une question secrète, est-ce du 2FA ?

Questions fréquentes

Le 2FA par SMS vaut-il mieux que pas de 2FA du tout ?

Oui, et de loin, contre les attaques automatisées : un attaquant qui rejoue une liste de mots de passe fuités est arrêté net. Non, dès que quelqu’un vous cible précisément, parce qu’un détournement de carte SIM chez l’opérateur redirige le message. Activez le SMS si c’est la seule option proposée par le service, et gardez le TOTP ou la clé physique pour la messagerie, la banque et les accès administrateur.

Pourquoi tous mes codes sont-ils refusés d’un coup ?

Neuf fois sur dix, l’horloge du serveur ou du téléphone a dérivé. TOTP compare des intervalles de 30 secondes calculés de chaque côté, avec une tolérance d’une fenêtre environ. Vérifiez la synchronisation NTP côté serveur (timedatectl, chronyc tracking) et l’heure automatique côté téléphone. Si les deux sont justes, c’est le secret qui a été ré-enrôlé quelque part.

Que se passe-t-il si je perds le téléphone qui porte l’application ?

Sans codes de secours ni sauvegarde du secret, vous dépendez entièrement de la procédure de récupération du service, qui prend de quelques minutes à plusieurs semaines selon les cas. Deux précautions à prendre à l’enrôlement : conserver les codes de secours ailleurs que sur ce téléphone, et enrôler un second appareil en scannant le même QR code, ce qui est parfaitement valide puisque TOTP repose sur un secret partagé et non sur un appareil unique.

Une passkey remplace-t-elle le mot de passe ou s’y ajoute-t-elle ?

Les deux usages existent. Comme second facteur, la clé FIDO2 vient après le mot de passe. Comme passkey en connexion sans mot de passe, elle le remplace, et les deux facteurs deviennent la possession de l’appareil plus le déverrouillage local (PIN ou biométrie). Dans les deux configurations, la signature est liée au domaine, ce qui neutralise les pages de phishing.

Faut-il stocker les codes TOTP dans son gestionnaire de mots de passe ?

C’est un compromis assumé. Le confort est réel et le remplissage automatique évite de recopier un code sur un faux site. En revanche, mot de passe et second facteur se retrouvent derrière une seule serrure : la compromission du coffre livre tout. Pour les accès à fort impact (administration système, registrar de domaines, compte de facturation), séparez les deux.