Authentification défi-réponse, rejeu, relais et attaque hors ligne

Authentification défi-réponse, rejeu, relais et attaque hors ligne

Le défi-réponse prouve la connaissance d’un secret sans le faire voyager : le vérifieur envoie une valeur fraîche, le client renvoie un calcul qui dépend de cette valeur et du secret. CHAP (Challenge-Handshake Authentication Protocol), NTLM (NT LAN Manager), Kerberos et FIDO2 (Fast IDentity Online 2) reposent tous sur cette idée, avec des garanties qui n’ont presque rien en commun. Cette page est la vue transversale : ce que le mécanisme retire du fil, ce qu’il y laisse, et les trois familles d’attaques qui en découlent.

Explication de la marmotte

Pour prouver qu’on connaît la recette secrète de la famille, pas besoin de la réciter devant tout le monde : il suffit de réussir le plat que l’autre réclame, jamais le même deux fois. Celui qui écoute à la porte repart sans la recette. Reste un tricheur possible : celui qui fait passer le plat d’un autre pour le sien.

→ Lire l’explication complète de la marmotte

Défi-réponse : ce que le mécanisme prouve et ce qu’il ne dit pas

Le schéma ci-dessous montre l’échange générique. À y lire : le secret ne franchit jamais la flèche, seule une valeur dérivée du secret et du défi circule.

La fonction f est soit un calcul à clé partagée (condensé ou code d’authentification de message, détaillé dans Prouver qu’un message vient du bon secret), soit une signature asymétrique. Ce choix décide de presque tout le reste.

Ce que l’échange garantit : à l’instant du défi, quelqu’un, quelque part, a pu calculer f avec le bon secret. Rien de plus. Il ne dit rien de qui transporte la réponse (le client légitime ou un intermédiaire qui recopie), ni de ce qui sert de secret (un mot de passe humain, un condensé stocké, une clé matérielle). Les trois familles d’attaques décrites plus bas tiennent dans ces deux silences.

Trois prérequis conditionnent la moindre garantie :

• Une source d’aléa cryptographique côté vérifieur. Un défi issu d’un compteur, d’une horloge ou d’un générateur mal initialisé au démarrage d’un équipement embarqué se prédit, donc se prépare.
• Un état côté vérifieur. Le défi émis doit être mémorisé, lié à une session et détruit après usage. Un vérifieur sans état derrière un répartiteur de charge accepte volontiers le défi d’un autre nœud, ou le même deux fois.
• Une horloge synchronisée quand elle remplace le défi. Kerberos s’appuie sur le temps : sans synchronisation fiable par NTP (Network Time Protocol), soit l’authentification casse, soit la fenêtre de tolérance est élargie jusqu’à ne plus rien protéger.

Le compromis central est là : un défi-réponse symétrique se déploie partout et ne demande aucun matériel, mais il oblige le vérifieur à détenir de quoi répondre lui-même. La variante asymétrique supprime ce défaut et se paie en enrôlement, en matériel et en procédure de récupération.

Rejeu, relais et attaque hors ligne : trois familles distinctes

Les confondre mène à déployer la mauvaise parade. Un défi parfaitement aléatoire ne fait rien contre un relais ; une signature des échanges ne fait rien contre un mot de passe de huit caractères.

Rejeu : quand la fraîcheur fait défaut

Le rejeu consiste à présenter une réponse capturée plus tôt. Il redevient possible dans quatre cas : défi prévisible, défi réutilisé, défi absent (la fraîcheur vient d’une horloge, donc d’une fenêtre de tolérance), ou défi non lié à la session qui l’a émis.

Variante moins connue : la réflexion. Quand le même secret sert dans les deux sens d’une authentification mutuelle, l’attaquant renvoie à sa victime le défi qu’elle vient de lui poser, dans une session parallèle, et récupère la réponse toute faite. La parade tient en une ligne : des secrets distincts par sens, ou l’identité et le rôle de chaque partie inclus dans le calcul.

Pour les mécanismes à horodatage, la parade est un cache de rejeu : le service mémorise les preuves déjà vues pendant la fenêtre de tolérance. Ce cache est local par construction. Un service réparti sur plusieurs instances sans cache partagé accepte la même preuve une fois par instance.

Relais : la réponse est authentique, le porteur ne l’est pas

Le relais ne casse rien. L’attaquant se place entre la victime et le service, transmet le défi dans un sens et la réponse dans l’autre, en temps réel. Le défi est frais, la réponse est exacte, le calcul a bien été fait avec le bon secret. Seul problème : la session ouverte appartient à l’attaquant.

Aucune qualité d’aléa ne corrige cela, puisque la faille n’est pas dans le défi mais dans l’absence de lien entre la réponse et le canal qui la porte. Trois parades existent, et elles seules :

• Liaison au canal : la réponse intègre une empreinte du canal TLS (Transport Layer Security) vu par le client, typiquement le certificat du serveur. Relayée sur un autre canal, elle ne correspond plus.
• Liaison à l’origine ou à la cible : la réponse intègre le nom du service visé. C’est le principe de WebAuthn (Web Authentication), où le navigateur inscrit lui-même l’origine dans les données signées.
• Signature des échanges : une clé de session dérivée du secret protège la suite du dialogue. Le relayeur obtient une session authentifiée dont il ne peut signer aucun message, ce qui gâche sensiblement l’intérêt.

Piège de production : la liaison au canal suppose que le client et le service voient le même canal TLS. Un proxy inverse ou un équipement d’inspection qui termine TLS devant le service casse cette hypothèse, et la tentation classique est de désactiver la protection « le temps de comprendre ». Le provisoire, dans ce métier, a une espérance de vie remarquable.

Attaque hors ligne et équivalent de mot de passe

Une paire défi/réponse capturée est un oracle de vérification : chaque mot de passe candidat se teste localement, sans toucher au service, sans verrouillage de compte, sans journal. La résistance dépend alors de deux choses, l’entropie du secret et le coût d’un essai. Un secret choisi par un humain passé dans un condensé rapide ne tient pas.

Deuxième problème, plus structurel : dans un schéma symétrique, le vérifieur doit pouvoir recalculer la réponse. Ce qu’il stocke suffit donc à répondre. Quand cette valeur est un condensé du mot de passe, le condensé est le mot de passe du point de vue du protocole : c’est le principe du pass-the-hash avec le condensé NT, et du pass-the-key avec les clés Kerberos. Voler la base du vérifieur revient à voler les identités, sans rien casser du tout.

CHAP, MS-CHAPv2, NTLM, Kerberos et FIDO2 : comparaison des garanties

Protocole	Ce qui sert de secret	Source de fraîcheur	Ce que le vérifieur stocke	Rejeu	Relais	Attaque hors ligne
CHAP	Secret partagé	Défi aléatoire du vérifieur	Le secret lui-même, sous forme réversible	Résiste si le défi est unique et imprévisible	Possible, aucune liaison	Un condensé MD5 par essai : dictionnaire immédiat
MS-CHAPv2	Condensé NT du mot de passe	Défis du serveur et du client	Condensé NT	Résiste	Possible hors tunnel validé	Ramenée à une recherche exhaustive DES de 2^56 qui livre le condensé NT
NTLMv1	Condensé NT	Défi serveur de 8 octets	Condensé NT	Résiste si défi aléatoire	Possible	Même faiblesse DES que MS-CHAPv2
NTLMv2	Condensé NT	Défi serveur, défi client, horodatage	Condensé NT	Résiste	Possible sans signature ni liaison au canal	HMAC-MD5 rapide : les mots de passe faibles tombent
Kerberos	Clé dérivée du mot de passe	Horodatage chiffré, pas de défi	Clés à long terme des comptes	Fenêtre d’horloge, couverte par le cache de rejeu	Limité au service visé par le ticket, possible sans signature ni liaison	Possible sur la pré-authentification et les tickets de service
FIDO2 / WebAuthn	Clé privée générée par l’authentificateur	Défi aléatoire du service	Clé publique, identifiant, compteur	Résiste (défi à usage unique)	Résiste : origine incluse dans la signature	Sans objet : rien à deviner

Quelques précisions que le tableau ne peut pas porter.

CHAP, décrit par la RFC (Request for Comments) 1994 pour PPP (Point-to-Point Protocol), calcule un condensé MD5 (Message Digest 5) de l’identifiant d’échange, du secret et du défi. Conséquence directe : le serveur doit conserver le secret sous une forme réversible. Le protocole permet de reposer un défi en cours de session, bonne idée restée sans descendance.

MS-CHAPv2 (Microsoft CHAP version 2, RFC 2759) ajoute l’authentification mutuelle et remplace le secret par le condensé NT. La réponse découpe ce condensé en trois clés DES (Data Encryption Standard), dont la troisième ne contient que deux octets effectifs. Casser l’échange revient à une unique recherche exhaustive DES, et le butin est le condensé NT, donc de quoi s’authentifier partout ailleurs. Le protocole ne survit que dans un tunnel TLS dont le client valide réellement le certificat serveur (voir PKI et TLS) ; un poste configuré pour accepter n’importe quel certificat livre l’échange au premier faux point d’accès venu.

NTLMv2 calcule un HMAC (Hash-based Message Authentication Code) fondé sur MD5, à partir du condensé NT, du défi serveur et d’un bloc contenant horodatage, défi client et informations sur la cible. C’est ce bloc qui peut porter la liaison au canal. Le détail des versions et du durcissement est dans la page NTLM : fonctionnement, vulnérabilités et durcissement.

Kerberos (RFC 4120) n’a pas de défi dans son premier échange : le client chiffre un horodatage avec sa clé (pré-authentification), et le centre de distribution de clés, ou KDC (Key Distribution Center), vérifie qu’il tombe dans la tolérance, cinq minutes par défaut. Face aux services, l’authentifiant (horodatage chiffré avec la clé de session) joue le même rôle, doublé d’un cache de rejeu. Le ticket est chiffré pour un service précis, ce qui borne le relais sans l’interdire. La surface hors ligne est large : pré-authentification capturée, comptes dispensés de pré-authentification, tickets de service chiffrés avec la clé d’un compte de service. Avec le chiffrement RC4 (Rivest Cipher 4), la clé est le condensé NT sans sel ; avec AES (Advanced Encryption Standard), elle sort d’une dérivation salée à 4096 itérations, mieux mais pas dissuasif pour un mot de passe humain. Détails dans Kerberos et KDC dans Active Directory, attaques et durcissement.

FIDO2/WebAuthn change de catégorie. L’authentificateur signe le défi avec une clé privée propre à chaque service, et les données signées incluent l’origine constatée par le navigateur ainsi que l’identifiant du service. Le vérifieur ne stocke qu’une clé publique : sa base volée ne permet de répondre à rien.

Exemple : relais d’un défi NTLM, puis la même tentative contre WebAuthn

Premier schéma : un relais contre un service qui accepte NTLM. À regarder : l’attaquant ne calcule rien, il recopie. La dernière branche montre l’effet des parades.

Le défi est aléatoire, la réponse est correcte, NTLMv2 fait son travail. Le service n’a aucun moyen de savoir que la réponse a été calculée pour un autre interlocuteur, sauf si la suite des échanges doit être signée ou si la réponse embarque l’empreinte du canal. Le relais marche aussi bien vers un autre protocole que celui de départ : une authentification captée sur un partage de fichiers SMB (Server Message Block) se relaie vers un annuaire LDAP (Lightweight Directory Access Protocol) si celui-ci n’exige rien.

Second schéma : le même montage face à WebAuthn, avec un site d’hameçonnage en position de relais.

La différence ne tient pas à la vigilance de l’utilisateur, et c’est tout l’intérêt. L’origine est inscrite par le navigateur, pas par la page ni par la personne, et la clé n’existe que pour le service qui l’a enrôlée. Le relais échoue deux fois : faute de clé à utiliser, puis faute d’origine acceptable.

Choix et durcissement d’un mécanisme de défi-réponse

La position défendue ici : pour toute authentification de personnes nouvellement conçue, défi-réponse asymétrique lié à l’origine, donc WebAuthn. C’est la seule ligne du tableau qui traite les trois familles à la fois, et elle retire au vérifieur la capacité de répondre à la place de l’utilisateur. Le déploiement a ses propres embûches, traitées dans Déployer le passwordless.

Pour l’existant, la question n’est pas « quel protocole est le meilleur » mais « quelle famille d’attaque reste ouverte » :

• Relais ouvert : exiger la signature sur SMB et LDAP, activer la liaison au canal, appelée EPA (Extended Protection for Authentication) dans l’écosystème Windows, sur les services HTTP (HyperText Transfer Protocol) et LDAP sur TLS. Tant que ces deux réglages ne sont pas imposés côté serveur, la version du protocole ne change rien.
• Hors ligne ouvert : supprimer NTLMv1 et MS-CHAPv2 hors tunnel validé, retirer RC4 de Kerberos, donner aux comptes de service des secrets générés par machine (au moins 25 caractères aléatoires, ou des comptes de service gérés dont l’annuaire renouvelle lui-même le mot de passe), ne dispenser aucun compte de pré-authentification. Le blindage de la pré-authentification, ou FAST (Flexible Authentication Secure Tunneling), retire l’horodatage chiffré de la vue d’un observateur.
• Équivalent de mot de passe stocké : il ne se corrige pas, il se confine. Cloisonnement des comptes à privilèges, interdiction de leur ouverture de session sur les postes ordinaires, et sortie progressive des protocoles symétriques.

Ce que même WebAuthn ne garantit pas : la session qui suit. Un jeton de session volé après une authentification irréprochable se rejoue sans défi ni signature ; cette protection doit venir de la gestion des sessions et des jetons, pas de l’authentification. Idem pour l’enrôlement et la récupération de compte, qui retombent souvent sur un courriel et un code, soit le niveau de sécurité que tout l’édifice prétendait dépasser (voir Authentifier les personnes et les services).

Dernier piège WebAuthn : l’identifiant du service est un nom de domaine. Changer de domaine d’authentification rend inutilisables les clés enrôlées sous l’ancien. Ce choix se fait une fois, avant le premier enrôlement.

Exploitation : secrets, rotation, supervision et reprise

Secrets et rotation. Dans les schémas symétriques, tout ce qui stocke un équivalent de mot de passe (base du KDC, annuaire, serveur d’accès réseau) est une cible de premier rang, à sauvegarder chiffrée et à restaurer avec la même prudence. Changer un mot de passe ne révoque pas les tickets Kerberos déjà émis : ils vivent jusqu’à expiration. La clé du compte qui signe les tickets initiaux (krbtgt dans Active Directory) se renouvelle deux fois de suite, l’ancienne valeur restant acceptée après un premier changement.

Supervision. Trois signaux valent le coût de collecte : les authentifications en NTLMv1 ou en RC4 (elles ne devraient plus exister, donc chaque occurrence est une anomalie ou un oubli), les échecs de liaison au canal (relais en cours, ou proxy TLS mal placé, les deux méritent une visite), et côté WebAuthn un compteur de signatures qui recule, signe possible d’un authentificateur cloné. Ce compteur reste à zéro sur les clés synchronisées entre appareils : l’absence de signal n’y prouve rien.

Reprise. Auditer l’usage de NTLM avant de le bloquer, sous peine de découvrir les applications oubliées par leurs pannes. Pour WebAuthn, imposer deux authentificateurs par personne dès l’enrôlement : la perte de l’unique clé renvoie vers la procédure de récupération, qui devient le maillon le plus faible. Avec des clés synchronisées, la reprise dépend du compte chez le fournisseur de synchronisation, dont la sécurité entre de fait dans le périmètre.

FAQ

Un défi aléatoire protège-t-il du relais ?

Non. Le défi garantit la fraîcheur, pas l’identité du porteur. Dans un relais, le défi est frais et la réponse légitime ; seul un lien entre la réponse et le canal, l’origine ou la suite signée des échanges fait échouer l’attaque.

NTLMv2 suffit-il si NTLMv1 est désactivé ?

Cela ferme la faiblesse DES, pas le reste. NTLMv2 se relaie tant que signature et liaison au canal ne sont pas exigées par les serveurs, se casse hors ligne quand le mot de passe est faible, et le condensé NT continue de suffire pour répondre.

Kerberos est-il un protocole de défi-réponse ?

Dans l’esprit, oui ; dans la forme, la fraîcheur vient d’un horodatage chiffré plutôt que d’un défi du vérifieur. D’où la dépendance à l’horloge, la fenêtre de tolérance et le cache de rejeu, absents des protocoles à défi explicite.

🐝 Ce qui arrive si on s’en passe

Sans défi-réponse, le secret lui-même traverse chaque maillon : le service qui le reçoit, le proxy qui termine le chiffrement devant lui, le journal applicatif qui trace une requête mal filtrée, la mémoire du processus qui le compare. Chacun de ces points devient capable de se faire passer pour l’utilisateur, partout où le même secret a cours, et sans limite de durée tant qu’il n’est pas changé. Un faux service n’a plus besoin de relayer quoi que ce soit en temps réel : il encaisse le secret et s’en sert plus tard, à tête reposée. La détection y perd aussi : une authentification refaite avec le vrai secret ne se distingue en rien d’une authentification légitime, et aucun défi consommé ne permet de dater la fuite.

🦫 Explication de la marmotte 🍫

Un service veut vérifier qu’une personne connaît bien un secret, sans que ce secret voyage sur le réseau. Il lui envoie donc une valeur tirée au hasard, différente à chaque tentative. L’ordinateur de la personne mélange cette valeur avec le secret par un calcul impossible à inverser, puis renvoie le résultat. Le service refait le calcul de son côté et compare. Quelqu’un qui écoute ne récupère pas le secret, et le résultat ne servira plus, puisque la prochaine valeur sera différente.

Trois choses peuvent mal tourner. Si la valeur au hasard revient deux fois, ou peut se deviner, un ancien résultat enregistré redevient valable. Si un attaquant se place au milieu, il peut transmettre la valeur à la victime, récupérer son résultat et le présenter au service à sa place, sans jamais connaître le secret. Enfin, avec la valeur et le résultat sous la main, il peut essayer chez lui des millions de mots de passe jusqu’à trouver celui qui redonne le même résultat.

Les méthodes récentes corrigent cela : le secret est une très longue clé fabriquée par une machine, qui ne quitte jamais l’appareil, et le résultat contient l’adresse du site visité. Présenté ailleurs, il est refusé. Le service, lui, ne garde qu’une information qui permet de vérifier, pas de répondre.

À lire aussi

• Gouverner les facteurs d’authentification en entreprisePolitique de choix des facteurs, déploiement progressif du passwordless, vérification d’identité et récupération de compte dans un parc hétérogène.
• L'administration Active Directory en tiers en une pageTiers 0, 1 et 2 : pourquoi un admin du domaine connecté sur un poste de travail expose tout le domaine, et les cloisons qui l'en empêchent : un compte par tier, poste d'administration dédié, LAPS, Protected Users.
• Déployer FIDO2 pour comptes à privilègesGuide pratique de priorisation et de déploiement progressif de l’authentification multifacteur résistante au phishing pour les comptes à privilèges.
• Le Kerberoasting en une pagePourquoi un compte de service Active Directory doté d'un SPN et d'un mot de passe faible est un risque, et les cinq parades qui rendent son ticket inutile : gMSA, mot de passe long, AES sans RC4, moindre privilège, événement 4769.

Pages voisines

La citent

• Prouver sans révéler : ZK et identification
• Sécuriser badges RFID, NFC et serrures connectées en entreprise
• Sécuriser l'accès des flottes de véhicules connectés

Authentification défi-réponse, rejeu, relais et attaque hors ligne

Elle cite

• ⇄Lien dans les deux sens :Kerberos et KDC dans Active Directory, attaques et durcissement
• ⇄Lien dans les deux sens :NTLM : protocole authentification LAN Manager New Technology Microsoft
• ⇄Lien dans les deux sens :Attaque par relais NTLM et signature SMB obligatoire
• Authentifier les personnes et les services
• Déployer le passwordless dans un parc hétérogène
• Hashcat pour casser hors ligne des empreintes de mots de passe
• L'entropie au démarrage
• Prouver qu’un message vient du bon secret

⇄ : les deux pages se citent l’une l’autre.