Le lien que vous pouvez écrire vous-même : dériver un jeton de réinitialisation depuis le code source

Un lien de réinitialisation de mot de passe est une capacité. Le détenir revient à prouver que vous contrôlez la boîte mail à laquelle il a été envoyé, c'est pourquoi la valeur doit être imprévisible pour quiconque n'a pas reçu l'e-mail. L'unicité est une propriété de base de données et n'a rien à voir avec cela : des entiers séquentiels sont uniques aussi.

Ce générateur tire ses deux composants de champs qui sont affichés dans une console de support, sur les factures et dans l'interface d'administration. La date d'inscription et le numéro de compte ne sont pas des secrets et n'ont jamais été censés l'être. Les injecter dans une chaîne de format produit une valeur unique par compte et calculable par quiconque a déjà vu une fiche client, un groupe bien plus large que les personnes ayant accès à la boîte mail.

Ce qui aggrave les choses, ce sont les contrôles qui l'entourent. Pas d'énumération de comptes, une expiration de trente minutes, une livraison à la seule adresse enregistrée : chacun de ces contrôles est correct, et chacun d'eux suppose que le jeton est la partie difficile. Quand le jeton peut être calculé, ils protègent la mauvaise chose, et le fait que l'endpoint confirm recherche un jeton sans session associée est ce qui transforme le calcul en prise de contrôle de compte.

• Utiliser la colonne id. La ligne des opérations a id 7741 et account_no 40218. Le générateur lit account_no.
• Prendre la date depuis la ligne de facturation. Elle partage la date d'inscription du 2024-03-11 mais a un numéro de compte différent.
• Prendre les chiffres de Rosa Castellanos. Son account_no 30218 se termine aussi par 0218, ce qui explique pourquoi une mauvaise ligne reste plausible.
• Utiliser invite_token. Elle se trouve juste au-dessus de celle qui compte et utilise le jour de l'année sur trois chiffres. Le flux de réinitialisation ne l'appelle pas.
• Supprimer le zéro initial. Le format est %04d, donc c'est 0218 et non 218.
• Se rassurer avec secrets.token_urlsafe. Elle se trouve dans le même fichier et sert aux sessions, pas aux réinitialisations.

Générez le jeton, ne le dérivez pas.

• Utilisez une valeur aléatoire cryptographiquement sûre d'au moins 128 bits, par exemple secrets.token_urlsafe(32), que ce fichier importe déjà pour les sessions.
• Stockez un hash du jeton plutôt que le jeton lui-même, pour qu'une lecture de la base de données ne livre pas des liens de réinitialisation actifs.
• Liez confirm à autre chose que le seul jeton : limitez fortement le débit, invalidez toutes les autres sessions en cas de succès, et envoyez un e-mail au compte lors d'un changement de mot de passe.
• Invalidez les jetons en circulation quand un nouveau est demandé, et gardez une expiration courte. Les deux sont peu coûteux et limitent la fenêtre d'exposition.
• Traitez BILL-1877 comme la découverte qu'elle est. Une ligne de réinitialisation consommable par quiconque en connaît le nom, sans limitation de débit, est la seconde moitié de ce bug.