Résumé

  • Dans les attaques décrites par la RFC 10027, l’utilisateur peut réussir une véritable authentification multifacteur tout en accordant l’accès à l’appareil de l’attaquant. Le lien manquant unit l’appareil initiateur à la décision.
  • Un QR code ou un code utilisateur valide identifie une transaction en attente. Il ne prouve ni qui l’a présenté, ni pourquoi elle a été lancée, ni où les jetons seront utilisés.
  • Daniel Fett a cosigné la RFC avec Pieter Kasselman et Filip Skokan. Leur recommandation combine choix du protocole, proximité, limitation des droits, détection et rétablissement, sans transformer un contrôle isolé en garantie absolue.

Un fraudeur n’a pas toujours besoin d’imiter la page de connexion. Il peut au contraire souhaiter que la victime arrive sur la vraie page. La marque est correcte, le certificat aussi, et le gestionnaire de mots de passe ne signale rien. Cette authenticité rassure précisément au moment où la mauvaise question est posée.

La RFC 10027, publiée comme Best Current Practice de l’IETF en août 2026, nomme le défaut : le canal entre l’appareil qui consommera le service et celui sur lequel l’utilisateur autorise la demande n’est souvent pas authentifié. Une télévision, une borne ou un poste de travail affiche un QR code. Le téléphone se charge de l’authentification. Entre les deux, l’être humain est invité à certifier le contexte par son seul jugement.

L’attaquant peut alors ouvrir la transaction sur son propre appareil, obtenir le code officiel et l’envoyer à la victime avec un récit crédible — assistance technique, activation urgente, partage d’un document. La victime scanne, s’authentifie et accepte. Le serveur sait qui elle est. Il ne sait pas nécessairement devant quel écran elle se trouve.

Une autorisation réelle, détournée de son intention

Ce mécanisme explique pourquoi parler d’« échec de la MFA » serait imprécis. La MFA a pu accomplir sa tâche : authentifier une personne. Ce qui manque est l’association entre la personne, l’appareil initiateur, le motif annoncé et la capacité finalement remise.

La RFC distingue le Cross-Device Consent Phishing, où la victime accorde une autorisation, du Cross-Device Session Phishing, où elle transmet un artefact permettant de déplacer une session déjà ouverte. Dans les deux cas, le butin peut être un jeton d’accès, un jeton d’actualisation ou une session exploitable, pas le mot de passe. Réinitialiser seulement le secret de connexion peut donc laisser la conséquence principale intacte.

Le QR code possède une valeur probante limitée. Il peut être bien formé, unique, non expiré et signé par le bon serveur. Ces propriétés ne disent pas qui l’a placé dans l’e-mail, si l’utilisateur attendait la demande, si les appareils sont proches, si la portée est raisonnable ou si le bénéficiaire correspond à l’écran visible. Une donnée authentique peut circuler dans une histoire mensongère.

Pourquoi Daniel Fett compte dans ce dossier

Le site professionnel de Daniel Fett le présente comme consultant en sécurité spécialisé dans l’identité et les protocoles web, actif sur OAuth et OpenID Connect à l’OpenID Foundation et à l’IETF. Son dossier IETF réunit plusieurs RFC consacrées à l’identification de l’émetteur, à la preuve de possession et à la sécurité d’OAuth. Il est l’un des trois auteurs de la RFC 10027, pas son propriétaire intellectuel unique, et il ne contrôle aucun déploiement cité par le texte.

Son apport éclaire surtout une méthode : ne pas faire d’une étape cryptographique réussie la preuve d’une relation que le protocole n’a pas modélisée. L’analyse formelle peut exclure certaines attaques dans un modèle défini; elle ne prouve pas que toutes les implémentations, interfaces et hypothèses humaines respectent ce modèle.

Pour une équipe de sécurité, chaque phrase doit donc conserver son complément. Qui a été authentifié ? Auprès de qui ? Pour quelle transaction ? Quel client a reçu le jeton ? Un utilisateur authentifié n’est pas un appareil initiateur authentifié. Une demande provenant du vrai serveur n’est pas une intention humaine vérifiée. Un jeton lié à une clé n’est pas forcément lié au bon poste : l’attaquant peut exercer la clé de l’appareil qu’il contrôle.

Une défense composée de limites explicites

La RFC 10027 dresse une liste de protections, puis décrit leurs limites. Les codes courts et à usage unique raccourcissent la fenêtre de réutilisation; un fraudeur interactif peut attendre que la victime réponde avant de générer le code. Les limites de débit freinent les campagnes, moins les attaques ciblées. La sensibilisation réduit le risque, mais une demande malveillante soignée peut ressembler à une demande normale.

La proximité apporte une preuve plus concrète. Bluetooth Low Energy, NFC, ultra-wideband, réseau partagé ou géolocalisation peuvent rendre difficile l’échange à distance. Pourtant, VPN, usurpation de position, NAT, réseau mobile et approbation légitime à distance empêchent d’en faire une équivalence avec l’intention. La proximité indique une situation; elle ne décide pas à la place de l’utilisateur.

Limiter les initiateurs à des appareils ou réseaux de confiance ferme une partie de la surface. Encore faut-il enrôler, attester, mettre à jour et révoquer ces appareils. Réduire les portées et la durée des jetons limite les dégâts après une mauvaise décision sans corriger cette décision. Les jetons contraints à l’émetteur empêchent surtout leur déplacement; ils n’empêchent pas l’appareil hostile bénéficiaire d’utiliser sa propre clé.

Le choix du protocole devient alors une décision de risque. La RFC recommande FIDO pour l’authentification interappareils lorsque les capacités permettent de lier origine et proximité. CIBA peut être préférable lorsque le serveur dispose déjà d’un canal vers l’utilisateur, tout en exigeant une défense contre les demandes non sollicitées. Le Device Authorization Grant d’OAuth reste le plus compatible avec les appareils pauvres en entrées, mais cette universalité est précisément sa faiblesse. Il devrait être évité pour les ressources sensibles ou critiques si les protections supplémentaires ne compensent pas le canal non authentifié.

Du bouton « Autoriser » à la preuve d’exploitation

La primauté du code en fonctionnement défendue par Heng Lu fournit ici une règle d’audit : une déclaration n’est pas le résultat opérationnel. L’événement « autorisé » ne dit pas encore quel appareil a reçu quelle capacité, sur quelle ressource, puis l’a utilisée.

Un reçu utile relie l’identité du client initiateur, son état, l’appareil d’autorisation, la méthode, le contexte affiché des deux côtés, la portée exacte, les indices de proximité, la décision, le destinataire du jeton, sa première utilisation, la révocation et le rétablissement. Ces données doivent être minimisées et protégées. Leur absence ne peut pas être compensée par une coche verte.

La responsabilité suit les leviers. Le produit décide si le gain d’activation justifie un flux interappareils. L’équipe d’identité choisit le protocole et les droits. Les équipes terminal et réseau établissent la confiance et la proximité. La fraude observe les initiations anormales. Le serveur de ressources applique les contraintes. Le support révoque les sessions et vérifie le retour à un état sain. L’utilisateur ne doit pas devenir l’unique authentificateur d’un canal que l’architecture a choisi de laisser sans preuve.

La leçon de Daniel Fett et de ses coauteurs n’est donc pas de bannir les QR codes. Elle est plus exigeante : ne jamais confondre une passation visible avec une relation authentifiée.

Sources