Dans le cadre de la refonte d'un site en PHP/mysql, je dois ajouter la
fonctionnalité Mot de passe oublié sur l'accès à un espace membre.
Je m'interrogais sur les moyens de mettre en oeuvre cette procédure et
même si cette question n'est pas purement technique PHP, je fait appel à
vos expériences.
Le sgbd contient le login, et le hashage sha1 du mot de passe (oui, oui,
je sais que John G. n'est pas pour, mais c'est déjà stocké comme ca...).
Donc ma première idée est de mettre en place la page classique contenant
un champ entrez votre email et on vous renvoie un nouveau mot de passe.
Au moment de la validation, je pensai changer le mot de passe dans la
base en utilisant un généré aléatoirement, et envoyer ce dernier à
l'adresse email.
Or, comme les adresses email figurent aussi dans des messages sur le
site, j'ai peur qu'un petit malin ne s'amuse à changer les mots de passe
des autres. Bien sur, les membres recevront leur nouveau mot de passe,
mais ils risquent de se lasser de les modifier si cela se reproduit.
D'autres part, je n'ai pas d'information dans la base concernant le
compte qui ne soit pas visible sur le site (genre, quel est le nom de
votre chien) qui permettrait d'identifier à coup sur le demandeur. Et
comme, il y a déjà plusieurs milliers de compte déjà créé, je ne peux
ajouter cette fonction.
Avez-vous des idées ou des liens pour résoudre ce problème?
Voila ce que peut faire le webmaster :) L'une des raisons pour lesquelles je ne participe presque plus à ce
forum et que je me contente de modérer les articles, c'est que j'en ai marre de répéter toujours les mêmes choses.
Il est "évident" (?) que bannir l'IP sera au mieux inutile, et au pire une catastrophe.
1) tout le monde le sait (?) REMOTE_ADDR n'est pas fiable.
2) tout le monde le sait (?) il n'est d'ailleurs même pas possible de connaître l'adresse IP source *avec certitude*.
3) en admettant que ce soit la bonne, il y a des adresses IP dynamiques. Donc non seulement ça n'empêchera pas R00t-P4t4t0r de recommencer avec une autre IP dans 10 minutes, mais en plus avec un peu de malchance, un pauvre gars se pointera le lendemain avec l'IP bannie et l'aura dans le...
4) il est de notoriété publique (?) que les proxys ça existe. Pour ne parler que de ceux-ci, tous les abonnés AOL tournent sur les mêmes adresses IP. Même si oui je sais "AOL sucks", ça fait quand même bannir une tétrachiée d'utilisateurs légitimes.
5) le temps que l'utilisateur légitime dont on demande indûment le changement de passe lise son mail, se décide à l'envoyer au webmaster, que le webmaster le lise, si j'ai envie de f... la m... je vais scripter la demande de changement de mot de passe et toute la base de données sera déjà pourrie.
Bref, halte aux conneries.
JG
Voila ce que peut faire le webmaster :)
L'une des raisons pour lesquelles je ne participe presque plus à ce
forum et que je me contente de modérer les articles, c'est que j'en ai
marre de répéter toujours les mêmes choses.
Il est "évident" (?) que bannir l'IP sera au mieux inutile, et au pire
une catastrophe.
1) tout le monde le sait (?) REMOTE_ADDR n'est pas fiable.
2) tout le monde le sait (?) il n'est d'ailleurs même pas possible de
connaître l'adresse IP source *avec certitude*.
3) en admettant que ce soit la bonne, il y a des adresses IP dynamiques.
Donc non seulement ça n'empêchera pas R00t-P4t4t0r de recommencer avec
une autre IP dans 10 minutes, mais en plus avec un peu de malchance, un
pauvre gars se pointera le lendemain avec l'IP bannie et l'aura dans le...
4) il est de notoriété publique (?) que les proxys ça existe. Pour ne
parler que de ceux-ci, tous les abonnés AOL tournent sur les mêmes
adresses IP. Même si oui je sais "AOL sucks", ça fait quand même bannir
une tétrachiée d'utilisateurs légitimes.
5) le temps que l'utilisateur légitime dont on demande indûment le
changement de passe lise son mail, se décide à l'envoyer au webmaster,
que le webmaster le lise, si j'ai envie de f... la m... je vais scripter
la demande de changement de mot de passe et toute la base de données
sera déjà pourrie.
Voila ce que peut faire le webmaster :) L'une des raisons pour lesquelles je ne participe presque plus à ce
forum et que je me contente de modérer les articles, c'est que j'en ai marre de répéter toujours les mêmes choses.
Il est "évident" (?) que bannir l'IP sera au mieux inutile, et au pire une catastrophe.
1) tout le monde le sait (?) REMOTE_ADDR n'est pas fiable.
2) tout le monde le sait (?) il n'est d'ailleurs même pas possible de connaître l'adresse IP source *avec certitude*.
3) en admettant que ce soit la bonne, il y a des adresses IP dynamiques. Donc non seulement ça n'empêchera pas R00t-P4t4t0r de recommencer avec une autre IP dans 10 minutes, mais en plus avec un peu de malchance, un pauvre gars se pointera le lendemain avec l'IP bannie et l'aura dans le...
4) il est de notoriété publique (?) que les proxys ça existe. Pour ne parler que de ceux-ci, tous les abonnés AOL tournent sur les mêmes adresses IP. Même si oui je sais "AOL sucks", ça fait quand même bannir une tétrachiée d'utilisateurs légitimes.
5) le temps que l'utilisateur légitime dont on demande indûment le changement de passe lise son mail, se décide à l'envoyer au webmaster, que le webmaster le lise, si j'ai envie de f... la m... je vais scripter la demande de changement de mot de passe et toute la base de données sera déjà pourrie.
Bref, halte aux conneries.
JG
Bilango
Donc tu ne touches à rien dans la table qui stocke les mots de passe, tu envoies un jeton d'autorisation sur un email réputé fiable, et tu attends. Si ce jeton est demandé pendant sa période de validité, tu fais l'update avec le nouveau mot de passe fournit, sinon... tu ne fais rien d'autre que la purge du jeton.
C'est très clair, merci.
C'est ça qui me broute profondément avec ce mécanisme des sessions PHP4, c'est que les développeurs ne savent plus comment ça marche. Le paragraphe que j'ai écrit au dessus, c'est exactement la description d'une gestion de sessions "manuelle" telle qu'on la faisait déjà en PHP3 (et telle que je la fais encore d'ailleurs). Cf le tutoriel que je diffuse sur saphirtech.com pour un détaillage complet.
Effectivement, la réponse était au chapitre 10 du Cours de web dynamique, et j'ignorai le fonctionnement précis des sessions.
Je vais relire tes documents, et te remercie sincérement de ces merveilleuses contributions.
-- Bilango
Donc tu ne touches à rien dans la table qui stocke les mots de passe, tu
envoies un jeton d'autorisation sur un email réputé fiable, et tu
attends. Si ce jeton est demandé pendant sa période de validité, tu fais
l'update avec le nouveau mot de passe fournit, sinon... tu ne fais rien
d'autre que la purge du jeton.
C'est très clair, merci.
C'est ça qui me broute profondément avec ce mécanisme des sessions PHP4,
c'est que les développeurs ne savent plus comment ça marche. Le
paragraphe que j'ai écrit au dessus, c'est exactement la description
d'une gestion de sessions "manuelle" telle qu'on la faisait déjà en PHP3
(et telle que je la fais encore d'ailleurs). Cf le tutoriel que je
diffuse sur saphirtech.com pour un détaillage complet.
Effectivement, la réponse était au chapitre 10 du Cours de web
dynamique, et j'ignorai le fonctionnement précis des sessions.
Je vais relire tes documents, et te remercie sincérement de ces
merveilleuses contributions.
Donc tu ne touches à rien dans la table qui stocke les mots de passe, tu envoies un jeton d'autorisation sur un email réputé fiable, et tu attends. Si ce jeton est demandé pendant sa période de validité, tu fais l'update avec le nouveau mot de passe fournit, sinon... tu ne fais rien d'autre que la purge du jeton.
C'est très clair, merci.
C'est ça qui me broute profondément avec ce mécanisme des sessions PHP4, c'est que les développeurs ne savent plus comment ça marche. Le paragraphe que j'ai écrit au dessus, c'est exactement la description d'une gestion de sessions "manuelle" telle qu'on la faisait déjà en PHP3 (et telle que je la fais encore d'ailleurs). Cf le tutoriel que je diffuse sur saphirtech.com pour un détaillage complet.
Effectivement, la réponse était au chapitre 10 du Cours de web dynamique, et j'ignorai le fonctionnement précis des sessions.
Je vais relire tes documents, et te remercie sincérement de ces merveilleuses contributions.
-- Bilango
Pozzo
John GALLET wrote:
C'est ça qui me broute profondément avec ce mécanisme des sessions PHP4, c'est que les développeurs ne savent plus comment ça marche.
Je parie que tu n'aimes pas non plus le garbage collector de Java ;-)
-- Pozzo - Et dire qu'on faisait des cgi en C il n'y a pas si longtemps...
John GALLET wrote:
C'est ça qui me broute profondément avec ce mécanisme des sessions PHP4,
c'est que les développeurs ne savent plus comment ça marche.
Je parie que tu n'aimes pas non plus le garbage collector de Java ;-)
--
Pozzo - Et dire qu'on faisait des cgi en C il n'y a pas si longtemps...
C'est ça qui me broute profondément avec ce mécanisme des sessions PHP4, c'est que les développeurs ne savent plus comment ça marche.
Je parie que tu n'aimes pas non plus le garbage collector de Java ;-)
-- Pozzo - Et dire qu'on faisait des cgi en C il n'y a pas si longtemps...
John GALLET
C'est ça qui me broute profondément avec ce mécanisme des sessions PHP4, c'est que les développeurs ne savent plus comment ça marche.
Je parie que tu n'aimes pas non plus le garbage collector de Java ;-)
C'est pas difficile à parier. J'ai déjà raconté N fois l'anecdote des serveurs web de production d'un grand acteur de la e-finance qui restaient régulièrement totalement scotchés pendant 1,5 à 2 secondes de manière aléatoire, et que Sun a mis 2 jours à diagnostiquer (tout à faire correctement) comme le déclenchement du garbage collector java. C'est pas en C ou en C++ qu'on aurait eut le problème.
Pozzo - Et dire qu'on faisait des cgi en C il n'y a pas si longtemps...
Ca tombe bien, PHP est du CGI en C :-)
a++; JG
C'est ça qui me broute profondément avec ce mécanisme des sessions PHP4,
c'est que les développeurs ne savent plus comment ça marche.
Je parie que tu n'aimes pas non plus le garbage collector de Java ;-)
C'est pas difficile à parier. J'ai déjà raconté N fois l'anecdote des
serveurs web de production d'un grand acteur de la e-finance qui
restaient régulièrement totalement scotchés pendant 1,5 à 2 secondes de
manière aléatoire, et que Sun a mis 2 jours à diagnostiquer (tout à
faire correctement) comme le déclenchement du garbage collector java.
C'est pas en C ou en C++ qu'on aurait eut le problème.
Pozzo - Et dire qu'on faisait des cgi en C il n'y a pas si longtemps...
C'est ça qui me broute profondément avec ce mécanisme des sessions PHP4, c'est que les développeurs ne savent plus comment ça marche.
Je parie que tu n'aimes pas non plus le garbage collector de Java ;-)
C'est pas difficile à parier. J'ai déjà raconté N fois l'anecdote des serveurs web de production d'un grand acteur de la e-finance qui restaient régulièrement totalement scotchés pendant 1,5 à 2 secondes de manière aléatoire, et que Sun a mis 2 jours à diagnostiquer (tout à faire correctement) comme le déclenchement du garbage collector java. C'est pas en C ou en C++ qu'on aurait eut le problème.
Pozzo - Et dire qu'on faisait des cgi en C il n'y a pas si longtemps...
Ca tombe bien, PHP est du CGI en C :-)
a++; JG
Pozzo
John GALLET wrote:
Bref, halte aux conneries.
Ca me fait penser à la réponse "Vaste programme..." faite par de Gaulle à son aide de camp qui lui aurait dit "Mort aux cons !"
-- Pozzo - Hors sujet
John GALLET wrote:
Bref, halte aux conneries.
Ca me fait penser à la réponse "Vaste programme..." faite par de Gaulle
à son aide de camp qui lui aurait dit "Mort aux cons !"
Ca me fait penser à la réponse "Vaste programme..." faite par de Gaulle à son aide de camp qui lui aurait dit "Mort aux cons !"
-- Pozzo - Hors sujet
Michel Billaud
John GALLET writes:
Re,
Envoi d'un lien valide pendant X minutes (oh, une session !) permettant d'écraser le mot de passe actuel.
Effectivement, je vais certainement opter pour cette idée. Sur le principe de la session par contre, je me demande si le risque n'est pas la fermeture du navigateur par l'internaute (ou alors je n'ai pas compris la méthode).
Une session n'est pas nécessairement une donnée conservée dans un cookie... Le principe de la session, c'est de comparer une donnée reçue avec une donnée conservée côté serveur qui est associée à des droits d'accès aux ressoruces serveur. Donc si tu envoies un lien html dans le mail du style change_pass.php?authid345677890ABCDefgh, il suffit de vérifier que cet ID est présent dans, par exemple, une table de bases de données (ou même un fichier texte vu le peu d'accès concurrents, à la limite).
J'ai l'impression qu'on peut même se dispenser de stocker quoi que ce soit dans la base, il suffit que l'authid soit en fait un jeton contenant les informations nécessaires (identifiant utilisateur concerné, date limite de validité du jeton) crypté par le serveur.
MB
-- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
John GALLET <john.gallet@wanadoo.fr> writes:
Re,
Envoi d'un lien valide pendant X minutes (oh, une session !) permettant
d'écraser le mot de passe actuel.
Effectivement, je vais certainement opter pour cette idée. Sur le
principe de la session par contre, je me demande si le risque n'est pas
la fermeture du navigateur par l'internaute (ou alors je n'ai pas
compris la méthode).
Une session n'est pas nécessairement une donnée conservée dans un
cookie... Le principe de la session, c'est de comparer une donnée reçue
avec une donnée conservée côté serveur qui est associée à des droits
d'accès aux ressoruces serveur. Donc si tu envoies un lien html dans le
mail du style change_pass.php?authid345677890ABCDefgh, il suffit de
vérifier que cet ID est présent dans, par exemple, une table de bases de
données (ou même un fichier texte vu le peu d'accès concurrents, à la
limite).
J'ai l'impression qu'on peut même se dispenser de stocker quoi que ce soit dans la base,
il suffit que l'authid soit en fait un jeton contenant les informations nécessaires
(identifiant utilisateur concerné, date limite de validité du jeton)
crypté par le serveur.
MB
--
Michel BILLAUD billaud@labri.fr
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)
Envoi d'un lien valide pendant X minutes (oh, une session !) permettant d'écraser le mot de passe actuel.
Effectivement, je vais certainement opter pour cette idée. Sur le principe de la session par contre, je me demande si le risque n'est pas la fermeture du navigateur par l'internaute (ou alors je n'ai pas compris la méthode).
Une session n'est pas nécessairement une donnée conservée dans un cookie... Le principe de la session, c'est de comparer une donnée reçue avec une donnée conservée côté serveur qui est associée à des droits d'accès aux ressoruces serveur. Donc si tu envoies un lien html dans le mail du style change_pass.php?authid345677890ABCDefgh, il suffit de vérifier que cet ID est présent dans, par exemple, une table de bases de données (ou même un fichier texte vu le peu d'accès concurrents, à la limite).
J'ai l'impression qu'on peut même se dispenser de stocker quoi que ce soit dans la base, il suffit que l'authid soit en fait un jeton contenant les informations nécessaires (identifiant utilisateur concerné, date limite de validité du jeton) crypté par le serveur.
MB
-- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
John GALLET
J'ai l'impression qu'on peut même se dispenser de stocker quoi que ce soit dans la base, il suffit que l'authid soit en fait un jeton contenant les informations nécessaires (identifiant utilisateur concerné, date limite de validité du jeton) crypté par le serveur.
Tout dépend du niveau de secret associé aux données utilisées pour ce checksum, surtout sur du code open source(1). La date de validité est assez facile à deviner ou pifométriser avec suffisement de précision pour limiter les combinaisons et toutes les essayer dans le temps imparti. Si par "identifiant" on entend "login", c'est discutable. Si identifiant=loginresse email, on oublie. Si identifiant numérique en autoincrement on oublie aussi. Bref, oui sur sur le principe dès lors qu'on ne peut pas tout simplement faire du bruteforce parce qu'on limite les combinaisons possibles.
JG
J'ai l'impression qu'on peut même se dispenser de stocker quoi que ce soit dans la base,
il suffit que l'authid soit en fait un jeton contenant les informations nécessaires
(identifiant utilisateur concerné, date limite de validité du jeton)
crypté par le serveur.
Tout dépend du niveau de secret associé aux données utilisées pour ce
checksum, surtout sur du code open source(1). La date de validité est
assez facile à deviner ou pifométriser avec suffisement de précision
pour limiter les combinaisons et toutes les essayer dans le temps
imparti. Si par "identifiant" on entend "login", c'est discutable. Si
identifiant=loginresse email, on oublie. Si identifiant numérique en
autoincrement on oublie aussi. Bref, oui sur sur le principe dès lors
qu'on ne peut pas tout simplement faire du bruteforce parce qu'on limite
les combinaisons possibles.
J'ai l'impression qu'on peut même se dispenser de stocker quoi que ce soit dans la base, il suffit que l'authid soit en fait un jeton contenant les informations nécessaires (identifiant utilisateur concerné, date limite de validité du jeton) crypté par le serveur.
Tout dépend du niveau de secret associé aux données utilisées pour ce checksum, surtout sur du code open source(1). La date de validité est assez facile à deviner ou pifométriser avec suffisement de précision pour limiter les combinaisons et toutes les essayer dans le temps imparti. Si par "identifiant" on entend "login", c'est discutable. Si identifiant=loginresse email, on oublie. Si identifiant numérique en autoincrement on oublie aussi. Bref, oui sur sur le principe dès lors qu'on ne peut pas tout simplement faire du bruteforce parce qu'on limite les combinaisons possibles.
JG
Jean-Francois Ortolo
John GALLET wrote:
Re,
Donc tu ne touches à rien dans la table qui stocke les mots de passe, tu envoies un jeton d'autorisation sur un email réputé fiable, et tu attends. Si ce jeton est demandé pendant sa période de validité, tu fais l'update avec le nouveau mot de passe fournit, sinon... tu ne fais rien d'autre que la purge du jeton.
Bonjour Monsieur
Ok pour cette procédure d'update de password.
Juste une question: Celà vaut-il la peine, de faire une vérification de la complexité du password, au moment de sa saisie par le demandeur ?
Genre: Au moins un ou deux chiffres, et une ou deux lettres minuscules et une ou deux lettres majuscules.
Juste pour savoir ce que vous préconisez en ce qui concerne ce topic.
Merci beaucoup pour vos apports aux bonnes pratiques de programmation web.
Bien à vous.
Jean-François Ortolo
-- Visitez mon site gratuit donnant des Statistiques et des Historiques Graphiques sur les Courses de Chevaux: http://www.ortolojf-courses.com
John GALLET wrote:
Re,
Donc tu ne touches à rien dans la table qui stocke les mots de passe, tu
envoies un jeton d'autorisation sur un email réputé fiable, et tu
attends. Si ce jeton est demandé pendant sa période de validité, tu fais
l'update avec le nouveau mot de passe fournit, sinon... tu ne fais rien
d'autre que la purge du jeton.
Bonjour Monsieur
Ok pour cette procédure d'update de password.
Juste une question: Celà vaut-il la peine,
de faire une vérification de la complexité du password,
au moment de sa saisie par le demandeur ?
Genre: Au moins un ou deux chiffres,
et une ou deux lettres minuscules
et une ou deux lettres majuscules.
Juste pour savoir ce que vous préconisez
en ce qui concerne ce topic.
Merci beaucoup pour vos apports
aux bonnes pratiques de programmation web.
Bien à vous.
Jean-François Ortolo
--
Visitez mon site gratuit donnant des Statistiques
et des Historiques Graphiques sur les Courses de Chevaux:
http://www.ortolojf-courses.com
Donc tu ne touches à rien dans la table qui stocke les mots de passe, tu envoies un jeton d'autorisation sur un email réputé fiable, et tu attends. Si ce jeton est demandé pendant sa période de validité, tu fais l'update avec le nouveau mot de passe fournit, sinon... tu ne fais rien d'autre que la purge du jeton.
Bonjour Monsieur
Ok pour cette procédure d'update de password.
Juste une question: Celà vaut-il la peine, de faire une vérification de la complexité du password, au moment de sa saisie par le demandeur ?
Genre: Au moins un ou deux chiffres, et une ou deux lettres minuscules et une ou deux lettres majuscules.
Juste pour savoir ce que vous préconisez en ce qui concerne ce topic.
Merci beaucoup pour vos apports aux bonnes pratiques de programmation web.
Bien à vous.
Jean-François Ortolo
-- Visitez mon site gratuit donnant des Statistiques et des Historiques Graphiques sur les Courses de Chevaux: http://www.ortolojf-courses.com
