PHP : Cryptage MD5 et Cookie

PHP : Cryptage MD5 et Cookie - PHP - Programmation

Marsh Posté le 12-02-2003 à 17:19:39    

Salut
 
voila je ne vois pas l'intérêt de crypter un mot de passe en MD5 pour le foutre ensuite ds un cookie !
 
Je m'explique : mon MDP est "toto"
Je le crypte et le mets ds un cookie sous la forme 12d5f45e.
 
C pas décryptable (heureusement)
 
Mais pour vérif si mon user est bien un vrai je dois fatalement checker le login et le md5(MDP) avec ce qu'il y a ds la base non ???
 
Dc ca veut dire que je dois ds mon code convertir le MDP saisi par md5 puis le comparer avec le MDP de la base converti lui aussi en md5. En gros, crypté un MDP ds un cookie a UN avantage : si on te matte ds tes cookies, on ne voit pas ton cookie fétiche en clair !
 
Est-ce que je me trompe ?
 
a+  
Merci
 
PS : c t pas sensé être une affirmation :) C une question suite à un raisonnement.

Reply

Marsh Posté le 12-02-2003 à 17:19:39   

Reply

Marsh Posté le 12-02-2003 à 17:24:14    

bravo tu es donc capable de suivre un raisonnement logique et d'en tirer des conclusions
 
sèrieusement, à part ça tu postais pour quoi ??


---------------
La musique c'est comme la bouffe, tu te souviens du restaurant dans lequel t'as bien mangé 20 ans plus tôt, mais pas du sandwich d'il y a 5 minutes :o - Plugin pour winamp ©Harkonnen : http://harko.free.fr/soft
Reply

Marsh Posté le 12-02-2003 à 18:00:35    

Sh@rdar a écrit :

bravo tu es donc capable de suivre un raisonnement logique et d'en tirer des conclusions
 
sèrieusement, à part ça tu postais pour quoi ??


 
 :lol: non sérieux en fait ma question c t ya-t-il un moyen sérieux de crypté un cookie à part ce que je viens d'énoncer ?
 
merci

Reply

Marsh Posté le 12-02-2003 à 18:22:57    

[:totozzz]

Reply

Marsh Posté le 12-02-2003 à 18:29:02    

kileak2 a écrit :


 
 :lol: non sérieux en fait ma question c t ya-t-il un moyen sérieux de crypté un cookie à part ce que je viens d'énoncer ?
 
merci


Ben, en le cryptant :D ...
MD5 est un algo de hachage, pas de chiffrement. Tu peux utiliser du DES, du RSA ou tout autre algorithme, en gardant la clef bien secrêtement coté serveur. Et pour être parano jusqu'au bout, tu peux même vérifier l'authenticité de ton cookie en chiffrant le cookie concaténé avec son hachage MD5.

Reply

Marsh Posté le 12-02-2003 à 18:45:48    

Dsls a écrit :


Et pour être parano jusqu'au bout, tu peux même vérifier l'authenticité de ton cookie en chiffrant le cookie concaténé avec son hachage MD5.  

[:totoz]

Reply

Marsh Posté le 12-02-2003 à 18:48:54    

Dsls a écrit :


Et pour être parano jusqu'au bout, tu peux même vérifier l'authenticité de ton cookie en chiffrant le cookie concaténé avec son hachage MD5.  


:love:


---------------
Whichever format the fan may want to listen is fine with us – vinyl, wax cylinders, shellac, 8-track, iPod, cloud storage, cranial implants – just as long as it’s loud and rockin' (Billy Gibbons, ZZ Top)
Reply

Marsh Posté le 13-02-2003 à 11:30:15    

Dsls a écrit :


Ben, en le cryptant :D ...
MD5 est un algo de hachage, pas de chiffrement. Tu peux utiliser du DES, du RSA ou tout autre algorithme, en gardant la clef bien secrêtement coté serveur. Et pour être parano jusqu'au bout, tu peux même vérifier l'authenticité de ton cookie en chiffrant le cookie concaténé avec son hachage MD5.  


 
Et DES, RSA...... c des trucs intégrés à php comme MD5 ou c en plus ?

Reply

Marsh Posté le 13-02-2003 à 11:56:40    

ben de toute façon le problème reste le meme que tu utilises MD5 ou que tu crypes...

Reply

Marsh Posté le 13-02-2003 à 12:46:48    

kileak2 a écrit :


 
Et DES, RSA...... c des trucs intégrés à php comme MD5 ou c en plus ?


 
On peut y accéder via les fonctions mcrypt_XXX (cf http://ch.php.net/manual/en/ref.mcrypt.php), mais il faut que la libmcrypt soit installée...
 

Citation :


ben de toute façon le problème reste le meme que tu utilises MD5 ou que tu crypes...


Certes, si quelqu'un récupère ton cookie par un moyen ou par un autre il aura accès à tes pages protégées... dans ce cas rien ne vaut un bon https (mais dans ce cas, plus besoin de chiffrer le cookie ;) )

Reply

Marsh Posté le 13-02-2003 à 12:46:48   

Reply

Marsh Posté le 13-02-2003 à 13:16:35    

Dsls a écrit :


 
On peut y accéder via les fonctions mcrypt_XXX (cf http://ch.php.net/manual/en/ref.mcrypt.php), mais il faut que la libmcrypt soit installée...
 

Citation :


ben de toute façon le problème reste le meme que tu utilises MD5 ou que tu crypes...


Certes, si quelqu'un récupère ton cookie par un moyen ou par un autre il aura accès à tes pages protégées... dans ce cas rien ne vaut un bon https (mais dans ce cas, plus besoin de chiffrer le cookie ;) )


 
A ce point !!!!
 
Mais https fait comment lui ?

Reply

Marsh Posté le 13-02-2003 à 13:41:00    

kileak2 a écrit :


 
A ce point !!!!
 
Mais https fait comment lui ?


 
En fait, ta question soulève plusieurs problèmes et plusieurs contraintes de sécurité différentes :
1. Le stockage du mot de passe sur la machine serveur
2. Le stockage du cookie sur la machine cliente
3. Le transit du mot de passe lors de l'authentification, et lors des reconnexions.
 
Les (ou plutot des) solutions :
1. Protection de la machine, accès base de données, mot de passe chiffré (de manière unilatérale de préférence, cf md5 ou autres)
2. Protection du cookie afin d'empêcher sa lecture par un autre utilisateur de la machine => chiffrement du mot de passe. A noter que le fait de stocker le md5 du mot de passe tel qu'il est stocké en base ne change rien, puisque ca revient à envoyer un mot de passe en clair => mieux vaut dans ce cas le stocker chiffré par le serveur avec un algo permettant de le déchiffrer (toujours coté serveur), et une clef secrète coté serveur.
3. Si un gars te pique ton cookie (ca peut être dû a) à une faille dans un .php, b) à un autre gars qui se connecte sur ta machine cliente, c) à cause de sniffing de paquets), il a tous les accès sur le serveur. Des solutions :
  pour a) Blinder son code php
  pour c) utiliser ssl pour chiffrer la communication et ainsi éviter que les paquets soient interceptés (attention aux man-in-the-middle quand même)
  pour b) protéger ses cookies par mot de passe (je crois que c'est faisable sous mozilla, je ne sais pas comment c'est sous IE), ou blinder son compte utilisateur.
 
Enfin dans tous les cas, et toujours dans l'optique "parano à donf", il vaut mieux éviter de conserver un mot de passe (chiffré ou non) coté client. Au pire on peut utiliser les ID de session php (par exemple), qui eux n'ont aucun lien avec le passwd (mais là il reste toujours le problème de vol de cookie, à moins que la session ait une durée de vie très courte)
 
Voila, j'espère ne pas avoir dit trop de bêtises (et si c'est le cas, je suis sur que vous rectifierez  :D )


Message édité par dsls le 13-02-2003 à 13:41:49
Reply

Marsh Posté le 13-02-2003 à 15:14:33    

Dsls a écrit :


 
En fait, ta question soulève plusieurs problèmes et plusieurs contraintes de sécurité différentes :
1. Le stockage du mot de passe sur la machine serveur
2. Le stockage du cookie sur la machine cliente
3. Le transit du mot de passe lors de l'authentification, et lors des reconnexions.
 
Les (ou plutot des) solutions :
1. Protection de la machine, accès base de données, mot de passe chiffré (de manière unilatérale de préférence, cf md5 ou autres)
2. Protection du cookie afin d'empêcher sa lecture par un autre utilisateur de la machine => chiffrement du mot de passe. A noter que le fait de stocker le md5 du mot de passe tel qu'il est stocké en base ne change rien, puisque ca revient à envoyer un mot de passe en clair => mieux vaut dans ce cas le stocker chiffré par le serveur avec un algo permettant de le déchiffrer (toujours coté serveur), et une clef secrète coté serveur.
3. Si un gars te pique ton cookie (ca peut être dû a) à une faille dans un .php, b) à un autre gars qui se connecte sur ta machine cliente, c) à cause de sniffing de paquets), il a tous les accès sur le serveur. Des solutions :
  pour a) Blinder son code php
  pour c) utiliser ssl pour chiffrer la communication et ainsi éviter que les paquets soient interceptés (attention aux man-in-the-middle quand même)
  pour b) protéger ses cookies par mot de passe (je crois que c'est faisable sous mozilla, je ne sais pas comment c'est sous IE), ou blinder son compte utilisateur.
 
Enfin dans tous les cas, et toujours dans l'optique "parano à donf", il vaut mieux éviter de conserver un mot de passe (chiffré ou non) coté client. Au pire on peut utiliser les ID de session php (par exemple), qui eux n'ont aucun lien avec le passwd (mais là il reste toujours le problème de vol de cookie, à moins que la session ait une durée de vie très courte)
 
Voila, j'espère ne pas avoir dit trop de bêtises (et si c'est le cas, je suis sur que vous rectifierez  :D )


 
Bel exposé !
Effectivement, fo pas non plus être trop parano :)
 
Je pense que je vais qd même opté pour un md5 ou un mcrypt du mdp de mon user ds le cookie.
Pkoi ? parce que au moins s'il se fait carotter son cookie, le gars pourra acceder à mon site mais pas à tous les autres où l'user à un compte. Ce que je dis compte bien sur seulement pour les gens qui ont UN mdp UNIQUE pour tous les sites ! Ca arrive fréquemment !
 
Je pige qd même pas comment le fait de crypter ou coder quoique ce soit sur le serveur peu ajouter de la sécurité si tu envoies la clé ds un cookie.
Le cookie ca sert, p.e., à s'identifier dc le serveur va checker les données du cookie point barre. Si c ok après multiple algo de décodage ca passe mais la chaine testée vient irrémédiablement du cookie dc... On tourne en rond :)
 
C sur que pour circuler ds un site, je vais opter pour le session_id(). Le cookie servira juste au 1er "loggage" automatique.
 
a+

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed