Enregistrement de passwords en bdd...

Le
Jean-Francois Ortolo
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

--
Visitez mon site gratuit donnant des Statistiques
et des Historiques Graphiques sur les Courses de Chevaux:
http://www.ortolojf-courses.com
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
dric-li
Le #73523
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.

Bon courage

P'tit Marcel
Le #73524
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
Le #73268
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

Olivier Miakinen
Le #73266

[...] 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
Pour une expression correcte, voir la FAQ de ce groupe :

Denis Beauregard
Le #73262
Le 17 Mar 2007 13:42:10 GMT, Jean-Francois Ortolo
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
Le #73263
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
Pour une expression correcte, voir la FAQ de ce groupe :



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
Le #72989

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
Le #72987
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
Le #72984
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
Dépêches sur le nommage
John GALLET
Le #71889
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

Publicité
Poster une réponse
Anonyme