Votre compte a été piraté — changer simplement le mot de passe suffit-il à éjecter l'attaquant ?
Réponse courte
Pas à lui seul. De nombreux systèmes maintiennent valides les sessions existantes et les jetons déjà émis après un changement de mot de passe — jetons OAuth de rafraîchissement, « mots de passe d'application », clés d'API et cookies persistants — si bien qu'un attaquant disposant d'une session active peut rester. La bonne réponse est de changer le mot de passe ET d'invalider toutes les sessions et jetons, révoquer les identifiants d'application, et auditer les appareils MFA et les paramètres de récupération. Croire qu'une réinitialisation seule éjecte l'attaquant est une erreur classique de réponse à incident.
Cela semble évident : l'attaquant est entré avec votre mot de passe, alors changez-le et il est bloqué. Dans les systèmes d'identité modernes, cette intuition est souvent fausse, et agir en conséquence donne un faux sentiment de confinement.
Pourquoi un changement de mot de passe n'éjecte pas toujours
L'authentification et l'accès continu sont découplés. Vous vous authentifiez une fois avec un mot de passe, mais le système émet ensuite des artefacts à durée de vie plus longue qui ne revérifient pas le mot de passe à chaque requête :
- Sessions actives / cookies — une session de navigateur connectée peut rester valide pendant des jours, quel que soit le mot de passe actuel.
- Jetons OAuth de rafraîchissement — émis aux applications connectées, ils génèrent de nouveaux jetons d'accès sans jamais revoir le mot de passe.
- Mots de passe d'application / clés d'API — des identifiants séparés à longue durée de vie, créés précisément pour ne pas dépendre du mot de passe principal.
- Confiance persistante de l'appareil — les options « se souvenir de cet appareil » qui sautent la ré-authentification.
Un attaquant ayant établi une session active ou récupéré un jeton de rafraîchissement continue simplement à l'utiliser après votre réinitialisation.
Ce qui éjecte vraiment l'attaquant
Traitez la réinitialisation comme une étape d'une séquence, pas le travail entier :
- Réinitialiser le mot de passe — oui, faites-le quand même.
- Invalider toutes les sessions — déclenchez une déconnexion globale / « révoquer toutes les sessions » pour tuer les cookies existants.
- Révoquer jetons et identifiants d'application — supprimez les autorisations OAuth, jetons de rafraîchissement, mots de passe d'application et clés d'API.
- Auditer la MFA et les paramètres de récupération — les attaquants ajoutent souvent leur propre appareil MFA, e-mail alternatif ou téléphone de récupération pour réinitialiser le mot de passe immédiatement après. Retirez tout ce que vous ne reconnaissez pas.
- Vérifier les règles de transfert et les consentements OAuth — persistance courante sur les comptes de messagerie.
À retenir pour l'entretien
L'erreur est de traiter l'authentification comme une porte continue alors que c'est un point de contrôle ponctuel qui émet des jetons durables. Dire « changez le mot de passe » seul montre que vous ne maîtrisez pas le cycle de vie des sessions et des jetons. La bonne réponse est « réinitialiser le mot de passe et révoquer chaque session, jeton et voie de récupération, puis vérifier la MFA ».
Questions de suivi probables
- Pourquoi un jeton OAuth de rafraîchissement peut-il continuer à fonctionner après la réinitialisation du mot de passe ?
- Quels artefacts du parcours de récupération auditer pour que l'attaquant ne puisse pas simplement réinitialiser le mot de passe à nouveau ?
- Quand « déconnexion globale / révoquer toutes les sessions » est-elle la bonne première action ?