Renforcer le flux de changement de mot de passe avec authentification récente et réinitialisation des sessions

Ce qui peut mal tourner lors d’un changement de mot de passe

Un changement de mot de passe est l'une des actions les plus à risque dans une application. Si un attaquant peut le déclencher, ou garder l'accès après, une petite erreur se transforme en prise de contrôle totale du compte.

Le point de départ habituel n'est pas le formulaire de mot de passe lui‑même. C'est ce que l'attaquant possède déjà : un cookie de session volé depuis un ordinateur partagé, un refresh token exposé dans des logs, ou un lien de réinitialisation extrait d'une boîte mail, de l'historique du navigateur ou des aperçus d'email. Si votre application considère toute session connectée comme entièrement de confiance, cet attaquant peut changer le mot de passe et verrouiller le vrai utilisateur.

Une confusion fréquente est « connecté » vs « récemment vérifié ». « Connecté » signifie simplement qu'il existe une session valide. « Récemment vérifié » signifie que l'utilisateur a prouvé que c'est bien lui maintenant, généralement en ressaisissant le mot de passe actuel, en utilisant un code à usage unique, ou en complétant une vérification step‑up. Sans cette barrière proche du moment du changement, une vieille session devient une clé maîtresse.

Même lorsque la mise à jour du mot de passe est protégée, beaucoup d'apps échouent juste après la mise à jour. Si les anciennes sessions et tokens restent valides, l'attaquant conserve l'accès en silence.

Ce que cela donne en pratique :

• Prise de contrôle et verrouillage du compte (mot de passe ou email modifié)
• Persistance silencieuse (les anciennes sessions continuent de fonctionner)
• Requêtes de réinitialisation répétées qui désorientent l'utilisateur
• Vol de données (messages, informations de facturation, clés API)

Un scénario réaliste : un fondateur change son mot de passe après avoir remarqué quelque chose d'étrange, mais l'attaquant détient encore un refresh token valable d'une session antérieure. Le fondateur se sent en sécurité. L'attaquant reste connecté et attend.

Objectifs de sécurité pour une mise à jour sûre

Un changement de mot de passe n'est pas juste la mise à jour d'une chaîne en base. Vous faites deux choses : confirmer que le vrai utilisateur est présent, puis couper tout accès qui pourrait appartenir à un attaquant.

Quatre objectifs couvrent l'essentiel :

• Présence : confirmer que la personne qui change le mot de passe est bien le propriétaire réel maintenant.
• Contention : une fois le mot de passe mis à jour, les anciens accès doivent cesser rapidement.
• Protection contre le replay : empêcher la réutilisation d'anciens tokens pour générer de nouveaux accès.
• Clarté : les utilisateurs doivent comprendre ce qui va se passer (et le système doit être cohérent).

Cibles de conception qui correspondent à ces objectifs :

• Exiger une vérification récente juste avant d'enregistrer le nouveau mot de passe.
• Mettre à jour les identifiants de façon atomique (pas d'états partiels).
• Invalider les sessions et appareils mémorisés selon votre politique.
• Révoquer ou faire pivoter les tokens pour que les anciens ne puissent pas être rejoués.
• Fournir une confirmation claire et une voie de récupération si le changement n'était pas attendu.

Exiger une authentification récente au bon moment

L'étape de durcissement la plus utile est d'exiger une authentification récente. L'utilisateur est déjà connecté, mais on lui demande de le prouver à nouveau et on n'accepte cette preuve que pendant une courte fenêtre.

Le timing compte. Si vous demandez trop tôt, l'utilisateur peut être interrompu et laisser un écran sensible ouvert. Si vous demandez trop tard, les équipes implémentent parfois par erreur le chemin « enregistrer » sans appliquer la vérification. Un schéma pratique :

• Laissez l'utilisateur ouvrir l'écran de paramètres.
• Exigez la vérification récente juste avant d'accepter et d'enregistrer le nouveau mot de passe.

Les bonnes sollicitations incluent la ressaisie du mot de passe actuel, une invite passkey/biométrique, ou une étape 2FA si le compte en a une.

Définissez « récent » en minutes, pas en heures. Pour les changements de mot de passe, une fenêtre de 5–15 minutes est courante.

Exemple : quelqu'un trouve une session de navigateur déverrouillée sur un ordinateur partagé et ouvre les Paramètres du compte. Il peut naviguer, mais quand il clique sur « Enregistrer le nouveau mot de passe », il doit passer une vérification fraîche. Cela bloque la plupart des attaques « détournement de session puis verrouillage » sans forcer des reconnexions constantes.

Un flux étape par étape pour changer le mot de passe

Traitez le changement de mot de passe comme une action à haut risque, même si l'utilisateur est déjà connecté. Un appareil partagé oublié ou un cookie volé suffit à rendre cela dangereux.

Un flux simple et sûr :

1. L'utilisateur ouvre les paramètres du compte. L'app identifie le compte depuis la session courante (pas depuis un champ de formulaire).
2. Juste avant d'afficher ou d'activer l'action finale « enregistrer », exigez une preuve récente (mot de passe actuel, passkey ou 2FA). Enregistrez l'heure de cette vérification et appliquez une fenêtre courte.
3. L'utilisateur saisit le nouveau mot de passe deux fois. Validez les bases (longueur, pas identique à l'ancien, éviter les choix manifestement faibles) et renvoyez des messages d'erreur clairs.
4. Sauvegardez le nouveau mot de passe en utilisant un hachage fort. Puis faites immédiatement la rotation et la révocation des identifiants pour que les anciens ne puissent plus être réutilisés.
5. Affichez une confirmation qui correspond à la réalité : quels appareils seront déconnectés, si la session courante reste active, et quoi faire si l'utilisateur n'a pas demandé le changement.

Un détail à répéter : effectuez la re‑vérification juste avant le changement, pas au moment où l'utilisateur a ouvert les paramètres. Sinon quelqu'un peut ouvrir la page, s'éloigner, et une autre personne peut finir le travail.

Invalider les sessions après la mise à jour du mot de passe

Changer un mot de passe devrait couper les sessions créées avant le changement. Sinon un attaquant qui a déjà volé un cookie de session, un refresh token ou un token « remember me » peut rester connecté après que l'utilisateur pense être en sécurité.

Vous choisissez généralement entre :

• Déconnecter partout : valeur par défaut la plus sûre.
• Déconnecter partout sauf la session courante : toujours sûr si vous ne l'autorisez qu'après une re‑auth récente.

Ce qu'il faut invalider juste après l'enregistrement dépend de votre architecture, mais les équipes oublient souvent au moins l'un de ces éléments :

• Sessions serveur et cookies de session créés avant le changement
• Refresh tokens et tokens longue durée « remember me »
• Sessions d'appareils en arrière‑plan (apps mobiles, tablettes)
• Tokens de réinitialisation de mot de passe déjà émis
• Clés API ou tokens d'accès personnels, si votre produit les supporte

Le mécanisme « remember me » mérite une attention particulière. Ces tokens sont conçus pour survivre aux redémarrages, ce qui en fait aussi de belles cibles en cas de vol. Traitez‑les comme des refresh tokens et révoquez‑les.

Le message visible par l'utilisateur doit rester simple et exact : « Votre mot de passe a été changé. Il se peut que vous deviez vous reconnecter sur d'autres appareils. »

Empêcher la réutilisation de tokens par rotation et révocation

La réutilisation de token, c'est quand une ancienne clé ouvre toujours la porte après que vous avez changé la serrure. Un utilisateur met à jour son mot de passe, mais un attaquant avec un refresh token volé ou un JWT longue durée continue d'appeler votre API.

La correction est simple : après le changement d'identifiants, tout ce qui prouve l'identité doit être traité comme suspect et remplacé.

Faire pivoter les refresh tokens, révoquer les autres

Pour la plupart des apps, les refresh tokens sont la priorité. Pivotez le token courant et révoquez tous les autres refresh tokens pour ce compte. Si un attaquant a enregistré un ancien token, il cesse de fonctionner immédiatement.

Prévoir des coupures pour les JWT

Les access tokens JWT sont souvent valables jusqu'à expiration. C'est pratique, mais problématique pour des coupures d'urgence. Deux approches courantes :

• Garder des access tokens de courte durée et s'appuyer sur la rotation des refresh tokens.
• Ajouter une vérification côté serveur (par exemple une version par utilisateur que vous comparez à chaque requête).

Un schéma propre est une « version de session » côté serveur (parfois appelée security stamp). Stockez‑la sur l'enregistrement utilisateur, incluez‑la dans les tokens, et incrémentez‑la quand le mot de passe change. Toute requête portant une ancienne version échoue, même si la signature est valide.

N'oubliez pas les identifiants longue durée

Les changements de mot de passe doivent déclencher une revue des clés longue durée qui contournent les écrans de login, comme les clés API et les tokens d'accès personnels. Si ces éléments restent valides indéfiniment, un changement de mot de passe ne contiendra pas complètement un incident.

Cas limites rencontrés en pratique

Le scénario heureux est facile. Les bugs apparaissent quand les utilisateurs ont plusieurs onglets ouverts, utilisent des liens email, ou n'ont jamais eu de mot de passe.

Changements via lien email (magic link ou reset link)

Si un changement de mot de passe démarre depuis un lien email, traitez le lien comme un moyen de commencer, pas comme un laissez‑passer pour tout finir. Quand c'est possible, demandez une confirmation fraîche avant la mise à jour finale : ressaisie du mot de passe actuel (si existant), confirmation par code à usage unique, ou une reconnexion rapide si la session est vieille.

Utilisateurs qui n'ont pas encore de mot de passe

Les utilisateurs issus d'une connexion sociale définissent souvent un mot de passe plus tard. Dans ce cas, ne demandez pas le mot de passe actuel, mais exigez quand même une confirmation forte (par exemple un code à usage unique) et indiquez clairement que définir un mot de passe active la connexion par email+mot de passe.

Cas limites à tester :

• Un flux de réinitialisation est ouvert dans un autre onglet pendant que l'utilisateur change le mot de passe depuis les paramètres.
• Deux liens de réinitialisation sont utilisés dans le mauvais ordre (le plus ancien doit échouer).
• L'utilisateur change son mot de passe, puis tente d'utiliser un ancien refresh token ou cookie « remember me ».
• L'utilisateur suppose que se déconnecter d'un onglet l'a déconnecté partout.
• Plusieurs tentatives échouées se produisent rapidement (possibilité de guessing ou d'automatisation).

Après toute mise à jour de mot de passe, envoyez une notification (email ou in‑app) indiquant ce qui a changé et quand, plus un chemin clair « Ce n'était pas moi » menant à la récupération.

Erreurs courantes exploitées par les attaquants

Les attaquants attaquent rarement l'écran de changement de mot de passe directement. Ils cherchent des failles qui leur permettent de garder l'accès après que l'utilisateur pense avoir réglé le problème.

Les échecs les plus courants :

• Les changements de mot de passe ne révoquent pas les autres sessions sur les appareils.
• Les refresh tokens ne sont pas pivotés et révoqués lors du changement de mot de passe.
• Les actions sensibles comptent uniquement sur la protection CSRF, sans prompt de re‑auth.
• L'« ancien mot de passe » est accepté sans imposer une fenêtre de recence.
• Pas de journal d'audit ni d'alerte pour les changements de mot de passe et les réinitialisations de session.

Sans logs, vous ne remarquerez pas des motifs comme des changements de mot de passe répétés, la réutilisation de refresh tokens, ou des invalidations de session qui n'ont pas réellement pris effet.

Vérifications rapides avant la mise en production

Traitez le changement de mot de passe comme une fonctionnalité critique pour la sécurité, pas comme un simple écran de paramètres. Testez‑la comme le ferait un attaquant : depuis un autre appareil, avec d'anciens tokens, et avec une connexion périmée.

Dans un environnement de staging, connectez‑vous au même compte sur deux appareils (ou deux navigateurs), puis :

• Changez le mot de passe sur l'appareil A, puis actualisez des pages protégées sur l'appareil B. L'appareil B doit être forcé de se reconnecter selon votre politique.
• Essayez d'utiliser un ancien refresh token datant d'avant le changement. Il ne doit pas générer de nouveau access token.
• Attendez que la fenêtre de « connexion récente » expire, puis essayez de changer le mot de passe à nouveau sans re‑vérification. L'action doit être bloquée jusqu'à preuve du propriétaire.
• Confirmez que vous consignez l'événement de changement de mot de passe avec l'heure et un contexte d'appareil/sessions basique (ID de session, user agent, IP si vous la stockez).
• Vérifiez le texte de l'interface : il doit correspondre clairement à ce qui arrive aux autres sessions.

Un scénario réaliste : un fondateur change son mot de passe après un email de connexion suspect, mais une tablette reste connectée. Vos tests doivent détecter cela.

Exemple : corriger un système de connexion généré par IA qui est cassé

Un schéma courant dans les apps générées par IA est l'authentification « collante » : une fois connecté, on reste connecté pendant des semaines. Changer le mot de passe met à jour la base, mais ne dégage pas les sessions existantes.

Cela ressemble à de la commodité, mais c'est une vraie faille de sécurité. Si un attaquant vole un token de session ou un refresh token (depuis des logs exposés, le stockage du navigateur, ou des secrets exposés), il peut continuer à l'utiliser. Si votre système ne révoque jamais les anciens tokens, un changement de mot de passe ne supprime pas leur accès.

Plan de correction pratique :

• Exigez une authentification récente juste avant le changement de mot de passe.
• Invalidez immédiatement les sessions actives pour cet utilisateur après la mise à jour (y compris les autres appareils, selon votre politique).
• Faites pivoter les refresh tokens et suivez un identifiant/une version côté serveur pour que les anciens refresh tokens ne puissent pas être réutilisés.
• Rejetez les tokens émis avant l'horodatage du changement de mot de passe ou avant la nouvelle version de token.

La vérification importe autant que le changement de code :

1. Connectez‑vous sur deux appareils.
2. Sur l'appareil A, changez le mot de passe.
3. Sur l'appareil B, essayez de charger une page protégée et de rafraîchir la session.
4. Confirmez que l'appareil B est forcé de se reconnecter et ne peut pas réutiliser les anciens tokens.

Le résultat souhaité est banal : après un changement de mot de passe, la persistance a disparu. Même si un token a été volé la semaine dernière, il cesse de fonctionner aujourd'hui.

Prochaines étapes si vous avez hérité d'une app générée par IA

Les changements de mot de passe et la gestion des sessions sont souvent les premiers endroits où de petites erreurs d'auth transforment en vraies prises de contrôle. Avant de modifier quoi que ce soit, clarifiez ce que vous avez :

• Quel fournisseur ou quelle bibliothèque d'auth utilisez‑vous
• Où résident les sessions (cookies, store de sessions serveur, JWT only, ou mixte)
• Quels types de tokens existent (access, refresh, reset, magic links)
• Si vous pouvez révoquer sessions et tokens par utilisateur

Ensuite, écrivez votre politique par défaut. Le comportement par défaut le plus sûr est généralement « déconnecter partout après un changement de mot de passe ». Certains produits laissent la session courante connectée, mais seulement si vous appliquez une re‑auth récente et pivotez correctement les tokens.

Si vous traitez un code généré par des outils comme Lovable, Bolt, v0, Cursor ou Replit, il est fréquent que l'interface ait l'air finie tandis que la révocation et l'invalidation des sessions manquent. FixMyMess (fixmymess.ai) se concentre sur le diagnostic et la réparation de ces failles d'auth, et propose un audit de code gratuit pour cartographier les problèmes de sessions et de tokens avant de décider d'une refonte ou de changements plus importants.