Des flux de réinitialisation de mot de passe qui ne divulguent ni comptes ni jetons

Objectif

Permettre à un utilisateur ayant perdu son mot de passe de retrouver l'accès, sans offrir à un attaquant un moyen de prendre le contrôle du compte ou de découvrir quelles adresses sont enregistrées.

Prérequis

Des mots de passe stockés sous forme de hachages salés et lents ; un moyen d'envoyer un e-mail (ou un autre canal secondaire) que l'application contrôle ; un limiteur de débit capable de compter par compte et par adresse source.

Étapes

1. Accepter le formulaire de demande pour toute saisie. L'aide-mémoire OWASP cité demande un message identique pour les comptes existants et inexistants, ainsi qu'un temps de réponse constant ; effectuer le même travail dans les deux branches plutôt que de retourner prématurément.
2. Limiter le débit des demandes par compte et par source, afin qu'un attaquant ne puisse ni inonder la boîte de réception d'une victime ni forcer les jetons par force brute.
3. Générer le jeton avec un générateur aléatoire cryptographiquement sûr, suffisamment long pour déjouer les tentatives de devinette, lié à un seul utilisateur, avec une expiration courte ; n'en stocker que le hachage, comme pour un mot de passe. Les jetons signés tels que les JWT sont possibles, mais apportent leurs propres modes de défaillance.
4. Construire l'URL de réinitialisation à partir d'une origine configurée, jamais à partir de l'en-tête Host de la requête, afin qu'un en-tête empoisonné ne puisse pas rediriger le lien vers le domaine d'un attaquant. Utiliser HTTPS.
5. Servir la page de réinitialisation avec Referrer-Policy: no-referrer afin que le jeton présent dans l'URL ne fuite pas vers des ressources tierces, et limiter aussi le débit du point d'accès du jeton.
6. Ne rien modifier sur le compte tant qu'un jeton valide n'est pas présenté : ni verrouillage, ni indicateur, ni changement de mot de passe.
7. Une fois le jeton valide : exiger le nouveau mot de passe à deux reprises, appliquer la politique de mot de passe habituelle, le stocker, invalider le jeton, et soit invalider les autres sessions, soit proposer de le faire. Ne pas connecter l'utilisateur depuis la page de réinitialisation ; le rediriger vers la connexion normale.
8. Envoyer une notification indiquant que le mot de passe a été changé (sans le mot de passe). Conserver une voie pour les utilisateurs qui ne contrôlent plus le canal secondaire, telle qu'un contact d'assistance vérifié.

Résultat attendu

Une demande de réinitialisation pour une adresse inconnue et pour une adresse connue sont indiscernables pour le demandeur ; un lien intercepté expire rapidement et ne fonctionne qu'une fois ; une injection dans l'en-tête Host ou une fuite par le referrer ne produit rien d'exploitable.

Limites et base de vérification

Suit l'aide-mémoire cité ; aucune mesure n'est revendiquée. Les codes PIN par SMS (de 6 à 12 chiffres, envoyés par un canal secondaire) échangent la longueur du jeton contre une session limitée qui ne permet que de réinitialiser le mot de passe. Des questions de sécurité seules ne constituent pas une méthode de récupération. Les comptes avec authentification multifacteur nécessitent le chemin de récupération MFA, pas celui-ci.