Un e-mail de mot de passe prouve la réversibilité, pas un schéma

Un service qui envoie par e-mail le mot de passe actuel d’un utilisateur a démontré une chose : il peut obtenir ce secret sous une forme qu’il peut envoyer. Il n’a pas démontré quelle colonne, quel algorithme ou quelle bibliothèque l’a produit. La distinction compte parce que la constatation est réelle et que la conclusion qu’on en tire est généralement trop précise. La réversibilité quelque part dans le parcours est le mécanisme ; un format de stockage deviné ne l’est pas.

Gardez les preuves à ce niveau et le reste de l’analyse restera exact.

Ce que prouve le renvoi de l’ancien secret

Un vérificateur à sens unique ne peut pas produire le mot de passe d’origine, car il a été conçu pour ne pas être inversible. Si le service peut envoyer le mot de passe par e-mail, alors à cet instant il détient une matière dont le mot de passe peut être récupéré, ou il intercepte et stocke le texte en clair avant le hachage. Dans les deux cas, le chemin de récupération est réversible, et c’est une véritable constatation de sécurité. Cela ne dit rien sur la question de savoir si la même base de données utilise un hachage coûteux pour d’autres colonnes.

Attention aussi au cas intermédiaire : un blob chiffré stocké avec une clé détenue par l’application est réversible en pratique, même si le mot chiffré sonne rassurant dans un rapport.

Pourquoi c’est une constatation de conception, pas une carte du stockage

L’e-mail prouve la récupérabilité et n’identifie pas le schéma exact. Il peut s’agir de texte en clair, de chiffrement déterministe, d’une routine d’obfuscation d’un fournisseur ou d’un magasin d’identifiants distinct utilisé uniquement pour la récupération. Les différentes parties d’un produit utilisent souvent des stockages différents. Attribuer un algorithme sur la foi d’un seul e-mail est le genre d’affirmation qui s’effondre lors d’une réunion de suivi.

Ce que vous pouvez dire est plus étroit et plus utile : ce chemin peut récupérer le secret, donc le produit ne peut pas affirmer qu’il n’existe aucun identifiant récupérable. Tout le reste exige les preuves de l’opérateur.

Construisez la réinitialisation autour de l’autorisation

Une réinitialisation résout un autre problème : prouver que le demandeur peut choisir un nouveau mot de passe. Les recommandations de l’OWASP à ce sujet décrivent des jetons ou codes à usage unique générés de façon sûre avec une expiration appropriée, et elles traitent l’étape de demande comme quelque chose à protéger contre l’énumération et l’inondation. Une demande non authentifiée ne doit pas modifier le compte à elle seule. Validez l’autorisation avant d’accepter le remplacement et rendez le jeton inutilisable après un usage réussi.

Le canal e-mail fait partie du modèle de sécurité. Posséder un nom de compte ne prouve rien, et un flux de réinitialisation qui révèle si un compte existe donne à un attaquant un annuaire avec lequel travailler.

Invalidez ce que le mot de passe protégeait

Changer un mot de passe ne met pas automatiquement fin à l’accès qu’il accordait. Les sessions VPN actives, les appareils mémorisés et les jetons émis par le serveur peuvent chacun avoir leur propre comportement d’invalidation. Décidez délibérément lesquels doivent se terminer et vérifiez que l’implémentation le fait, car un utilisateur qui suppose qu’une réinitialisation l’a déconnecté partout se trompe souvent. Consignez cette décision avec le flux.

Pour les opérateurs : documentez quel composant vérifie la demande, lequel change l’identifiant et comment les sessions associées sont gérées. Pour les utilisateurs : protégez le canal de récupération légitime et traitez tout message qui renvoie un mot de passe comme suspect.

L’évaluation précise est courte : ce que le message démontre, ce qui reste inconnu et si la récupération remplace l’accès par un processus contrôlé.