je voulais savoir si selon vous placer dans un cookie le login + mdp crypté c'est suffisant pour une authentification de l'utilisateur ? Si c'est pas conseillé, etc...

moi c comme ca que je fait !! je sais pas comment fait joce mais a mon avis il est meme pas crypte le mdp (chui pas sur).

joce a l'air d'avoir crypté car le contenu de la var passs de mon cookie ne contient pas mon mdp clair

 
 
Bah au niveau sécurité, je ne stockerais jamais le login/pass dans un cookie étant que par exemple en réseau il est assez simple de récupérer (soit via un partage, soit directos sur l'ordi) le cookie pour en extraire les données.

oui, mais crypté ?

<input type=password maxlength=40 size=25 name=password value="************">
 
 
******** => mon pass en clair !! il le sort d'ou puisque qu'il crypte ds la bdd en md5 ?

 
Ca change quoi?
Tu veux dire quoi? :
- ton script le chiffre avant de l'envoyer ? : on prend le cookie sur son ordi et on aura accès au site vu que le script déchiffrera et tombera donc sur le bon pass;
- tu laisses IE s'en charger ? : si IE arrive à le déchiffrer au moment de le renvoyer, je pense qu'un autre programme pourrait aussi le faire.
 
Mais bon tu n'es pas obligé de t'emmerder pour un site qui ne nécéssite pas une sécurité max ...

 
md5 ne chiffre pas , il fait un hash ce qui a l'avantage de ne pas pouvoir revenir en arrière.  
Par contre es-tu sûr que le mot de pass est hashé dans la base de données?

lorsque j'écris le cookie il est crypté avec md5, donc sur l'ordi on peux pas voir le mot de pass en clair. Je pense pas qu'on puisse le déchiffrer facilement non plus. Par contre, si qqun transporte le cookie avec lui, il tjs authentifié de la même façon.

 
tu le cryptes avec md5 ??!
je comprends pas un truc, ton script est-ce qu'il arrive à récupérer le mot de pass en clair à partir du résultat du md5?

non, mais je compares les 2 mdp cryptés...

 
voilà, md5 ne chiffre pas il fait un hash, à partir de quoi on ne peut pas retrouver le texte original d'aucun manière (sauf en essayant toutes les possibilités   ).
 
le fait de mettre le md5 dans un cookie revient finalement au même que de mettre le mot de pass en clair, vu que si quelqu'un récupère ce cookie, il pourra avoir accès au site. D'accord il ne pourra pas connaître le mot de pass en clair, mais il pourra peut-être le changer, etc... (en fonction du site).
 
Sous Linux (par exemple), les mots de pass sont stockés sous forme hashés, ainsi si quelqu'un récupère le fichier des login/pass , il ne pourra connaître aucun des mot de pass. Mais dans ce cas là, pour se loguer il faut fournir le mot de pass en clair, ensuite l'OS le hash avec le même algorythme et le compare à celui qui est stocké. Ainsi il n'y a pas de problème.

mon site ne permet pas de changer son mot de passe (pas pour les utilisateurs en tout cas, seul l'admin peut donner un nouveau mdp)

 
ok mais t'es d'accord que à partir du moment où quelqu'un lit le cookie et récupère le md5 du mot de pass, ça revient au même que si il avait pu lire le mot de pass en clair : il a accès aux même fonctionnalités dans les 2 cas.

tout à fait, mais c'est vraiment très peu probable que le mec récupère le cookie et l'utilise... De toute façon, y'a pas de données vitales..., au pire, je mets une durée de validité de cookie très courte, comme ça le mec il va pas loin.

 
Bah voilà, si il n'y a pas de données importantes, ce n'est pas grave.
À propos de la durée de validité du cookie, si tu y stockes le mot de pass hashé, quelqu'un peut regénérer un cookie valide ensuite. Par contre, il vaut mieux générer, quand l'utilisateur se logue, un id unique (genre un md5 du temps en microsecondes) que tu stockes dans ta base de données avec sa date d'expiration, comme ça ce sera plutôt ton script qui vérifira la validité de l'id.