Discussion :

[Aizen64]

Bonjour,

J'ai une problématique basique que je ne sais pas résoudre en pratique.

Le cas d'un login :
-> vérification du login/mot de passe. Si les données correspondent, le process de login est bon.
-> adresse email existante mais pas de mot de passe défini. Par conséquent, la base est de générer un token d'activation spécifique à l'utilisateur, de lui envoyer un mail avec ce token. Comment gérer aussi la durée de validité du lien ?

La partie pour générer un mot de passe aléatoire n'est pas complexe mais je n'arrive pas à appliquer le reste de la logique que j'ai expliqué dans mon message.

[tdutrion]

Bonjour,

Il me semble que le plus simple dans ce cas est de stocker le code avec un timestamp en base de donnée. Mets le timestamp en UTC.

Ensuite quand l'utilisateur accède à la page de reset via le lien, tu vérifies dans ta bd si le code est valide, a déjà été utilisé, et si le temps actuel UTC est inférieur au timestamp stocké + x minutes.

[Aizen64]

Pour résumer ta logique :
- générer un hash aléatoire en y concaténant la date/heure courante au format UTC lors du passage de variable en POST et le stocker dans la BDD,

Lors du clic sur le lien :
- Réception et vérification de la chaîne passée en GET si elle correspond à ce qui est stocké dans la BDD.

Quel est l’intérêt de vérifier la timestamp ? Définir la durée de validité du lien ? Par exemple si je souhaite que le lien de reset/activation de compte soit valable 24 heures, si la comparaison entre la timestamp stockée en BDD et la date/heure actuelle est supérieure à ce délai, le lien est considéré comme invalide ?

La problématique du hash :
A une chaîne donnée correspond un hash fixe, en connaissant l'adresse email d'un utilisateur et la méthode de hachage, il est possible de déterminer l'emprunte non ? L'utilisation de la timestamp permet ajoutée au champ qui permet le login est-elle une méthode suffisante pour sécuriser la validation ?

[tdutrion]

Désolé je m'exprime mal en ce moment je crois, ça me fait ça sur tous les forums !

Pour reprendre en détail :

Page 1 : password reset. L'utilisateur saisis une adresse email dans un champ, tu as aussi un token csrf pour la securité. Ton process à ce moment là est : vérifier le csrf - vérifier que l'email existe - générer un code unique (cf Enrico Zimuel, ou randomlib d'IrcMaxell) - stocker le code unique avec l'id de l'utilisateur et le timestamp UTC courant dans la base de donnée - envoyer l'email à l'utilisateur.

A partir de là, le code est lié à l'utilisateur uniquement dans ta base de données, et ne peut être recréé.

L'utilisateur suit le lien de ton mail et tombe sur une page. Tu récupères le code en get, vérifie qu'il existe dans la base de données, compare le timestamp associé dans la bd avec le timestamp courant de ton serveur web converti en UTC, et c'est gagné ! Cette dernière vérification sert en effet à définir si le code est trop vieux et dire à l'utilisateur d'en redemander un.


Du coup dans ce cas là, le token est une string générée pour être unique, donc ton problème disparait.

[Aizen64]

Désolé je m'exprime mal en ce moment je crois, ça me fait ça sur tous les forums !

Pour reprendre en détail :

Page 1 : password reset. L'utilisateur saisis une adresse email dans un champ, tu as aussi un token csrf pour la securité. Ton process à ce moment là est : vérifier le csrf - vérifier que l'email existe - générer un code unique (cf Enrico Zimuel, ou randomlib d'IrcMaxell) - stocker le code unique avec l'id de l'utilisateur et le timestamp UTC courant dans la base de donnée - envoyer l'email à l'utilisateur.

A partir de là, le code est lié à l'utilisateur uniquement dans ta base de données, et ne peut être recréé.

L'utilisateur suit le lien de ton mail et tombe sur une page. Tu récupères le code en get, vérifie qu'il existe dans la base de données, compare le timestamp associé dans la bd avec le timestamp courant de ton serveur web converti en UTC, et c'est gagné ! Cette dernière vérification sert en effet à définir si le code est trop vieux et dire à l'utilisateur d'en redemander un.


Du coup dans ce cas là, le token est une string générée pour être unique, donc ton problème disparait.

Je comprends. Serait-il possible de faire l'opération sans interaction avec la BDD pour la vérification de l'URL générée ? Parce que dans ce cas, j'aurai besoin d'un champ spécifique dans une table et je ne vois pas l'intérêt de stocker un hash de ce type en base puisqu'il n'a d'intérêt que lors du reset.

[tdutrion]

Alors sans bd... tout dépends ce qu'on appelle BD... Il te faut tout de même un stockage persistant car tu ne peux pas le mettre en session (rien ne te dis que ton utilisateur va ouvrir le lien dans un autre navigateur car la plupart cliquent dans leur client mail qui ouvre IE...).

Ceci dit n'importe quel storage marche (Redis, fichier, DBMS...) tant que c'est accessible depuis n'importe quelle instance de ton app (particulièrement si tu utilises un PAAS ou autre déploiement scalable).

Pour moi, la db reste le moyen le plus efficace dans ce cas.