Les failles de réinitialisation de mot de passe
Tous les services proposent un lien « mot de passe oublié ». C’est une nécessité : sans lui, des utilisateurs perdraient définitivement leur compte. Mais c’est aussi une seconde porte d’entrée, souvent moins bien gardée que la première. Si le mécanisme de récupération est faible, inutile de deviner le mot de passe : on se fait ouvrir la porte. Dans cette leçon, vous apprenez à examiner ce mécanisme et à recommander des corrections.
Rappel légal
Déclencher une réinitialisation sur le compte d’une personne réelle, ou détourner un compte, est une infraction (articles 323-1 à 323-3-1 du Code pénal), sans parler de l’atteinte à la vie privée. Vos tests se font sur des comptes de test que vous avez créés dans votre application d’entraînement locale, avec des adresses de laboratoire.
Comment fonctionne une récupération typique
- L’utilisateur indique son identifiant ou son adresse e-mail.
- L’application génère un jeton (un secret à usage unique) et l’envoie, par e-mail ou SMS, sous forme de lien ou de code.
- L’utilisateur présente ce jeton, et l’application l’autorise à choisir un nouveau mot de passe.
Le jeton joue le rôle d’un mot de passe temporaire. Toute la sécurité repose sur trois propriétés : il est imprévisible, à durée limitée et à usage unique. Les failles viennent presque toujours de l’absence de l’une d’elles.
Les défauts à rechercher
1. Un jeton prévisible
Si le jeton est dérivé de l’heure, d’un compteur ou de l’adresse e-mail, il peut être deviné. Pour l’évaluer, déclenchez plusieurs réinitialisations sur vos comptes de test et comparez les jetons reçus : ressemblent-ils à des valeurs aléatoires, ou voit-on un motif ? Un jeton court (quelques chiffres) sans limite d’essais est aussi vulnérable.
2. Un jeton qui ne s’éteint pas
Un lien de réinitialisation qui reste valable des jours, ou qui peut être réutilisé après avoir servi, est un risque : il reste dans les boîtes e-mail, les historiques, les sauvegardes. Test : utilisez le lien, changez le mot de passe, puis essayez de réutiliser le même lien. Il doit être refusé. Demandez deux jetons successifs : le premier doit être invalidé quand le second est émis.
3. Un jeton qui fuit
Un jeton ne doit apparaître ni dans la réponse de la page « mot de passe oublié » ni dans un en-tête ni dans un message d’erreur. Il ne doit être connu que de la boîte de l’utilisateur. Autre fuite classique : le lien envoyé est construit à partir d’une information fournie par la requête (comme le nom d’hôte), ce qui peut faire pointer le lien vers un autre site. En principe de défense : construire ce lien à partir d’une configuration côté serveur, jamais à partir de données de la requête.
4. Des questions de sécurité faibles
« Nom de jeune fille de votre mère », « ville de naissance », « nom de votre premier animal » : ces réponses se trouvent souvent sur les réseaux sociaux ou dans des documents publics. Elles sont à déconseiller comme unique moyen de récupération.
5. L’énumération de comptes
Si la page répond « cette adresse n’existe pas » pour un compte inconnu et « un e-mail a été envoyé » pour un compte existant, elle révèle qui est inscrit. La bonne pratique : afficher le même message dans tous les cas (« si un compte correspond, un message a été envoyé »), et que la durée de réponse reste comparable.
6. L’absence de limitation
Un formulaire de récupération sans limite permet d’inonder la boîte d’un utilisateur de messages (nuisance) ou de tester de nombreux codes courts. Limitez le nombre de demandes et d’essais par compte et par source.
7. Un changement d’adresse e-mail non protégé
Si l’on peut changer l’adresse e-mail d’un compte sans retaper le mot de passe actuel ni confirmer à l’ancienne adresse, quiconque détourne brièvement une session peut ensuite verrouiller le compte à son profit. Les opérations sensibles doivent demander une nouvelle confirmation d’identité.
Ce qui doit se passer après une réinitialisation
Une bonne application, une fois le mot de passe changé :
- invalide le jeton utilisé et tous les jetons en attente ;
- déconnecte toutes les sessions existantes du compte (si un intrus était connecté, il est évincé) ;
- notifie l’utilisateur par un message, afin qu’il puisse réagir si ce n’était pas lui ;
- n’envoie jamais le nouveau mot de passe en clair par e-mail.
Démarche de test en labo
| Contrôle | Comment le vérifier | Résultat attendu |
|---|---|---|
| Message uniforme | Comparer les réponses pour un compte existant et inexistant | Messages identiques |
| Imprévisibilité | Comparer plusieurs jetons de comptes de test | Aucun motif apparent, jeton long |
| Usage unique | Réutiliser un lien déjà consommé | Refus |
| Expiration | Utiliser un lien après le délai annoncé | Refus |
| Invalidation des sessions | Rejouer l’ancien cookie après réinitialisation | Refus |
| Limitation | Demander plusieurs réinitialisations rapprochées | Ralentissement ou blocage |
Ce tableau est un bon modèle de liste de contrôle pour votre carnet.
Astuce
Beaucoup d’applications d’entraînement n’envoient pas de vrais e-mails. Cherchez dans la documentation comment consulter les messages envoyés (journal de l’application, boîte de test intégrée). N’utilisez jamais votre vraie adresse e-mail pour ces essais.
À vous de jouer
Examinez le mécanisme de récupération de votre application d’entraînement, ou, à défaut, étudiez un laboratoire guidé de la PortSwigger Web Security Academy consacré à ce thème.
- Créez deux comptes de test et déclenchez la réinitialisation sur chacun.
- Comparez les messages pour un compte existant et un compte inexistant.
- Vérifiez si le lien est à usage unique et s’il expire.
- Complétez le tableau de contrôle ci-dessus avec vos observations.
Voir une solution
Il n’y a pas une seule bonne réponse, puisque cela dépend de l’application. Un exemple de constat bien rédigé : « Le lien de réinitialisation reste valable après usage. Impact : un lien récupéré dans un historique ou une boîte compromise permet de reprendre le compte. Gravité moyenne à élevée. Correction : invalider le jeton à la première utilisation, durée de vie courte, invalidation des sessions existantes et notification de l’utilisateur. » Si tout est conforme, notez-le aussi : c’est un résultat à part entière.
À retenir
- La récupération de compte est une seconde porte d’entrée : elle doit être aussi solide que la connexion.
- Un jeton doit être imprévisible, à durée limitée et à usage unique.
- Évitez l’énumération de comptes, les questions de sécurité faibles et les liens construits à partir de données de la requête.
- Après réinitialisation : invalider les jetons et les sessions, notifier l’utilisateur.
- Les opérations sensibles (changer d’e-mail) demandent une nouvelle confirmation.
Pour consolider l’authentification, on ajoute souvent un second facteur. Est-il infaillible ? C’est la dernière leçon de ce chapitre.