Un code d’authentification désigne toute valeur générée ou convenue qui sert à prouver une identité lors d’un accès. Le terme recouvre aussi bien un code OTP à usage unique affiché par une application TOTP qu’un code d’authentification de message (MAC) utilisé en cryptographie pour vérifier l’intégrité de données. Dans la pratique quotidienne, c’est surtout le code à six chiffres, renouvelé toutes les trente secondes par Google Authenticator ou un équivalent, qui vient à l’esprit.
TOTP, HOTP, MAC : distinguer les mécanismes derrière le code d’authentification
Un code OTP basé sur le temps (TOTP) repose sur un secret partagé entre le service et l’application, combiné à l’horodatage courant. Le serveur et l’application génèrent le même code au même instant, ce qui supprime tout besoin de transmission réseau du code lui-même.
Lire également : Quel est le protocole Wi-Fi le plus sécurisé ?
Le HOTP (mot de passe à usage unique fondé sur HMAC) fonctionne sur un compteur incrémental plutôt que sur l’heure. Sa fenêtre de validité reste ouverte tant que le compteur n’avance pas, ce qui le rend plus vulnérable au rejeu si un code intercepté n’est pas consommé rapidement.
Le MAC, lui, ne sert pas à authentifier un utilisateur mais un message. Il accompagne des données pour garantir qu’elles n’ont subi aucune modification en transit. Confondre les deux est fréquent, mais un MAC protège l’intégrité d’un flux de données, pas l’accès à un compte.
A découvrir également : Comment savoir si une image a été manipulée ?
Code d’authentification par SMS : une méthode que le NIST classe comme restreinte
Le NIST SP 800-63B-4 traite l’authentification par SMS comme une méthode « restreinte ». Nous observons que cette classification surprend encore beaucoup d’équipes techniques. Le texte demande aux services qui utilisent l’authentification via le réseau téléphonique de proposer une alternative et de tenir compte de signaux de risque tels qu’un changement de carte SIM ou une portabilité récente du numéro.
Le problème principal est le SIM swap. Un attaquant qui convainc un opérateur de transférer un numéro vers une nouvelle carte SIM reçoit les codes OTP à la place du titulaire légitime. Le code d’authentification arrive alors sur le bon numéro, mais sur le mauvais appareil.
Pourquoi le SMS reste massivement utilisé malgré ses failles
Le SMS ne nécessite ni smartphone récent, ni application tierce, ni connexion Internet. Pour un service qui cible un public large, cette compatibilité universelle l’emporte souvent sur le risque théorique. Nous recommandons néanmoins de proposer systématiquement une application d’authentification comme option parallèle, même quand le SMS est conservé.
La récupération de compte contourne-t-elle le code d’authentification ?
C’est le point que la majorité des articles sur le sujet ignorent. La procédure de récupération de compte constitue elle-même une authentification. Si un service protège la connexion par TOTP mais permet de réinitialiser l’accès via un simple lien envoyé par e-mail ou un code SMS, la sécurité réelle du compte se limite à celle du canal de récupération.
Prenons un cas concret. Un utilisateur active la double authentification avec Google Authenticator. Il perd son téléphone. Le service lui envoie un code de récupération par SMS. Un attaquant ayant compromis le numéro (SIM swap, interception SS7) récupère ce code et accède au compte. Le code TOTP n’a servi à rien.
Ce qui détermine le vrai plafond de sécurité d’un compte
Le plafond de sécurité d’un compte n’est pas fixé par la méthode d’authentification principale, mais par le maillon le plus faible du parcours complet, récupération incluse. Un service qui exige une clé FIDO pour se connecter mais autorise un reset par e-mail sans vérification supplémentaire offre une façade robuste sur une fondation fragile.
- Vérifier si le flux de récupération exige le même niveau d’authentification que la connexion normale (ou un niveau supérieur)
- S’assurer que la récupération par SMS peut être désactivée au profit de codes de secours générés hors ligne
- Stocker les codes de secours dans un gestionnaire de mots de passe chiffré, pas dans un fichier texte ou une capture d’écran
Passkeys et FIDO : le code d’authentification devient invisible
Les passkeys (identifiants FIDO/WebAuthn) suppriment le code saisi par l’utilisateur. L’authentification repose sur une paire de clés cryptographiques liée au domaine réel du service, ce qui empêche la réutilisation sur un site de phishing. Les codes OTP ne sont pas résistants au hameçonnage, contrairement aux passkeys qui lient la preuve d’identité au domaine visité.
Le NIST autorise les passkeys comme option résistante au phishing au niveau AAL2. Les passkeys synchronisées, stockées dans un coffre cloud (iCloud Keychain, Google Password Manager), ne sont pas admises au niveau AAL3, qui exige une clé privée non exportable. Cette distinction est technique mais structurante pour les architectures à haute assurance.
Un code PIN et un OTP ne font pas deux facteurs
Un code PIN et un mot de passe relèvent tous deux de la catégorie « ce que l’on sait ». Leur combinaison ne constitue pas une authentification multifacteur au sens strict. Pour atteindre le MFA, il faut croiser au moins deux catégories distinctes : connaissance (mot de passe), possession (téléphone, clé physique) ou inhérence (biométrie).
- Connaissance : mot de passe, code PIN, réponse secrète
- Possession : application TOTP sur un appareil, clé de sécurité USB, carte à puce
- Inhérence : empreinte digitale, reconnaissance faciale, reconnaissance vocale
Choisir le bon type de code d’authentification selon le contexte
Pour un usage personnel courant, une application TOTP (Google Authenticator, Microsoft Authenticator ou équivalent) offre un gain de sécurité substantiel par rapport au mot de passe seul. Le code généré ne transite pas par le réseau mobile, ce qui élimine le risque de SIM swap sur ce canal.
Pour des environnements à exigence élevée (infrastructure critique, données de santé, systèmes financiers), une clé de sécurité physique FIDO2 reste la référence. La clé privée ne quitte jamais le matériel, ce qui satisfait les exigences AAL3 du NIST.
Le vrai critère de choix n’est pas la robustesse théorique du code d’authentification principal, mais la cohérence de l’ensemble du parcours : connexion, récupération, changement d’appareil. Un compte dont chaque étape exige le même niveau de preuve est un compte réellement protégé. Un compte dont la porte principale est blindée mais dont la fenêtre de récupération reste ouverte ne l’est pas.
