« Se connecter »
Essai gratuit

Comment prévenir les abus de réinitialisation de mot de passe sur votre site web (2026)

Illustration de la prévention des abus de réinitialisation de mot de passe, montrant les menaces telles que les attaques automatisées, l'énumération d'utilisateurs, l'inondation de courriels et le bourrage d'informations d'identification, ainsi que les protections telles que la limitation du taux, la vérification CAPTCHA, la protection de l'existence du compte et les alertes de surveillance.
captcha.eu

La plupart des équipes protègent soigneusement leur page de connexion et laissent le flux de réinitialisation du mot de passe presque ouvert. Les attaquants le savent. Ils utilisent le flux de réinitialisation pour énumérer les comptes valides, inonder les boîtes de réception d'e-mails automatisés, voler des jetons par la génération de liens faibles et contourner les protections de connexion que vous avez passé du temps à renforcer. Ce guide explique tous les schémas d'abus de réinitialisation et les étapes pratiques qui permettent d'arrêter chacun d'entre eux.

Temps de lecture estimé : 13 minutes

Essayez CAPTCHA.eu gratuitement - sans carte de crédit
Voir toutes les intégrations

En bref

Pourquoi les flux de réinitialisation font-ils l'objet d'abus ?

Le flux de réinitialisation contourne entièrement votre page de connexion. S'il est plus faible que votre page de connexion, les attaquants l'utilisent pour accéder plus facilement à votre compte.

Quatre schémas de maltraitance à connaître

L'énumération de comptes, l'inondation de réinitialisations, le vol de jetons et la conception d'une récupération faible. Chacun de ces problèmes nécessite une défense différente, et aucun d'entre eux n'est résolu par la seule protection de l'ouverture de session

La correction unique la plus rapide

Renvoyer la même réponse, qu'un compte existe ou non. Cette simple modification élimine l'énumération des comptes pour un coût d'ingénierie nul

Ce que couvre ce guide

Pourquoi les flux de réinitialisation de mots de passe sont-ils ciblés ?

Le flux de réinitialisation du mot de passe est la porte dérobée de votre système d'authentification. Son rôle est de permettre aux utilisateurs de revenir sans leur mot de passe, ce qui signifie qu'il doit contourner la vérification normale des informations d'identification. Cela le rend structurellement plus faible que le login, et les attaquants exploitent directement cette faille.

Trois éléments font des flux de réinitialisation des cibles attrayantes. Tout d'abord, la plupart des équipes ajoutent une forte protection contre les robots à la connexion, mais négligent complètement le point de terminaison de réinitialisation. Deuxièmement, les flux de réinitialisation révèlent des informations utiles aux attaquants : si un compte existe, quelles adresses électroniques sont enregistrées et à quelle vitesse les jetons de réinitialisation expirent. Troisièmement, les formulaires de réinitialisation sont publics et faciles à automatiser : un robot peut déclencher des milliers de demandes de réinitialisation par heure sur un formulaire sans limitation de taux ou CAPTCHA.

Il en résulte que même les équipes qui ont renforcé la connexion, ajouté le MFA et mis en œuvre la limitation du taux laissent souvent la réinitialisation du mot de passe comme une entrée latérale non protégée. L'OWASP's Forgot Password Cheat Sheet répertorie les vulnérabilités du flux de réinitialisation parmi les faiblesses d'authentification les plus couramment exploitées dans les applications de production. Le point le plus faible de votre système d'authentification est le seul qui compte pour un attaquant déterminé, et si ce point est votre formulaire de réinitialisation, toute la protection de votre page de connexion ne compte pour rien.

Les quatre types d'abus de réinitialisation de mot de passe

L'abus de réinitialisation de mot de passe n'est pas un type d'attaque unique. Il s'agit d'une catégorie de quatre modèles distincts, chacun ayant des objectifs différents et nécessitant des défenses différentes.

SCHÉMA D'ABUS
CE QUE FONT LES ATTAQUANTS
CE QU'ILS GAGNENT
Énumération des comptes
Soumettre des demandes de réinitialisation pour de nombreuses adresses électroniques et observer si les réponses diffèrent selon qu'il s'agit de comptes existants ou non.
Une liste validée d'adresses électroniques de comptes réels à utiliser dans le cadre d'attaques de phishing, de credential stuffing ou d'attaques ciblées.
Réinitialisation de l'inondation
Déclencher automatiquement un grand nombre d'e-mails de réinitialisation vers un ou plusieurs comptes
Surcharge de la boîte de réception qui cache des courriels d'hameçonnage, harcèlement des utilisateurs ou dégradation de la réputation de l'infrastructure de messagerie.
Vol de jetons et force brute
Interception des liens réinitialisés par le biais des en-têtes de référence, des URL archivées ou de l'historique du navigateur, ou par la force brute de jetons courts/prévisibles.
Jeton de réinitialisation valide qui leur permet de définir un nouveau mot de passe et de reprendre le compte sans connaître le mot de passe original.
Faiblesse de la conception de la récupération
Exploiter des méthodes de récupération non sécurisées : jetons réutilisables, liens n'expirant pas, questions de sécurité dont les réponses peuvent être devinées, ou échange de cartes SIM pour intercepter les codes SMS.
Accès au compte par le biais du chemin de récupération sans qu'il soit nécessaire d'interrompre le flux de connexion

Ces quatre schémas apparaissent souvent ensemble dans une même campagne d'attaque. Un attaquant peut commencer par l'énumération pour identifier les comptes réels, puis utiliser l'inondation de réinitialisation pour créer la confusion tout en exécutant un vol de jetons ou un échange de cartes SIM contre une cible spécifique de grande valeur. Pour se défendre contre ces quatre types d'attaques, il est nécessaire de mettre en place des contrôles en couches, et non une solution unique.

Sept défenses efficaces

  • Renvoyer des réponses cohérentes pour les comptes existants et non existants

    C'est le changement le plus important que vous puissiez faire, et il ne coûte presque rien à mettre en œuvre. Lorsqu'un utilisateur soumet une demande de réinitialisation pour une adresse électronique, renvoyez exactement le même message, le même code d'état HTTP et le même temps de réponse, que le compte existe ou non. Un message tel que “Si un compte avec cette adresse existe, vous recevrez un courriel de réinitialisation” ferme complètement l'énumération des comptes. L'erreur la plus fréquente consiste à renvoyer “Nous vous avons envoyé un courriel de réinitialisation” pour les comptes réels et “Aucun compte trouvé” pour les comptes inexistants. L'OWASP's Forgot Password Cheat Sheet signale spécifiquement ce modèle comme l'une des vulnérabilités d'énumération les plus répandues dans les applications de production. Corrigez le texte de la réponse, mais vérifiez également le temps de réponse : si votre application interroge la base de données avant de renvoyer une réponse, la différence de temps entre une réponse positive et une réponse négative pour un compte réel peut elle-même entraîner une fuite d'informations. Utilisez un traitement asynchrone ou un délai artificiel pour assurer la cohérence du délai.

  • Ajouter un CAPTCHA au formulaire de demande de réinitialisation

    Le CAPTCHA sur le formulaire de réinitialisation arrête deux types d'abus à la fois : l'inondation de réinitialisation et l'énumération de comptes à grande échelle. Un attaquant qui teste des milliers d'adresses électroniques à la recherche de comptes valides doit automatiser ces demandes. Un CAPTCHA de type "proof-of-work" impose un calcul cryptographique pour chaque demande, ce qui rend l'automatisation à grande échelle économiquement impraticable sans affecter les utilisateurs légitimes qui soumettent une demande à la fois. Pour les sites web européens, le choix du CAPTCHA est plus important ici que presque partout ailleurs. Le formulaire de réinitialisation est une page critique pour la sécurité où les utilisateurs sont déjà dans une situation vulnérable : ils ont perdu l'accès à leur compte. L'ajout d'un CAPTCHA comportemental basé sur les cookies introduit des questions de consentement à la protection de la vie privée au mauvais moment. Un CAPTCHA de preuve de travail sans cookie s'intègre sans nécessiter d'avis de consentement supplémentaire sur les pages de récupération. Pour une explication complète de son fonctionnement, consultez notre guide sur les CAPTCHA invisibles.

Protégez votre flux de réinitialisation de mot de passe sans cookies ou consentement au-dessus de la tête

CAPTCHA.eu met fin à l'inondation de réinitialisation et à l'énumération à l'échelle avec la vérification invisible de la preuve de travail. Pas de cookies, hébergé en Autriche, certifié WCAG 2.2 AA par TÜV Autriche.

Démarrer l'essai gratuit
Voir toutes les intégrations

    • Appliquer une limitation de débit par compte et par IP

      La limitation du taux sur le point de terminaison de réinitialisation limite le volume d'abus, même lorsque le CAPTCHA est déjà en place. Appliquez des limites à deux niveaux : par adresse IP et par compte. La limitation par adresse IP ralentit un attaquant qui utilise un petit nombre d'adresses. La limitation au niveau du compte garantit que même une attaque distribuée ne peut pas inonder une seule boîte de réception de manière répétée. Un seuil de départ raisonnable est de trois à cinq demandes de réinitialisation par compte et par heure. Au-delà de cette limite, rejetez les nouvelles demandes en silence : renvoyez la même réponse cohérente sans envoyer de nouveau courriel. N'indiquez pas à l'utilisateur qu'il a atteint une limite de taux, car cela laisse filtrer des informations sur votre logique de limitation de taux. Appliquez également des limites au point final de validation du jeton : un attaquant qui tente de forcer brutalement un jeton de réinitialisation doit soumettre de nombreuses tentatives de jeton, et la limitation du taux de ce point final supprime entièrement la surface d'attaque pour les jetons courts.

    • Utiliser des jetons cryptographiquement forts, de courte durée et à usage unique.

      Les tokens de réinitialisation sont les clés des comptes de vos utilisateurs. Ils doivent être générés à l'aide d'un générateur de nombres aléatoires sécurisé sur le plan cryptographique, et non à l'aide d'un horodatage, d'un identifiant séquentiel ou d'un hachage d'entrées prévisibles. La norme NIST SP 800-63B recommande au moins 20 octets d'entropie pour les secrets de réinitialisation, ce qui correspond à un jeton d'au moins 40 caractères hexadécimaux ou à un encodage base64 équivalent. Fixez une durée d'expiration courte : une heure est une durée généreuse pour la plupart des applications ; 15 à 30 minutes sont appropriées pour les contextes de haute sécurité. Expirer le jeton immédiatement après son utilisation : un jeton qui reste valide après une réinitialisation du mot de passe est une porte dérobée persistante. Expirer également tous les autres jetons actifs pour ce compte lorsqu'une nouvelle réinitialisation est demandée : si un attaquant déclenche une nouvelle réinitialisation après que l'utilisateur en a déjà reçu une, l'ancien jeton ne doit plus fonctionner.

    • Prévenir les fuites de jetons grâce aux en-têtes de référence et à la mise en cache

      Les jetons de réinitialisation fournis dans des URL présentent un risque spécifique : le jeton peut fuir à travers l'en-tête HTTP Referrer si la page de réinitialisation contient des ressources externes (scripts d'analyse, polices, ressources CDN ou images de tiers). Lorsqu'un utilisateur clique sur un lien de votre page de réinitialisation, le navigateur peut envoyer l'URL complète (y compris le jeton) en tant que référent à des serveurs externes. Pour éviter cela, définissez Referrer-Policy : no-referrer sur votre page de confirmation de réinitialisation. Définissez également des en-têtes cache-control appropriés pour éviter que les URL de réinitialisation ne soient stockées dans l'historique du navigateur ou dans les caches de proxy. Demandez à l'application de ne pas enregistrer les valeurs des jetons de réinitialisation dans les journaux d'accès ou les systèmes de suivi des erreurs, car il s'agit d'une source courante d'exposition involontaire des jetons dans les environnements de production.

    • Remplacer les questions de sécurité par des canaux secondaires vérifiés

      Les questions de sécurité ne constituent pas une méthode de récupération sûre. Les réponses aux questions de sécurité les plus courantes (nom de jeune fille de la mère, animal de compagnie de l'enfance, première école) sont souvent accessibles au public par le biais des médias sociaux, des courtiers en données ou de recherches ciblées. Elles donnent l'apparence d'une vérification sans en avoir la substance. Remplacez les questions de sécurité par des canaux secondaires vérifiés : courriel à une adresse confirmée lors de l'inscription ou codes TOTP basés sur une application. Si la récupération par SMS est inévitable, comprenez que l'échange de cartes SIM la rend vulnérable pour les comptes de grande valeur. Pour les comptes dont les enjeux sont élevés (accès administrateur, identifiants de paiement, dossiers médicaux), exigez un second canal vérifié plutôt qu'une voie de récupération unique.

    • Notifier les utilisateurs et surveiller les schémas de réinitialisation anormaux

      Envoyez aux utilisateurs une notification lorsqu'une réinitialisation est demandée, et pas seulement lorsqu'elle est terminée. Un message tel que “Une réinitialisation de mot de passe a été demandée pour votre compte. Si ce n'est pas vous, vous pouvez ignorer cet e-mail - votre mot de passe n'a pas changé” donne aux utilisateurs la possibilité de réagir avant qu'un attaquant n'utilise un jeton volé. Du côté de la surveillance, un pic soudain dans les demandes de réinitialisation est un signal précoce d'une campagne d'énumération ou d'inondation. Définissez des alertes en cas de volumes inhabituels de réinitialisation par IP, par compte ou pour l'ensemble de l'application. Établissez une corrélation entre les pics de réinitialisation et les modèles d'échec de connexion : les attaquants testent souvent les comptes énumérés sur la page de connexion avant de passer au flux de réinitialisation lorsqu'ils se heurtent à une limitation de débit ou à un CAPTCHA.

    La posture de sécurité minimale viable de réinitialisation

    Si vous ne mettez en œuvre que trois éléments : des réponses cohérentes (défense 1), un CAPTCHA sur le formulaire de réinitialisation (défense 2) et des jetons à usage unique et à courte durée de vie (défense 4), vous supprimez les vulnérabilités de réinitialisation les plus couramment exploitées. Ajoutez les autres progressivement en fonction de la sensibilité des comptes que vous protégez.

    La place des CAPTCHA dans la protection contre la réinitialisation des mots de passe

    Le CAPTCHA sur le formulaire de réinitialisation du mot de passe joue un rôle spécifique et limité : il empêche les abus automatisés du point final de réinitialisation. Il empêche les robots de tester des milliers d'adresses électroniques à la recherche de comptes valides et empêche l'inondation automatisée de réinitialisations à l'encontre d'utilisateurs spécifiques. Il ne corrige pas la faiblesse de la génération de jetons, n'empêche pas les fuites de jetons par le biais des en-têtes de référence et ne remplace pas une conception cohérente de la réponse.

    Ce positionnement est important car certaines équipes s'appuient trop sur le CAPTCHA (en l'utilisant comme seul contrôle) ou ne l'utilisent pas assez (en l'omettant parce que “les utilisateurs ne devraient pas avoir besoin de résoudre une énigme pour réinitialiser leur mot de passe”). Dans les deux cas, il s'agit d'une erreur. Le CAPTCHA invisible à preuve de travail n'ajoute aucune friction visible pour les utilisateurs légitimes qui soumettent une demande de réinitialisation. Il ne fait qu'augmenter le coût pour les robots qui en soumettent des milliers. C'est précisément là que le CAPTCHA a sa place dans la pile de défense.

    Pour le flux de réinitialisation de WordPress en particulier, notre Guide CAPTCHA WordPress couvre l'intégration au niveau de wp-login.php. Pour Keycloak, le flux de réinitialisation des identifiants nécessite un snippet FTL distinct des flux de connexion et d'enregistrement : notre snippet FTL Guide d'intégration de Keycloak couvre les trois flux avec des étapes de configuration spécifiques.

    Abus de réinitialisation de mot de passe et obligations au titre du RGPD

    Une attaque réussie de réinitialisation de mot de passe entraînant un accès non autorisé à un compte constitue une violation de données à caractère personnel au sens du RGPD. Si le compte compromis contenait des données à caractère personnel (ce qui est le cas de la quasi-totalité des comptes d'utilisateurs), vous êtes confronté aux obligations d'évaluation et de notification prévues à l'article 33.

    Le formulaire de réinitialisation lui-même présente également un aspect RGPD spécifique. Les services CAPTCHA traditionnels qui placent des cookies sur les pages de récupération créent une exigence de consentement en matière de protection de la vie privée à un moment délicat : un utilisateur qui a perdu l'accès à son compte doit maintenant naviguer dans une bannière de consentement aux cookies avant de le récupérer. Un CAPTCHA à preuve de travail sans cookie élimine ce problème de manière structurelle. Aucun mécanisme de consentement n'est nécessaire pour la couche CAPTCHA elle-même, ce qui constitue une simplification significative de la conformité pour les DPO qui gèrent la charge documentaire des flux d'authentification.

    L'angle de l'article 32

    L'article 32 du RGPD exige des mesures de sécurité technique appropriées. Pour tout site web qui stocke des données personnelles derrière des comptes d'utilisateurs, ne pas protéger le flux de réinitialisation est de plus en plus difficile à défendre dans le cadre d'un contrôle de l'autorité de surveillance. L'inondation par réinitialisation, l'énumération et le vol de jetons sont des schémas d'attaque bien documentés avec des contre-mesures bien connues. Leur mise en œuvre fait partie d'un dispositif raisonnable au titre de l'article 32.

    Liste de contrôle pour la mise en œuvre

    Utilisez cette liste de contrôle pour vérifier votre flux de réinitialisation actuel. Les éléments sont classés par ordre d'impact par effort de mise en œuvre : les éléments les plus importants offrent le plus de protection pour le moins de travail.

    • Réponses cohérentes : Vérifiez que votre formulaire de réinitialisation renvoie le même message, le même code d'état et le même temps de réponse pour les comptes existants et non existants.
    • CAPTCHA sur le formulaire de réinitialisation : Ajouter un CAPTCHA invisible au formulaire de demande de réinitialisation. Pour WordPress : voir le guide WordPress. Pour Keycloak : voir le guide Keycloak.
    • Limitation du débit par compte et par IP : Appliquer des limites aux deux niveaux. Rejeter silencieusement après le seuil : ne pas révéler l'existence de la limite.
    • Des jetons cryptographiquement forts : Confirmez que votre générateur de jetons utilise un CSPRNG avec au moins 20 octets d'entropie. Rejeter les identifiants séquentiels, les horodatages et les modèles de hachage de l'adresse électronique.
    • Expiration du jeton : Les jetons expirent dans l'heure qui suit leur émission. Les jetons expirent immédiatement lors de leur utilisation. Les nouvelles demandes de réinitialisation invalident tous les jetons antérieurs pour ce compte.
    • En-tête Referrer-Policy : Fixer Politique de référencement : no-referrer sur les pages de confirmation de réinitialisation. Examiner toutes les ressources externes chargées sur ces pages.
    • Pas de questions de sécurité : Remplacer par une vérification basée sur le courrier électronique ou sur TOTP. Vérifier tous les flux de questions de sécurité anciens encore actifs dans votre application.
    • Réinitialiser les notifications de demande : Envoyez un courriel aux utilisateurs lorsqu'une réinitialisation est déclenchée, et pas seulement lorsqu'elle est terminée.
    • Surveillance et alerte : Définissez des alertes pour les pics de volume de réinitialisation par IP et par compte. Établissez une corrélation avec les modèles d'échec de connexion.
    • HTTPS partout sur les flux de réinitialisation : Veiller à ce que toutes les pages de réinitialisation et tous les points de terminaison de soumission de jetons utilisent HTTPS avec TLS. Rejeter les jetons de réinitialisation soumis par HTTP.

    Questions fréquemment posées

    Qu'est-ce que l'abus de réinitialisation de mot de passe ?

    L'abus de réinitialisation de mot de passe est l'utilisation abusive d'un flux de récupération de compte pour obtenir un accès non autorisé, énumérer des comptes valides, inonder des boîtes de réception ou voler des jetons de récupération. Il se distingue de l'empoisonnement par réinitialisation de mot de passe, qui est une vulnérabilité technique spécifique dans laquelle un attaquant manipule la façon dont le lien de réinitialisation est généré. L'abus de réinitialisation est une catégorie plus large qui comprend quatre types d'attaques distinctes : l'énumération, l'inondation, le vol de jetons et la faiblesse de la conception de la récupération.

    Quelle est la différence entre l'abus de réinitialisation de mot de passe et l'empoisonnement de réinitialisation de mot de passe ?

    L'empoisonnement de la réinitialisation du mot de passe est une technique spécifique dans la catégorie plus large de l'abus de réinitialisation. L'empoisonnement se produit lorsqu'un attaquant manipule l'en-tête HTTP Host pour rediriger un lien de réinitialisation vers un domaine contrôlé par l'attaquant. L'abus de réinitialisation couvre un ensemble plus large de modèles : énumération de comptes par le biais de différences de réponse, inondation de réinitialisations pour submerger les boîtes de réception, forçage brutal de jetons et exploitation de méthodes de récupération faibles telles que les questions de sécurité ou l'interception de SMS.

    Les CAPTCHA empêchent-ils les abus en matière de réinitialisation de mot de passe ?

    Le CAPTCHA met un terme aux abus automatisés : l'inondation par réinitialisation et l'énumération de comptes à grande échelle. Il ne corrige pas la faiblesse de la génération de jetons, n'empêche pas la fuite de jetons par le biais des en-têtes de référence et ne remplace pas la conception d'une réponse cohérente. Utilisez le CAPTCHA comme une couche dans une pile de sécurité de réinitialisation plus large, et non comme le seul contrôle.

    Comment les attaquants énumèrent-ils les comptes par le biais du formulaire de réinitialisation ?

    Si votre formulaire de réinitialisation renvoie des réponses différentes pour les comptes existants et non existants (texte de message différent, codes d'état HTTP différents ou temps de réponse sensiblement différents), un pirate peut soumettre des demandes de réinitialisation pour une liste d'adresses électroniques et observer celles qui renvoient la réponse “compte trouvé”. Cela permet de connaître votre base d'utilisateurs enregistrés sans qu'aucun mot de passe n'ait besoin d'être craqué. La solution consiste à toujours renvoyer la même réponse, que le compte existe ou non.

    Quelle est la durée de validité d'un jeton de réinitialisation ?

    Une heure est un maximum raisonnable pour la plupart des applications. Pour les contextes plus sécurisés (comptes financiers, soins de santé, accès administratif), une durée de 15 à 30 minutes est plus appropriée. Le jeton doit expirer immédiatement après son utilisation, et tous les jetons précédents pour un compte doivent être invalidés lorsqu'une nouvelle réinitialisation est demandée. Les jetons qui restent valides après utilisation constituent une porte dérobée persistante.

    Le flux de réinitialisation du mot de passe pose-t-il un problème au regard du RGPD?

    Oui, de deux manières. Premièrement, une attaque réussie qui conduit à un accès non autorisé au compte constitue une violation de données à caractère personnel au sens du RGPD, déclenchant une évaluation au titre de l'article 33 et d'éventuelles obligations de notification. Deuxièmement, les CAPTCHA basés sur des cookies sur les pages de récupération posent une question de consentement en matière de protection de la vie privée à un moment difficile pour les utilisateurs. Un CAPTCHA sans cookie supprime entièrement cette exigence de consentement dans le flux de récupération.

    Lecture associée

    Sources primaires

    Aide-mémoire de l'OWASP sur l'oubli du mot de passeRéponses cohérentes, conception de jetons sécurisés et recommandations en matière de limitation des taux.
    Aide-mémoire de l'OWASP sur l'authentificationla réauthentification et les pratiques d'authentification sécurisées
    PortSwigger Web Security Academy : Empoisonnement par réinitialisation du mot de passeDétails techniques sur l'exploitation de l'en-tête de l'hôte dans les flux de réinitialisation
    NIST SP 800-63B: orientations sur les authentificateurs secrets mémorisés et les exigences en matière d'entropie du secret réinitialisé
    Guide de test de l'OWASP : Fonctionnalités faibles de réinitialisation des mots de passe
    CAPTCHA.eu : Qu'est-ce que l'empoisonnement par réinitialisation du mot de passe ?Définition et distinction entre l'empoisonnement et l'abus plus large de résines
    CAPTCHA.eu : Comment prévenir les attaques par prise de contrôle de comptecontexte plus large de l'authentification et de la sécurité, y compris les flux de réinitialisation

    Messages récents

    fr_FRFrench
    en_USEnglish de_DEGerman es_ESSpanish nl_NLDutch it_ITItalian fr_FRFrench