Enregistrement de passwords en bdd...

[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

[dric-li]

Post by 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

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

[Thief13]

Post by dric-li
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]

Post by Jean-Francois Ortolo
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

[Jean-Francois Ortolo]

Post by P'tit Marcel
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

[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
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+***@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>.

[Jean-Francois Ortolo]

Post by Olivier Miakinen
Elle est incorrecte, comme la plupart de celles qui sont proposées. Tu
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).
<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

[Denis Beauregard]

Le 17 Mar 2007 13:42:10 GMT, Jean-Francois Ortolo

Post by Jean-Francois Ortolo
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.

Post by Jean-Francois Ortolo
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

[P'tit Marcel]

Post by Jean-Francois Ortolo
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...

[John GALLET]

Post by P'tit Marcel
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

[Patrick Mevzek]

Post by P'tit Marcel
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.

Post by P'tit Marcel
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.

[John GALLET]

Bonjour,

Post by Jean-Francois Ortolo
J'ai toujours entendu dire, qu'il valait mieux enregistrer les
passwords cryptés en bdd, par mesure de sécurité.

Du moment que tu restes bien conscient que c'est le niveau zéro de la
sécurité en question et que toute personne qui aura accès à la donnée
chiffrée pourra la déchiffrer en un temps raisonnable (rainbow tables, The
Ripper, tout ça), tu peux [perdre ton temps à| enrichir tes connaissances
en] chiffrant les mots de passe en base.

Post by Jean-Francois Ortolo
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.

On peut aussi lui envoyer une session temporaire sur une adresse email
réputée fiable pour en changer. La faille est reportée à l'accès à cette
adresse et aux failles de ton site permettant d'écraser cette adresse.

Post by Jean-Francois Ortolo
Comment faire pour disposer du password réel, si je n'ai que le
password crypté, ou bien autre chose ?

Ne pas le faire :-)

JG

[Christophe Meresse]

Post by John GALLET
Bonjour,

Post by Jean-Francois Ortolo
J'ai toujours entendu dire, qu'il valait mieux enregistrer les
passwords cryptés en bdd, par mesure de sécurité.

Du moment que tu restes bien conscient que c'est le niveau zéro de la
sécurité en question et que toute personne qui aura accès à la donnée
chiffrée pourra la déchiffrer en un temps raisonnable (rainbow tables, The
Ripper, tout ça), tu peux [perdre ton temps à| enrichir tes connaissances
en] chiffrant les mots de passe en base.

Je dois pas bien comprendre, tu suggère de laisser les passwords en
clair dans la base ?

C'est certain que quelqu'un ayant acces à la base va pouvoir les
décripter mais tout de même, en temps qu'admin ayant accès à la base,
je n'ai pas envie de voir les password de mes utilisateurs en clair.
C'est aussi un peu une question déontonlogique... non ? :)

Christophe

[Thomas Labourdette]

Post by Christophe Meresse

Post by John GALLET
Bonjour,

Post by Jean-Francois Ortolo
J'ai toujours entendu dire, qu'il valait mieux enregistrer les
passwords cryptés en bdd, par mesure de sécurité.

Du moment que tu restes bien conscient que c'est le niveau zéro de la
sécurité en question et que toute personne qui aura accès à la donnée
chiffrée pourra la déchiffrer en un temps raisonnable (rainbow tables,
The Ripper, tout ça), tu peux [perdre ton temps à| enrichir tes
connaissances en] chiffrant les mots de passe en base.

Je dois pas bien comprendre, tu suggère de laisser les passwords en
clair dans la base ?
C'est certain que quelqu'un ayant acces à la base va pouvoir les
décripter mais tout de même, en temps qu'admin ayant accès à la base,

Que tes passwords soient en clair ou chiffrés, soit quelqu'un arrive à
accéder à la base et il pourra les déchiffrer/lire soit l'accès est
suffisement sécurisé et que les passwords soit chiffrés ou en clair ne
change pas grand chose.

@+

[Christophe Meresse]

Post by Thomas Labourdette

Post by Christophe Meresse

Post by John GALLET
Bonjour,

Post by Jean-Francois Ortolo
J'ai toujours entendu dire, qu'il valait mieux enregistrer les
passwords cryptés en bdd, par mesure de sécurité.

Du moment que tu restes bien conscient que c'est le niveau zéro de la
sécurité en question et que toute personne qui aura accès à la donnée
chiffrée pourra la déchiffrer en un temps raisonnable (rainbow tables,
The Ripper, tout ça), tu peux [perdre ton temps à| enrichir tes
connaissances en] chiffrant les mots de passe en base.

Je dois pas bien comprendre, tu suggère de laisser les passwords en
clair dans la base ?
C'est certain que quelqu'un ayant acces à la base va pouvoir les
décripter mais tout de même, en temps qu'admin ayant accès à la base,

Que tes passwords soient en clair ou chiffrés, soit quelqu'un arrive à
accéder à la base et il pourra les déchiffrer/lire soit l'accès est
suffisement sécurisé et que les passwords soit chiffrés ou en clair ne
change pas grand chose.

C'est là ou je ne suis pas d'accord et ce que j'essayais d'expliquer
plus haut. En temps qu'administrateur ayant acces à la base, j'aurais
la visibilité sur les passwords et à la place d'une utilisateur de la
base, je n'aurais pas envie que l'administrateur puisse voir mon
password en clair.

A+
Christophe

[Thomas Labourdette]

Post by Christophe Meresse

Post by Thomas Labourdette
Que tes passwords soient en clair ou chiffrés, soit quelqu'un arrive à
accéder à la base et il pourra les déchiffrer/lire soit l'accès est
suffisement sécurisé et que les passwords soit chiffrés ou en clair ne
change pas grand chose.

C'est là ou je ne suis pas d'accord et ce que j'essayais d'expliquer
plus haut. En temps qu'administrateur ayant acces à la base, j'aurais
la visibilité sur les passwords et à la place d'une utilisateur de la
base, je n'aurais pas envie que l'administrateur puisse voir mon
password en clair.

En temps qu'administrateur, rien ne t'empêche de jouer avec John The Ripper
ou autres.

De plus, à moins que la seule information concernant l'utilisateur ne soit
le mot de passe, tu a aussi accès à toutes les informations le concernant
(à moins de tout stocker chiffré). Ce qui, pour un utilisateur, pourrait
être plus embêtant qu'un simple mot de passe.

Maintenant c'est toi qui est à même de juger ce que tu veux faire.

@+

[John GALLET]

Post by Christophe Meresse
Je dois pas bien comprendre, tu suggère de laisser les passwords en
clair dans la base ?

Je ne le suggère pas, je le laisse à l'appréciation du niveau de sécurité
requis pour l'application. Mais je ne vois pas en quoi ce serait
impossible. En revanche ce sur quoi j'insiste lourdement c'est que pour
une application qui doit être fortement sécurisée, chiffrer les mots de
passe n'est *en rien suffisant* il est *plus important* d'en empêcher
l'accès aux personnes non autorisées (et dès lors le chiffrage perd de son
intérêt).

Post by Christophe Meresse
C'est certain que quelqu'un ayant acces à la base va pouvoir les
décripter mais tout de même, en temps qu'admin ayant accès à la base,
je n'ai pas envie de voir les password de mes utilisateurs en clair.

Facile, il suffit de ne pas les regarder ;-)

Post by Christophe Meresse
C'est aussi un peu une question déontonlogique... non ? :)

En tant que root de moult machines, je peux lire les correspondances mail
privées de moult utilisateurs. Libre à moi de ne pas le faire (comme si
j'avais que ça à f...)

JG