Cracker un jeton de réinitialisation de mot de passe prévisible

Quand vous cliquez sur « mot de passe oublié », le serveur génère un token à usage unique, vous envoie par email un lien qui le contient, puis fait confiance à quiconque présente ce token pour réinitialiser le compte. Le token est la seule chose qui se dresse entre un attaquant et le compte, donc sa propriété la plus importante est l'imprévisibilité : ce doit être un secret long et aléatoire que le serveur a stocké et peut comparer, et rien d'autre.

Le token de ce challenge échoue à ce test. Il ressemble à un fouillis de lettres sans signification, mais sa forme le trahit - c'est simplement du base64, un encodage réversible que n'importe qui peut décoder d'un seul clic, avec la chaîne lisible inversée pour ajouter une fine couche d'obscurité. Encoder n'est pas chiffrer et ce n'est pas un secret : il n'y a pas de clé, donc la transformation fonctionne dans les deux sens pour tout le monde. Un token qui se dénoue en deux clics porte une entropie nulle que l'attaquant possède tout autant.

L'impact est la prise de contrôle du compte. Si les tokens de réinitialisation sont un encodage réversible de données du compte - un identifiant utilisateur, un email, un horodatage - un attaquant qui voit un lien valide peut le décoder, comprendre le motif, et forger un tout nouveau token valide pour un autre compte sans jamais recevoir l'email de cette victime. Le lien qui « a l'air aléatoire » est en réalité un message public que n'importe qui peut lire et réécrire.

• Supposer qu'un token est aléatoire parce qu'il ressemble à du bruit - une longue chaîne de lettres en casse mixte est exactement ce que produit le base64 à partir de texte ordinaire.
• Traiter le base64 (ou le hexadécimal, ou l'URL-encoding) comme un contrôle de sécurité. Ce sont des encodages réversibles sans clé ; ils ne cachent rien à quiconque les reconnaît.
• Ajouter une « obfuscation » comme inverser la chaîne ou empiler des encodeurs, en croyant que cela ajoute une vraie protection. L'obscurité n'est pas de l'entropie - quelques clics de plus n'arrêtent pas un attaquant.
• Dériver le token de données de compte prévisibles (email, identifiant séquentiel, horodatage). Si les entrées sont devinables, le token est forgeable.

Un token de réinitialisation doit être indevinable pour quiconque ne le possède pas déjà, ce qui signifie un véritable aléa plutôt qu'une transformation de données connues. Générez-le à partir d'une source aléatoire cryptographiquement sûre avec une longueur suffisante pour rendre le brute force sans espoir, stockez-le côté serveur (idéalement sous forme de hash, comme vous stockez les mots de passe), et lors de la réinitialisation, recherchez la valeur et comparez-la à ce que vous avez stocké. Le token ne doit rien révéler sur le compte et ne doit jamais pouvoir être reconstruit à partir des données du compte.

• Générez au moins 128 bits d'entropie à partir d'un CSPRNG (par exemple une valeur aléatoire de 32 octets), pas un compteur, un horodatage, ou un champ utilisateur encodé.
• Stockez un hash du token, pas le token lui-même, pour qu'une fuite de base de données ne livre pas des liens de réinitialisation actifs.
• Faites expirer les tokens rapidement (minutes, pas jours) et invalidez-les immédiatement après un seul usage réussi.
• Limitez le taux des demandes de réinitialisation et ne révélez jamais si une adresse email existe.