Bonjour,
 
 Pour l'instant je développe en local avec Wamp en php.
 
 Je réalise un script d'identification en php ou le client se log de façon classique avec un login et un mot de passe. Mais ceci dans le but de récupérer des paramètres de connexion à une base Mysql ou sont stockées des mesures qui sont propres à chaque organisme.
 
 Les données d'identification sont stockées dans une base avec une table "clients" (login_du_client/pwd_du_client/adressse_serveur_Mysql/nom_base_Mysql/login_Mysql/pwd_Mysql). Chaque base de données à ainsi un (ou plusieurs) utilisateur(s) avec des privilèges définis et chaque client ou groupe de clients à sa base bien à lui quand elle est stockée sur le même serveur.
 
 Quand le client s'identifie sur mon site, si le couple (login_du_client,pwd_du_client) est correcte je récupère les paramètres de connexion à sa base Mysql pour ouvrir une connexion permanente. Ce qui m'ennuie, c'est que je suis obligé de stocker "pwd_Mysql" en clair dans la table "clients". Alors que ceci sont stockés crypté (par PASSWORD()) dans Mysql, c'est gênant niveau sécurité...
 
Je ne vois pas trop comment faire autrement, c'est peut-être la façon de proceder qui n'est pas bonne.
 
Si vous avez des idées, une autre façon de procéder, cela m'intéresse.
 
merci

faut hasher le mot de passe
En md5 par exemple
 
Dans ta base, tu mets md5($ton_password) à la place $ton_password
 
md5() est une fonction php. Elle existe en SQL, mais tu t'exposerais aux injections.
 
Et quand tu veux vérifier l'identité, tu compares le hash qui est dans ta base, avec la valeur hashée du mot qu'a entré l'utilisateur.
 
Si c'est le même mot de passe, alors les deux valeurs de hash sont les mêmes
 
De cette manière, si le pirate à accès aux mots de passe, il ne pourra pas les utiliser, puisque la procédure compare des valeurs hashées (en effet, md5(md5(ton_password)) != md5(ton_password) )
 
 
 
D'après mes souvenirs, le sha1 est considéré de nos jours comme plus sûr que md5, mais ca reste pas mal de la branlette.

 
En effet  

fail

merci Pascal
 
Pas sûr d'avoir tout compris ou qu'on parle de la même chose.
Quand je crée un utilisateur pour une base, je rentre md5($ton_password ), qui sera stocké par mysql en PASSWORD(md5($ton_password )).
et dans la table "clients" je stock md5($pwd_mysql).
ça revient un peu au même qu'un pwd en clair non ?
 
bon, je vois ça demain. la nuit porte conseil !
encore merci pour ton aide.

tu stockes le md5 dans un CHAR(32)

Une empreinte md5 est toujours une chaine alphanumérique de 32 caractères.
 
Après avoir géré tout l'aspect sécurité dans tes variables (htmlentities & cie)
 

$query = 'INSERT INTO clients(pseudo,password,telephone,adresse) VALUES("'.$pseudo.'","'.md5($password).'","'.$telephone.'","'.$adresse.'" )';
mysql_query($query);

 
 
et pour s'identifier :
 

$query = 'SELECT id,pseudo, telephone, adresse FROM clients WHERE pseudo="'.$pseudo.'" AND password="'.md5($password).'"';
$result = mysql_query($query);
if ($data = mysql_fetch_assoc($result))
{
   // Connecté !
}
else
{
   // Echec de la connexion !
}

Finalement je crois qu'on ne parle pas de la même chose. Le code servant à s'identifier je connais et je le pratique. Mon pb c'est le stockage et la récupération du mot de passe d'accès à une base Mysql pas celui pour le login du client.

Si tu hashes le mdp, c'est pas réversible (ou alors avec des rainbow tables, et encore, c'est pas gagné). Donc si le user a perdu son mdp, ben faut lui en regénérer un.
 
Edit : perso, je trouve ce système plus fiable, car ça garantit au suer que son mdp ne pourra pas être volé et ça protège du sql injection pour la phase d'authentification. Dans mes applis, je fais même le md5 avec du javascript comme ça les login/mdp ne sont pas envoyés au serveur en clair.

 
   
 
Tu te rends compte que tu annihiles complètement ta protection ?
 
Le pirate qui récupère le mot de passe hashé qui est dans la base, n'aura plus qu'à se logger en passant à travers ton script javascript  
 
 
@berlo : Sinon, en effet, tu ne pourras plus récupérer le mot de passe.
Il faut faire un script qui renvoie un mail à l'utilisateur, contenant un lien qui lui permettra de recréer son mot de passe.

oups, double fail  

 
Certes, il pourra se logguer mais ne connaîtra pas le vrai mdp. S'il est capable de choper le hash md5 durant la connexion client/serveur, il est tout autant capable de choper le mdp en clair si je faisais le md5 côte serveur Donc j'annihile rien du tout.  
Et comme c'est pas le formulaire saisi par le user qui est envoyé au serveur mais un form caché qui va contenir le hash md5 du premier form, ben si le suer désactive JS, y'a rien qui part au serveur Donc pas de risque d'envoi du mdp en clair...

Oui mais il pourra aussi se logguer avec n'importe quel utilisateur dans le cas où il aurait accès au contenu de la base de données. Pour protéger les connexions, et notamment les échanges de mots de passes, c'est SSL ou rien d'autre ! Et puis côté accessibilité, on repassera...

 
Ben si qq'un a accès au contenu de la BD, que le mdp soit crypté ou pas, hashé ou pas, il pourra se connecter
 
Pour protéger les connexions efficacement, je suis bien d'accords que c'est SSL. Sauf que mon appli est un petit intranet d'un service accessible uniquement depuis l'entreprise. Pour l'accessibilité, je suis bien d'accord aussi que c'est pas top, mais n'ayant aucun utilisateur handicapé (visuel ou moteur) et que c'est pas prêt d'en avoir, je ne me suis pas pris al tête avec ça...

Sous entendu que tu fais tout le temps ça, quelque soit le contexte.
Maintenant, pour un contexte spécifique je veux bien reconnaître que ce peut être envisageable.

 
C'est grave.
Un form caché ne protège rien. Il est juste caché.
Un script javascript est facilement remplaçable coté client.
 
Si tu fais ton md5 coté client, le vrai mot de passe, celui que l'on compare, sera en réalité la valeur hashée du mot de passe original.
 
Si j'ai le contenu de ta table "user", il me suffit de valider ton formulaire de login en remplacant ton script qui le passe en md5, par un script qui ne fait rien du tout !
Du coup, le serveur reçoit le mot de passe, le compare, et    
 
 
 
Dans le cas que je propose, même si le pirate détient la table "user", il ne pourra pas se connecter, car le serveur attendra le mot de passe réel, qu'il hashera, et comparera avec l'empreinte qui est dans la base.
Connaitre la valeur hashée n'a aucun intéret pour le pirate (à part si le mot de passe est trop simple, auquel cas le déhashage se fait en 5min)

Grain de sel, ça complique suffisamment les choses pour être décourageant.

perso j'ai du mal à comprendre l'intérêt du pré-hash en JS suffit de récupérer le hash et de l'envoyer par POST soit même et c'est pareil ?

 
Je pense que l'idée est de se protéger du sniffing.
Mais ca ne protège rien du tout, puisqu'il devient sans intéret de connaitre le password original, son empreinte étant suffisante...
 
<metaphore surpuissante style="comprendra:qui-pourra;">
C'est un peu comme si tu avais un bouclier, et qu'en plein combat tu le mettais au dessus de ta tête pour te protéger de la pluie.
</metaphore surpuissante>

ouais

J'ai l'impression qu'on s'égare là. , je vois pas trop l'intérêt du MD5/JS non plus, si le hash est récupéré ça revient au même que d'avoir le mot de passe en clair.

Le risque peut être limité par les droits des comptes attribué sur les tables. Bon, c'est sûr que si la personne parvient à obtenir le compte root Mysql et que toutes les bases sont sur ce serveur c'est mort.

Dans mon cas il y a plusieurs BD, la connexion à la BD d'identification des membres se fait avec un compte user minimal (juste SELECT) sur cette table uniquement. Ce compte ne peux pas se connecter aux BD des différents clients.

le soucis est que si les mots de passe d'accès aux autres serveur/tables sont stockés en clair dans cette table, c'est mort aussi. Si on a accès à cette table, on peut aller bricoler dans toutes les tables de données des clients.

Attention bien différentier compte du client et compte de base de donnée, c'est ça mon problème : Comment doit-on faire pour stocker de façon cryptée un mot de passe de connexion à une autre BD dans une table de sorte que celui ci soit récupérable pour se connecté à cette autre BD ? (si c'est possible). Dans mon site l'acces client donne droit à utiliser mes scripts pour visualiser des données spécifiques à chaque client. Les données appartiennent aux clients et peuvent être stockées n'importe où du moment qu'elles sont sous la même forme, d'où la nécessité de récupérer les login/pwd d'accès au BD des clients.

Si j'ai bien compris, tu veux stocker les logins d'une base dans une table située dans une autre base.
Et tu veux faire en sorte que le serveur arrive à se connecter avec, mais pas le pirate ?
Si c'est cela, c'est impossible...
On sait que le serveur et le pirate dispose des mêmes informations (login et password)
Si le serveur peut se connecter avec ce dont il dispose, alors le pirate aussi.
Simple logique.
 
Si ce n'est pas ça, peux-tu t'expliquer plus clairement ?

si, c'est bien ça tu as bien compris.

C'est pour ça que je ne veux pas que les mots de passe des bases  n'apparaissent en clair dans la première base.

Y'a pas une technique de programmation pour stocker le mot de passe des bases dans la table pour les récupérer dans le script php d'identification, puis les décoder pour ouvrir la connexion à d'autre base ?

Après tout, je peux bien mettre une moulinette qui m'est propre dans ce script pour décoder le mot de passe.

je vais essayer de faire un schéma pour clarifier la chose...

Tu peux le crypter.
Mettre la valeur cryptée dans ta base.
Et dans ton script php, tu te connectes après avoir décrypté le mot de passe récupéré
 
Par contre, si le pirate a accès à la source php, là tu es fichu