accès distant MFA : TOTP, push, passkeys, clés matérielles

Vous connaissez le problème : les mots de passe sont hameçonnés, réutilisés ou brute‑forcés, et une session d'accès à distance en est la cible. L'authentification multifacteur (MFA) est la solution évidente — mais tous les seconds facteurs n'empêchent pas les mêmes attaques. Cet article compare TOTP, les notifications push, les passkeys (FIDO2) et les clés matérielles pour vous aider à choisir ce qui réduit réellement le risque pour votre flotte d'accès à distance.

Bref rappel des menaces — ce que l'authentification multifacteur doit empêcher

Avant de comparer les méthodes, explicitez les modèles d'attaquants. Les méthodes MFA bloquent des capacités différentes. Pour l'accès à distance, je m'intéresse aux attaquants capables de :

• Voler ou deviner des mots de passe (credential stuffing, fuites de mots de passe).
• Hameçonner des utilisateurs via une fausse page de connexion et capturer des codes ou jetons de session en temps réel.
• Usurper ou intercepter le trafic réseau (MiTM) ou prendre le contrôle d'une session VPN.
• Contrôler l'appareil de l'utilisateur (malware lisant les authentificateurs, ou une session déjà établie).
• Voler physiquement un appareil (téléphone ou token matériel) ou effectuer des swaps de SIM (pertinent pour le SMS).
• Exploiter la récupération de compte ou les dérogations du help‑desk pour supprimer l'authentification multifacteur (MFA).

Si vous voulez un mapping plus approfondi de ces menaces spécifiquement pour les produits de bureau à distance, voir Le bureau à distance est‑il sûr ? Un modèle de menace honnête et Sécurité du bureau à distance : ce qu'il faut savoir.

TOTP (mots de passe à usage unique basés sur le temps) : ce que c'est et quels types d'attaques il empêche

TOTP (RFC 6238) génère des codes numériques courts — généralement 6 chiffres changeant toutes les 30 secondes — en utilisant un secret partagé stocké sur le serveur et dans l'authenticator (application ou token). Google Authenticator, Authy, FreeOTP et de nombreux tokens matériels utilisent TOTP.

• Bloque : le credential stuffing et la réutilisation de mots de passe. Si un attaquant n'a que le mot de passe, il lui manque le TOTP courant.
• Bloque partiellement : le brute force automatisé — comme les codes sont courts, des limites de taux restent essentielles.
• Ne bloque pas : le hameçonnage en temps réel ou les attaques man‑in‑the‑middle (MiTM). Un attaquant qui contrôle une page de connexion peut demander le TOTP courant à la victime et l'utiliser immédiatement pour terminer la connexion. Le TOTP échoue aussi si l'appareil de l'utilisateur est compromis et que le secret est exfiltré.

Notes opérationnelles : TOTP est simple et largement supporté. Mais l'enrôlement par secret partagé (codes QR) doit être protégé : une fois le secret donné à un utilisateur, quiconque possède ce secret peut générer des codes indéfiniment. Les politiques de sauvegarde et de récupération (ré‑provisionnement quand un téléphone est perdu) sont les points où beaucoup d'organisations affaiblissent la sécurité en s'appuyant trop sur les réinitialisations du help‑desk.

Notifications push : commodité avec risques d'ingénierie sociale

Le push MFA envoie une notification à un appareil enregistré demandant à l'utilisateur d'approuver ou de refuser une tentative de connexion. Les implémentations varient : certaines incluent des détails transactionnels (IP, nom de l'application), d'autres affichent juste une invite « Approuver ». Le serveur émet un challenge et l'appareil le signe ou le confirme, puis le serveur accorde la session.

• Bloque : le vol de crédentiel seul — un attaquant qui n'a que le mot de passe ne peut pas compléter la connexion sans approbation.
• Bloque partiellement : les attaques automatisées et certaines configurations MiTM si le push est lié à un challenge serveur.
• Ne bloque pas de manière fiable : l'ingénierie sociale en temps réel ("approuvez la connexion pour continuer") et les attaques d'épuisement par bombardement de push (« push‑bombing »). Si un attaquant hameçonne un utilisateur et lance simultanément la connexion réelle, beaucoup d'utilisateurs approuvent simplement pour arrêter le bombardement. De plus, le push dépend de l'intégrité de l'appareil ; un téléphone compromis qui approuve automatiquement ou est contrôlé par un malware contourne ce facteur.

Point pratique : le push a un taux de conversion élevé et convient au personnel général, mais ne le considérez pas comme résistant au phishing à moins que l'implémentation n'inclue un lien d'origine/details transactionnels et que l'organisation impose formation utilisateur et vérifications contextuelles (localisation, posture de l'appareil).

Passkeys (FIDO2 / WebAuthn) — résistance au phishing réelle si implémenté correctement

Les passkeys sont le nom convivial pour les credentials FIDO2/WebAuthn. Ce sont des credentials à clé publique créés par site (relying party). La clé privée reste dans l'authenticator (platform ou roaming) ; l'authenticator signe un challenge qui inclut l'identifiant du relying party. Comme la signature est liée à l'origine du relying party, un site de phishing ne peut pas la réutiliser sur le vrai site.

• Bloque : le phishing, les MiTM qui reposent sur la capture de crédentiels, la réutilisation de crédentiels et de nombreuses attaques automatisées. Si l'authenticator est un élément sécurisé (TPM, Secure Enclave, ou un token matériel implémentant FIDO2), le matériel de clé n'est pas extractible.
• Bloque partiellement : les attaques où l'attaquant contrôle l'appareil pendant que l'utilisateur est présent — par ex., si un malware sur l'hôte peut déclencher des approbations ou enrôler de nouveaux credentials via un flux de récupération de compte compromis.
• Ne bloque pas : le vol physique lorsque l'authenticator est non sécurisé et non protégé par PIN/biométrie, ou l'abus de procédures de récupération de compte où le help‑desk peut retirer la clé sans contrôles appropriés.

En pratique, FIDO2/passkeys sont le seul second facteur standard largement disponible offrant une résistance fiable au phishing. Les passkeys intégrées aux plateformes (Windows Hello, Touch ID/Face ID) sont pratiques, et les clés matérielles roaming implémentant FIDO2 (YubiKey avec FIDO2, Nitrokey FIDO) offrent les mêmes garanties avec une séparation physique renforcée.

Clés matérielles : tokens OTP vs tokens FIDO2 — choisissez avec soin

Les tokens matériels existent en deux variantes : tokens à mot de passe à usage unique (HOTP/TOTP) et tokens FIDO2/WebAuthn. Ils ont chacun des avantages et des inconvénients.

• Tokens HOTP/TOTP : petits appareils peu coûteux affichant des codes numériques. Ils héritent des mêmes faiblesses que le TOTP logiciel : modèle à secret partagé, vulnérables au phishing en temps réel si l'attaquant demande le code et l'utilise immédiatement.
• Tokens FIDO2 : utilisent la cryptographie à clé publique et sont résistants au phishing pour les raisons décrites ci‑dessus. Ils requièrent souvent un toucher ou un PIN sur le token, ce qui protège contre l'utilisation non autorisée en cas de vol.

Arbitrages opérationnels : les tokens FIDO2 sont préférables lorsque la résistance au phishing est cruciale. Ils coûtent plus cher, nécessitent un inventaire et des politiques de gestion de clés (émission, déclaration de perte, sauvegardes). Les tokens TOTP sont bon marché et mieux que rien, mais considérez‑les comme une amélioration par rapport aux mots de passe, pas une solution miracle.

Correspondance entre méthodes et scénarios d'attaque courants en accès à distance

Des mappings concrets facilitent le choix. Voici des attaques courantes en accès à distance et quels facteurs les bloquent.

• Attaquant disposant seulement du mot de passe (fuite de crédentiels) : TOTP, push, passkeys et tokens matériels empêchent tous l'accès.
• Site de phishing en temps réel qui relaie la connexion : TOTP et le push sont susceptibles d'être contournés parce que l'attaquant peut relayer le code/le push, sauf si le push inclut de fortes informations transactionnelles et que l'utilisateur les vérifie. FIDO2/passkeys bloquent cela car la signature est liée à l'origine.
• Appareil utilisateur compromis (malware sur le PC utilisé pour initier la session distante) : le MFA n'aide que si l'attaquant ne peut pas utiliser l'appareil d'authentification. Si le malware peut lire les secrets TOTP, intercepter les approbations push ou déclencher un passkey plateforme sans présence utilisateur, le MFA peut être contourné. Les clés matérielles physiques avec toucher/PIN offrent ici une protection supérieure.
• Abus du help‑desk ou de la récupération de compte : tout MFA peut être contourné si vos processus de récupération permettent de retirer des facteurs sans authentification forte. Renforcez les workflows de récupération et journalisez les changements soigneusement.

Recommandations de déploiement pour l'accès à distance

Choisir le « meilleur » facteur dépend de la tolérance au risque, du budget et de la capacité opérationnelle. Pour l'accès à distance (outils de support, consoles d'administration, passerelles RDP) je recommande la baseline suivante :

• Exiger un MFA résistant au phishing (FIDO2/passkeys ou tokens FIDO2) pour les comptes à privilège et les opérateurs de support à distance. Ce sont les rôles à plus haut risque.
• Autoriser le push ou le TOTP pour le personnel général, mais uniquement avec contrôles compensatoires : vérifications de la posture des appareils, contrôles IP/géolocalisation, durées de session courtes et alertes d'activité anormale.
• Renforcer strictement la récupération de compte : ré‑enrôlement en plusieurs étapes nécessitant une preuve (appareil, vérifications d'identité), et journaliser chaque action de récupération.
• Conserver des facteurs de secours : émettre un nombre limité de tokens de récupération et exiger une vérification secondaire avant de remplacer une clé roaming perdue.

Sur le plan opérationnel, gardez en tête que l'auto‑hébergement de l'infrastructure MFA n'en vaut la peine que lorsqu'il le faut — conformité, réseaux isolés ou règles strictes de résidence des données. Les services managés (y compris le managed relay de Tenvo) coûtent généralement moins une fois que l'on prend en compte le patching, le renouvellement des certificats, la garde des clés et le temps d'astreinte. Le managed relay de Tenvo est notre recommandation par défaut : nous proposons des clients natifs pour macOS, Windows et Linux, un client navigateur en bêta publique, et un relay managé multi‑régions. Tarifs : Free $0, Lite $2.99/mo et Pro $7.99/mo — l'option managée vous apporte redondance et zéro maintenance de relay.

Si vous vous auto‑hébergez, acceptez la charge opérationnelle décrite dans Bureau à distance auto‑hébergé : pourquoi, comment, et ce qui casse et verrouillez agressivement les canaux de récupération.

Réalités opérationnelles — sauvegardes, enrôlement, fraude et expérience utilisateur

Un bon design MFA équilibre la sécurité et les opérations en temps réel. Quelques notes pragmatiques :

• Sécurité de l'enrôlement : Protégez l'étape d'association initiale. Si l'enrôlement est non authentifié ou seulement protégé par le même nom d'utilisateur/mot de passe, un attaquant capable de deviner les identifiants peut se provisionner en tant que facteur. Exigez un second canal pour l'enrôlement (confirmation par email vers une adresse corporate, approbation par un administrateur).
• Sauvegardes et récupération : n'envoyez pas de secrets en clair par email. Pour les passkeys, prévoyez des flux de récupération alternatifs (plusieurs clés par compte, clés de récupération en séquestre stockées avec contrôles d'accès stricts). Pour le TOTP, découragez les captures d'écran des codes QR et imposez des réémissions limitées dans le temps.
• Contrôles du help‑desk : rendez la révocation et la réémission traçables et multipartites pour les comptes à haut privilège.
• Journalisation et alertes : journalisez les échecs MFA, les nouveaux enrôlements de facteurs et les événements de récupération. Connectez‑les à votre SIEM et exigez une revue humaine pour les patterns anormaux.
• Expérience utilisateur : les passkeys intégrées réduisent la charge du help‑desk. Le push est le plus simple pour les utilisateurs non techniques, et le TOTP est utile là où les appareils ne peuvent pas recevoir de push.

Si vous voulez une checklist courte et pratique pour configurer l'accès à distance rapidement tout en gardant un MFA raisonnable, voir Comment configurer l'accès à distance en 60 secondes et notre guide Comment donner l'accès à distance à quelqu'un en toute sécurité.

Résumé : choisissez un MFA défendable et résistant au phishing pour les accès sensibles

Version courte :

• TOTP est mieux que rien mais échoue face au phishing en temps réel et contre tout attaquant capable de proxyfier une session.
• Le push ajoute de la commodité mais reste vulnérable à l'ingénierie sociale et à la fatigue d'approbation, sauf si les détails transactionnels et le contexte sont appliqués.
• FIDO2/passkeys (y compris les tokens FIDO2) sont le seul standard largement disponible qui résiste de façon fiable au phishing quand ils sont déployés correctement.
• Les tokens matériels implémentant FIDO2 offrent la meilleure protection pour les comptes à haut risque ; maintenez des processus stricts de récupération et de sauvegarde.
• La charge opérationnelle (enrôlement, help‑desk, sauvegardes) est le coût réel — et un relay/service managé réduit souvent ce coût par rapport à l'auto‑hébergement sauf si vous avez une obligation écrite d'auto‑héberger.

Utilisez un MFA résistant au phishing (passkeys ou tokens FIDO2) pour les administrateurs et les opérateurs de support à distance, conservez le push/TOTP comme recours pragmatiques pour le personnel général, et durcissez la récupération et l'enrôlement pour empêcher la suppression triviale du MFA.

Si vous voulez une voie d'implémentation qui équilibre coût opérationnel et sécurité, le managed relay de Tenvo élimine une grande partie des charges courantes : clients natifs macOS/Windows/Linux, client navigateur en bêta publique, relay managé multi‑régions, et tarifs Free $0 / Lite $2.99/mo / Pro $7.99/mo. Les relays managés simplifient aussi l'application du MFA sur des appareils distribués comparé à un seul relay auto‑hébergé.

Prêt à essayer ? Téléchargez le client et activez des seconds facteurs forts pour vos comptes critiques : Télécharger Tenvo.