Travaillant comme bénévole ( développement html + php ) pour une
assoc, j'aurai besoin prochainement de mettre en place un processus
d'authentification classique ( pas de ssl, je sais pas faire, mais si
quelqu'un a des tuyaux... ), et donc avoir à enregistrer des
logins/passwords dans la bdd.
La solution bdd, est plus facile que celle de .htaccess, pour
automatiser les modifications des caractéristiques d'authentification.
J'ai toujours entendu dire, qu'il valait mieux enregistrer les
passwords cryptés en bdd, par mesure de sécurité.
Le blème, c'est que j'aurai donc besoin de pouvoir rappeler son
password par email, à toute personne enregistrée en faisant la demande.
Comment faire pour disposer du password réel, si je n'ai que le
password crypté, ou bien autre chose ?
Merci beaucoup de vos réponses.
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
Travaillant comme bénévole ( développement html + php ) pour une assoc, j'aurai besoin prochainement de mettre en place un processus d'authentification classique ( pas de ssl, je sais pas faire, mais si quelqu'un a des tuyaux... ), et donc avoir à enregistrer des logins/passwords dans la bdd.
La solution bdd, est plus facile que celle de .htaccess, pour automatiser les modifications des caractéristiques d'authentification.
J'ai toujours entendu dire, qu'il valait mieux enregistrer les passwords cryptés en bdd, par mesure de sécurité.
Le blème, c'est que j'aurai donc besoin de pouvoir rappeler son password par email, à toute personne enregistrée en faisant la demande.
Comment faire pour disposer du password réel, si je n'ai que le password crypté, ou bien autre chose ?
Merci beaucoup de vos réponses.
Jean-François Ortolo
Bonjour
Crypter les mots de passe est une bonne idée. Mais en général on utilise une fonction de hashage comme md5, ce qui veut dire qu'on ne peut pas faire l'opération inverse. Dans ce cas, si l'utilisateur ne se souvient plus du mot de passe, il faut lui en générer un aléatoire, quitte à le changer par la suite.
Bon courage
Jean-Francois Ortolo wrote:
Bonjour
Travaillant comme bénévole ( développement html + php ) pour une
assoc, j'aurai besoin prochainement de mettre en place un processus
d'authentification classique ( pas de ssl, je sais pas faire, mais si
quelqu'un a des tuyaux... ), et donc avoir à enregistrer des
logins/passwords dans la bdd.
La solution bdd, est plus facile que celle de .htaccess, pour
automatiser les modifications des caractéristiques d'authentification.
J'ai toujours entendu dire, qu'il valait mieux enregistrer les
passwords cryptés en bdd, par mesure de sécurité.
Le blème, c'est que j'aurai donc besoin de pouvoir rappeler son
password par email, à toute personne enregistrée en faisant la demande.
Comment faire pour disposer du password réel, si je n'ai que le
password crypté, ou bien autre chose ?
Merci beaucoup de vos réponses.
Jean-François Ortolo
Bonjour
Crypter les mots de passe est une bonne idée.
Mais en général on utilise une fonction de hashage comme md5, ce qui veut
dire qu'on ne peut pas faire l'opération inverse.
Dans ce cas, si l'utilisateur ne se souvient plus du mot de passe, il faut
lui en générer un aléatoire, quitte à le changer par la suite.
Travaillant comme bénévole ( développement html + php ) pour une assoc, j'aurai besoin prochainement de mettre en place un processus d'authentification classique ( pas de ssl, je sais pas faire, mais si quelqu'un a des tuyaux... ), et donc avoir à enregistrer des logins/passwords dans la bdd.
La solution bdd, est plus facile que celle de .htaccess, pour automatiser les modifications des caractéristiques d'authentification.
J'ai toujours entendu dire, qu'il valait mieux enregistrer les passwords cryptés en bdd, par mesure de sécurité.
Le blème, c'est que j'aurai donc besoin de pouvoir rappeler son password par email, à toute personne enregistrée en faisant la demande.
Comment faire pour disposer du password réel, si je n'ai que le password crypté, ou bien autre chose ?
Merci beaucoup de vos réponses.
Jean-François Ortolo
Bonjour
Crypter les mots de passe est une bonne idée. Mais en général on utilise une fonction de hashage comme md5, ce qui veut dire qu'on ne peut pas faire l'opération inverse. Dans ce cas, si l'utilisateur ne se souvient plus du mot de passe, il faut lui en générer un aléatoire, quitte à le changer par la suite.
Bon courage
P'tit Marcel
J'ai toujours entendu dire, qu'il valait mieux enregistrer les passwords cryptés en bdd, par mesure de sécurité. Le blème, c'est que j'aurai donc besoin de pouvoir rappeler son password par email, à toute personne enregistrée en faisant la demande. Comment faire pour disposer du password réel, si je n'ai que le password crypté, ou bien autre chose ?
On n'a pas le mot de passe en clair. Comme ça un siphonage de la base de données ne permettra pas d'usurper les identités.
Si un utilisateur oublie son mot de passe, le site peut lui proposer de regénérer un nouveau mot de passe temporaire envoyé par email. L'utilisateur se connecte avec ce mot de passe qu'il doit alors changer.
Dans tous les cas, le mot de passe est stocké avec un cryptage non inversible (genre md5 et champ en varchar32).
La vérification du mot de passe se fait par une requête genre :
"select count(*) as nb from utilisateur where login = '$login' and password = md5('$mot')" (cryptage réalisé par le SGBD s'il le permet)
ou bien "select count(*) as nb from utilisateur where login = '$login' and password = '".md5($mot)."'" (cryptage réalisé par php)
La mise à jour du mot de passe se fait par un "update utilisateur set password = '".md5($mot)."' where login ='$login'" ou bien en appelant la fonction md5 du sgbd.
il faut choisir au départ si le cryptage sera fait par php ou par la BD car les deux ne sont pas forcément identiques.
protège-toi des injections de code dans les requêtes SQL (addslashes touçatouça).
eça -- P'tit Marcel stats sur les forums modérés http://www.centrale-lyon.org/ng/
J'ai toujours entendu dire, qu'il valait mieux enregistrer les
passwords cryptés en bdd, par mesure de sécurité.
Le blème, c'est que j'aurai donc besoin de pouvoir rappeler son
password par email, à toute personne enregistrée en faisant la demande.
Comment faire pour disposer du password réel, si je n'ai que le
password crypté, ou bien autre chose ?
On n'a pas le mot de passe en clair. Comme ça un siphonage de la base de
données ne permettra pas d'usurper les identités.
Si un utilisateur oublie son mot de passe, le site peut lui proposer de
regénérer un nouveau mot de passe temporaire envoyé par email.
L'utilisateur se connecte avec ce mot de passe qu'il doit alors changer.
Dans tous les cas, le mot de passe est stocké avec un cryptage non
inversible (genre md5 et champ en varchar32).
La vérification du mot de passe se fait par une requête genre :
"select count(*) as nb from utilisateur where login = '$login' and
password = md5('$mot')"
(cryptage réalisé par le SGBD s'il le permet)
ou bien
"select count(*) as nb from utilisateur where login = '$login' and
password = '".md5($mot)."'"
(cryptage réalisé par php)
La mise à jour du mot de passe se fait par un "update utilisateur set
password = '".md5($mot)."' where login ='$login'" ou bien en appelant la
fonction md5 du sgbd.
il faut choisir au départ si le cryptage sera fait par php ou par la BD
car les deux ne sont pas forcément identiques.
protège-toi des injections de code dans les requêtes SQL (addslashes
touçatouça).
eça
--
P'tit Marcel
stats sur les forums modérés http://www.centrale-lyon.org/ng/
J'ai toujours entendu dire, qu'il valait mieux enregistrer les passwords cryptés en bdd, par mesure de sécurité. Le blème, c'est que j'aurai donc besoin de pouvoir rappeler son password par email, à toute personne enregistrée en faisant la demande. Comment faire pour disposer du password réel, si je n'ai que le password crypté, ou bien autre chose ?
On n'a pas le mot de passe en clair. Comme ça un siphonage de la base de données ne permettra pas d'usurper les identités.
Si un utilisateur oublie son mot de passe, le site peut lui proposer de regénérer un nouveau mot de passe temporaire envoyé par email. L'utilisateur se connecte avec ce mot de passe qu'il doit alors changer.
Dans tous les cas, le mot de passe est stocké avec un cryptage non inversible (genre md5 et champ en varchar32).
La vérification du mot de passe se fait par une requête genre :
"select count(*) as nb from utilisateur where login = '$login' and password = md5('$mot')" (cryptage réalisé par le SGBD s'il le permet)
ou bien "select count(*) as nb from utilisateur where login = '$login' and password = '".md5($mot)."'" (cryptage réalisé par php)
La mise à jour du mot de passe se fait par un "update utilisateur set password = '".md5($mot)."' where login ='$login'" ou bien en appelant la fonction md5 du sgbd.
il faut choisir au départ si le cryptage sera fait par php ou par la BD car les deux ne sont pas forcément identiques.
protège-toi des injections de code dans les requêtes SQL (addslashes touçatouça).
eça -- P'tit Marcel stats sur les forums modérés http://www.centrale-lyon.org/ng/
Jean-Francois Ortolo
P'tit Marcel wrote:
On n'a pas le mot de passe en clair. Comme ça un siphonage de la base de données ne permettra pas d'usurper les identités.
Si un utilisateur oublie son mot de passe, le site peut lui proposer de regénérer un nouveau mot de passe temporaire envoyé par email. L'utilisateur se connecte avec ce mot de passe qu'il doit alors changer.
il faut choisir au départ si le cryptage sera fait par php ou par la BD car les deux ne sont pas forcément identiques.
Merci beaucoup P'tit Marcel
Et... Laquelle des deux solutions, cryptage par md5() php, ou md5() MySQL, est la plus pérenne, au fur et à mesure des versions ?
Il me semblait, que Monsieur John Gallet préconisait le cryptage par la fonction de la base de données ?
Merci beaucoup aussi pour la suggestion de filtrage ad hoc des données envoyées à la base de données.
Je vais mettre des if(ereg()) partout, pour valider les expressions régulières correctes, et non pas filtrer celles incorrectes.
J'ai eu comme expression régulière Posix, pour valider une adresse email, celle-ci:
"[a-zA-Z0-9._%-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,4}"
Cette expression est-elle correcte, pour valider une adresse email ?
Le développement en vue, ne concerne que des francophones...
Merci beaucoup de ta réponse.
Amicalement.
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
P'tit Marcel wrote:
On n'a pas le mot de passe en clair. Comme ça un siphonage de la base de
données ne permettra pas d'usurper les identités.
Si un utilisateur oublie son mot de passe, le site peut lui proposer de
regénérer un nouveau mot de passe temporaire envoyé par email.
L'utilisateur se connecte avec ce mot de passe qu'il doit alors changer.
il faut choisir au départ si le cryptage sera fait par php ou par la BD
car les deux ne sont pas forcément identiques.
Merci beaucoup P'tit Marcel
Et... Laquelle des deux solutions, cryptage par md5() php, ou md5()
MySQL, est la plus pérenne, au fur et à mesure des versions ?
Il me semblait, que Monsieur John Gallet préconisait le cryptage par
la fonction de la base de données ?
Merci beaucoup aussi pour la suggestion de filtrage ad hoc des
données envoyées à la base de données.
Je vais mettre des if(ereg()) partout, pour valider les expressions
régulières correctes, et non pas filtrer celles incorrectes.
J'ai eu comme expression régulière Posix, pour valider une adresse
email, celle-ci:
"[a-zA-Z0-9._%-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,4}"
Cette expression est-elle correcte, pour valider une adresse email ?
Le développement en vue, ne concerne que des francophones...
Merci beaucoup de ta réponse.
Amicalement.
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
On n'a pas le mot de passe en clair. Comme ça un siphonage de la base de données ne permettra pas d'usurper les identités.
Si un utilisateur oublie son mot de passe, le site peut lui proposer de regénérer un nouveau mot de passe temporaire envoyé par email. L'utilisateur se connecte avec ce mot de passe qu'il doit alors changer.
il faut choisir au départ si le cryptage sera fait par php ou par la BD car les deux ne sont pas forcément identiques.
Merci beaucoup P'tit Marcel
Et... Laquelle des deux solutions, cryptage par md5() php, ou md5() MySQL, est la plus pérenne, au fur et à mesure des versions ?
Il me semblait, que Monsieur John Gallet préconisait le cryptage par la fonction de la base de données ?
Merci beaucoup aussi pour la suggestion de filtrage ad hoc des données envoyées à la base de données.
Je vais mettre des if(ereg()) partout, pour valider les expressions régulières correctes, et non pas filtrer celles incorrectes.
J'ai eu comme expression régulière Posix, pour valider une adresse email, celle-ci:
"[a-zA-Z0-9._%-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,4}"
Cette expression est-elle correcte, pour valider une adresse email ?
Le développement en vue, ne concerne que des francophones...
Merci beaucoup de ta réponse.
Amicalement.
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
Olivier Miakinen
[...] valider les expressions régulières correctes, et non pas filtrer celles incorrectes.
Excellente idée.
J'ai eu comme expression régulière Posix, pour valider une adresse email, celle-ci:
"[a-zA-Z0-9._%-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,4}"
Cette expression est-elle correcte, pour valider une adresse email ?
Elle est incorrecte, comme la plupart de celles qui sont proposées. Tu peux constater que mon adresse om+ sera refusée par l'expression, alors que cette adresse est valide. Par ailleurs des noms de domaine valides, tels que ceux du TLD museum, seront refusés aussi (voir <http://icom.museum/contactus_fr.html> par exemple).
Pour une expression correcte, voir la FAQ de ce groupe : <http://faqfclphp.free.fr/#rub5.3>.
[...] valider les expressions
régulières correctes, et non pas filtrer celles incorrectes.
Excellente idée.
J'ai eu comme expression régulière Posix, pour valider une adresse
email, celle-ci:
"[a-zA-Z0-9._%-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,4}"
Cette expression est-elle correcte, pour valider une adresse email ?
Elle est incorrecte, comme la plupart de celles qui sont proposées. Tu
peux constater que mon adresse om+news@miakinen.net sera refusée par
l'expression, alors que cette adresse est valide. Par ailleurs des noms
de domaine valides, tels que ceux du TLD museum, seront refusés aussi
(voir <http://icom.museum/contactus_fr.html> par exemple).
Pour une expression correcte, voir la FAQ de ce groupe :
<http://faqfclphp.free.fr/#rub5.3>.
[...] valider les expressions régulières correctes, et non pas filtrer celles incorrectes.
Excellente idée.
J'ai eu comme expression régulière Posix, pour valider une adresse email, celle-ci:
"[a-zA-Z0-9._%-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,4}"
Cette expression est-elle correcte, pour valider une adresse email ?
Elle est incorrecte, comme la plupart de celles qui sont proposées. Tu peux constater que mon adresse om+ sera refusée par l'expression, alors que cette adresse est valide. Par ailleurs des noms de domaine valides, tels que ceux du TLD museum, seront refusés aussi (voir <http://icom.museum/contactus_fr.html> par exemple).
Pour une expression correcte, voir la FAQ de ce groupe : <http://faqfclphp.free.fr/#rub5.3>.
Denis Beauregard
Le 17 Mar 2007 13:42:10 GMT, Jean-Francois Ortolo écrivait dans fr.comp.lang.php:
Et... Laquelle des deux solutions, cryptage par md5() php, ou md5() MySQL, est la plus pérenne, au fur et à mesure des versions ?
En théorie, c'est la même chose (c'est un algorithme).
Je viens de regarder mon propre code pour un cas similaire et j'insère dans la BDD avec le MD5 de SQL alors que je compare avec le md5 de PHP.
Cette expression est-elle correcte, pour valider une adresse email ?
Je pense que la façon la plus simple de valider une adresse est de demander au nouvel abonné de confirmer en se connectant.
Mais on peut aussi couper au niveau du @ et s'assurer que le nom de domaine existe.
Denis
Le 17 Mar 2007 13:42:10 GMT, Jean-Francois Ortolo
<ortolo.jeanfrancois.no_spam@free.fr.invalid> écrivait dans
fr.comp.lang.php:
Et... Laquelle des deux solutions, cryptage par md5() php, ou md5()
MySQL, est la plus pérenne, au fur et à mesure des versions ?
En théorie, c'est la même chose (c'est un algorithme).
Je viens de regarder mon propre code pour un cas similaire et j'insère
dans la BDD avec le MD5 de SQL alors que je compare avec le md5 de
PHP.
Cette expression est-elle correcte, pour valider une adresse email ?
Je pense que la façon la plus simple de valider une adresse est de
demander au nouvel abonné de confirmer en se connectant.
Mais on peut aussi couper au niveau du @ et s'assurer que le nom de
domaine existe.
Le 17 Mar 2007 13:42:10 GMT, Jean-Francois Ortolo écrivait dans fr.comp.lang.php:
Et... Laquelle des deux solutions, cryptage par md5() php, ou md5() MySQL, est la plus pérenne, au fur et à mesure des versions ?
En théorie, c'est la même chose (c'est un algorithme).
Je viens de regarder mon propre code pour un cas similaire et j'insère dans la BDD avec le MD5 de SQL alors que je compare avec le md5 de PHP.
Cette expression est-elle correcte, pour valider une adresse email ?
Je pense que la façon la plus simple de valider une adresse est de demander au nouvel abonné de confirmer en se connectant.
Mais on peut aussi couper au niveau du @ et s'assurer que le nom de domaine existe.
Denis
Jean-Francois Ortolo
Olivier Miakinen wrote:
Elle est incorrecte, comme la plupart de celles qui sont proposées. Tu peux constater que mon adresse om+ sera refusée par l'expression, alors que cette adresse est valide. Par ailleurs des noms de domaine valides, tels que ceux du TLD museum, seront refusés aussi (voir <http://icom.museum/contactus_fr.html> par exemple).
Pour une expression correcte, voir la FAQ de ce groupe : <http://faqfclphp.free.fr/#rub5.3>.
Bonjour Monsieur
Merci beaucoup pour votre lien.
Je pense que le premier exemple donné, ( avec $ltext et $rtext ), conviendra particulièrement à mes besoins.
J'ai juste à présenter un formulaire d'envoi de mail à mon grand chef sioux ce soir... Je cours revoir le PHP Manual, il me semble que le traitement de l'enveloppe d'adresse email de retour ( en cas de bounce ), n'est pas le même suivant que le système hôte est Windows ou Unix/Linux.
Merci beaucoup. Amicalement.
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
Olivier Miakinen wrote:
Elle est incorrecte, comme la plupart de celles qui sont proposées. Tu
peux constater que mon adresse om+news@miakinen.net sera refusée par
l'expression, alors que cette adresse est valide. Par ailleurs des noms
de domaine valides, tels que ceux du TLD museum, seront refusés aussi
(voir <http://icom.museum/contactus_fr.html> par exemple).
Pour une expression correcte, voir la FAQ de ce groupe :
<http://faqfclphp.free.fr/#rub5.3>.
Bonjour Monsieur
Merci beaucoup pour votre lien.
Je pense que le premier exemple donné, ( avec $ltext et $rtext ),
conviendra particulièrement à mes besoins.
J'ai juste à présenter un formulaire d'envoi de mail à mon grand chef
sioux ce soir... Je cours revoir le PHP Manual, il me semble que le
traitement de l'enveloppe d'adresse email de retour ( en cas de bounce
), n'est pas le même suivant que le système hôte est Windows ou Unix/Linux.
Merci beaucoup.
Amicalement.
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
Elle est incorrecte, comme la plupart de celles qui sont proposées. Tu peux constater que mon adresse om+ sera refusée par l'expression, alors que cette adresse est valide. Par ailleurs des noms de domaine valides, tels que ceux du TLD museum, seront refusés aussi (voir <http://icom.museum/contactus_fr.html> par exemple).
Pour une expression correcte, voir la FAQ de ce groupe : <http://faqfclphp.free.fr/#rub5.3>.
Bonjour Monsieur
Merci beaucoup pour votre lien.
Je pense que le premier exemple donné, ( avec $ltext et $rtext ), conviendra particulièrement à mes besoins.
J'ai juste à présenter un formulaire d'envoi de mail à mon grand chef sioux ce soir... Je cours revoir le PHP Manual, il me semble que le traitement de l'enveloppe d'adresse email de retour ( en cas de bounce ), n'est pas le même suivant que le système hôte est Windows ou Unix/Linux.
Merci beaucoup. Amicalement.
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
Thief13
Crypter les mots de passe est une bonne idée. Mais en général on utilise une fonction de hashage comme md5, ce qui veut dire qu'on ne peut pas faire l'opération inverse.
Et cela est préférable, comme ça, ci quelqu'un arrive à passer un system du genre "répondre à la question secrete" comme un nouveau mot de passe est généré, le vraix possésseur du compte se rend bien compte qu'il y a un probleme puisqu'il n'arrivera plus à se connecter avec son mot de passe
Crypter les mots de passe est une bonne idée.
Mais en général on utilise une fonction de hashage comme md5, ce qui veut
dire qu'on ne peut pas faire l'opération inverse.
Et cela est préférable, comme ça, ci quelqu'un arrive à passer un system
du genre "répondre à la question secrete" comme un nouveau mot de passe
est généré, le vraix possésseur du compte se rend bien compte qu'il y a
un probleme puisqu'il n'arrivera plus à se connecter avec son mot de passe
Crypter les mots de passe est une bonne idée. Mais en général on utilise une fonction de hashage comme md5, ce qui veut dire qu'on ne peut pas faire l'opération inverse.
Et cela est préférable, comme ça, ci quelqu'un arrive à passer un system du genre "répondre à la question secrete" comme un nouveau mot de passe est généré, le vraix possésseur du compte se rend bien compte qu'il y a un probleme puisqu'il n'arrivera plus à se connecter avec son mot de passe
P'tit Marcel
Et... Laquelle des deux solutions, cryptage par md5() php, ou md5() MySQL, est la plus pérenne, au fur et à mesure des versions ?
J'utilise en général la fonction intégrée dans MySQL puisque la donnée est stockée dans MySQL. Cela assure en plus de pouvoir utiliser la donnée avec un autre langage que php.
et pour répondre à Denis, j'ai un vague souvenir qu'il est arrivé par accident que le md5 de php ne soit pas strictement interchangeable avec celui de MySQL. Il faudrait rechercher dans l'historique de ce forum. À moins que je confonde avec un autre fonction genre crypt...
-- P'tit Marcel stats sur les forums modérés http://www.centrale-lyon.org/ng/
Et... Laquelle des deux solutions, cryptage par md5() php, ou md5()
MySQL, est la plus pérenne, au fur et à mesure des versions ?
J'utilise en général la fonction intégrée dans MySQL puisque la donnée
est stockée dans MySQL. Cela assure en plus de pouvoir utiliser la
donnée avec un autre langage que php.
et pour répondre à Denis, j'ai un vague souvenir qu'il est arrivé par
accident que le md5 de php ne soit pas strictement interchangeable avec
celui de MySQL. Il faudrait rechercher dans l'historique de ce forum. À
moins que je confonde avec un autre fonction genre crypt...
--
P'tit Marcel
stats sur les forums modérés http://www.centrale-lyon.org/ng/
Et... Laquelle des deux solutions, cryptage par md5() php, ou md5() MySQL, est la plus pérenne, au fur et à mesure des versions ?
J'utilise en général la fonction intégrée dans MySQL puisque la donnée est stockée dans MySQL. Cela assure en plus de pouvoir utiliser la donnée avec un autre langage que php.
et pour répondre à Denis, j'ai un vague souvenir qu'il est arrivé par accident que le md5 de php ne soit pas strictement interchangeable avec celui de MySQL. Il faudrait rechercher dans l'historique de ce forum. À moins que je confonde avec un autre fonction genre crypt...
-- P'tit Marcel stats sur les forums modérés http://www.centrale-lyon.org/ng/
Patrick Mevzek
Dans tous les cas, le mot de passe est stocké avec un cryptage non inversible (genre md5 et champ en varchar32).
Mauvais conseil, en tout cas qui ne va pas jusqu'au bout. Stocker md5(pass) plutôt que pass n'améliore la sécurité que de manière marginale. Il y a des dictionnaires de précalculs de MD5 qui pourraient être utilisés pour retrouver le mot de passe trivialement.
Il faut donc, certes utiliser un hachage cryptographique (et pour le coup MD5 n'est plus recommandé), mais le perturber avec une graine. Il faut donc choisir une chaîne aléatoire, au moins aussi longue que la taille de l'espace de sortie de la fonction cryptographique utilisée, différente à chaque fois, et stockée donc en clair dans la base.
On peut aussi utiliser le cumul d'une constante secrete connue uniquement du code (voire connue uniquement du SGBDR qui peut faire le calcul via une procédure stockée) et d'une valeur spécifique à chaque compte, stockée en clair dans la base et difficilement devinable (comme la date de création du compte avec suffisamment de précisions).
Ainsi cette graine assure que deux mots de passe identique de deux comptes différents donneront des résultats différent, et que ce qu'on met en entrée de la fonction cryptographique ne se retrouvera jamais dans aucun dictionnaire...
Plus généralement, si on en croit les experts (Schneier), une bonne façon de faire est la suivante : - soit x[0]=0 - on calcul x[i] ainsi : x[i]=HMAC(x[i-1] || motdepasse || graine) avec HMAC utilisant une fonction cryptographique comme SHA-256 (en tout cas quelque chose qui donne 256 bits, au moins) et || note la concaténation - on arrête à l'itération r et on stocke dans la base x[r] avec r choisi de telle façon que l'ensemble du calcul prenne entre 0.2 et 1 seconde.
protège-toi des injections de code dans les requêtes SQL (addslashes touçatouça).
De nouveau un mauvais conseil : on peut réussir des injections SQL avec autant d'addslashes que vous voulez dans le code. Le problème des injections SQL n'est PAS un problème de guillemet.
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Dans tous les cas, le mot de passe est stocké avec un cryptage non
inversible (genre md5 et champ en varchar32).
Mauvais conseil, en tout cas qui ne va pas jusqu'au bout.
Stocker md5(pass) plutôt que pass n'améliore la sécurité que de
manière marginale. Il y a des dictionnaires de précalculs de MD5 qui
pourraient être utilisés pour retrouver le mot de passe trivialement.
Il faut donc, certes utiliser un hachage cryptographique (et pour le coup
MD5 n'est plus recommandé), mais le perturber avec une graine.
Il faut donc choisir une chaîne aléatoire, au moins aussi longue que la
taille de l'espace de sortie de la fonction cryptographique utilisée,
différente à chaque fois, et stockée donc en clair dans la base.
On peut aussi utiliser le cumul d'une constante secrete connue uniquement
du code (voire connue uniquement du SGBDR qui peut faire le calcul via une
procédure stockée) et d'une valeur spécifique à chaque compte,
stockée en clair dans la base et difficilement devinable (comme la date
de création du compte avec suffisamment de précisions).
Ainsi cette graine assure que deux mots de passe identique de deux comptes
différents donneront des résultats différent, et que ce qu'on met en
entrée de la fonction cryptographique ne se retrouvera jamais dans aucun
dictionnaire...
Plus généralement, si on en croit les experts (Schneier), une bonne
façon de faire est la suivante :
- soit x[0]=0
- on calcul x[i] ainsi :
x[i]=HMAC(x[i-1] || motdepasse || graine)
avec HMAC utilisant une fonction cryptographique comme SHA-256
(en tout cas quelque chose qui donne 256 bits, au moins)
et || note la concaténation
- on arrête à l'itération r et on stocke dans la base x[r] avec r
choisi de telle façon que l'ensemble du calcul prenne entre 0.2 et 1
seconde.
protège-toi des injections de code dans les requêtes SQL (addslashes
touçatouça).
De nouveau un mauvais conseil : on peut réussir des injections SQL avec
autant d'addslashes que vous voulez dans le code.
Le problème des injections SQL n'est PAS un problème de guillemet.
--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Dans tous les cas, le mot de passe est stocké avec un cryptage non inversible (genre md5 et champ en varchar32).
Mauvais conseil, en tout cas qui ne va pas jusqu'au bout. Stocker md5(pass) plutôt que pass n'améliore la sécurité que de manière marginale. Il y a des dictionnaires de précalculs de MD5 qui pourraient être utilisés pour retrouver le mot de passe trivialement.
Il faut donc, certes utiliser un hachage cryptographique (et pour le coup MD5 n'est plus recommandé), mais le perturber avec une graine. Il faut donc choisir une chaîne aléatoire, au moins aussi longue que la taille de l'espace de sortie de la fonction cryptographique utilisée, différente à chaque fois, et stockée donc en clair dans la base.
On peut aussi utiliser le cumul d'une constante secrete connue uniquement du code (voire connue uniquement du SGBDR qui peut faire le calcul via une procédure stockée) et d'une valeur spécifique à chaque compte, stockée en clair dans la base et difficilement devinable (comme la date de création du compte avec suffisamment de précisions).
Ainsi cette graine assure que deux mots de passe identique de deux comptes différents donneront des résultats différent, et que ce qu'on met en entrée de la fonction cryptographique ne se retrouvera jamais dans aucun dictionnaire...
Plus généralement, si on en croit les experts (Schneier), une bonne façon de faire est la suivante : - soit x[0]=0 - on calcul x[i] ainsi : x[i]=HMAC(x[i-1] || motdepasse || graine) avec HMAC utilisant une fonction cryptographique comme SHA-256 (en tout cas quelque chose qui donne 256 bits, au moins) et || note la concaténation - on arrête à l'itération r et on stocke dans la base x[r] avec r choisi de telle façon que l'ensemble du calcul prenne entre 0.2 et 1 seconde.
protège-toi des injections de code dans les requêtes SQL (addslashes touçatouça).
De nouveau un mauvais conseil : on peut réussir des injections SQL avec autant d'addslashes que vous voulez dans le code. Le problème des injections SQL n'est PAS un problème de guillemet.
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
John GALLET
et pour répondre à Denis, j'ai un vague souvenir qu'il est arrivé par accident que le md5 de php ne soit pas strictement interchangeable avec celui de MySQL. Il faudrait rechercher dans l'historique de ce forum. À moins que je confonde avec un autre fonction genre crypt...
Tu confonds probablement avec la fonction PASSWORD( ) de mysql qui utilisait MD5 et qui est passée à SHA1 (et donc on peut utiliser OLD_PASSWORD() pour l'ancien). Ca fout le bordel quel que chose de correct si tu as un vieux client mysql avec une nouvelle installation.
Le but de MD5 c'est bien d'être portable. Il y a des gags quand même (je me souviens d'un truc rigolo sur solaris) mais c'est assez limité.
JG
et pour répondre à Denis, j'ai un vague souvenir qu'il est arrivé par
accident que le md5 de php ne soit pas strictement interchangeable avec
celui de MySQL. Il faudrait rechercher dans l'historique de ce forum. À
moins que je confonde avec un autre fonction genre crypt...
Tu confonds probablement avec la fonction PASSWORD( ) de mysql qui
utilisait MD5 et qui est passée à SHA1 (et donc on peut utiliser
OLD_PASSWORD() pour l'ancien). Ca fout le bordel quel que chose de correct
si tu as un vieux client mysql avec une nouvelle installation.
Le but de MD5 c'est bien d'être portable. Il y a des gags quand même (je
me souviens d'un truc rigolo sur solaris) mais c'est assez limité.
et pour répondre à Denis, j'ai un vague souvenir qu'il est arrivé par accident que le md5 de php ne soit pas strictement interchangeable avec celui de MySQL. Il faudrait rechercher dans l'historique de ce forum. À moins que je confonde avec un autre fonction genre crypt...
Tu confonds probablement avec la fonction PASSWORD( ) de mysql qui utilisait MD5 et qui est passée à SHA1 (et donc on peut utiliser OLD_PASSWORD() pour l'ancien). Ca fout le bordel quel que chose de correct si tu as un vieux client mysql avec une nouvelle installation.
Le but de MD5 c'est bien d'être portable. Il y a des gags quand même (je me souviens d'un truc rigolo sur solaris) mais c'est assez limité.
