Simplement je voulais savoir ce que vous pensiez de l'identification par cookie sur un site (pour aller dans un espace membre). Est ce fiable au niveau securité? N'y a t il pas de risque d'etre pirater?  
 
Comment peut on s'y prendre le cas échéant pour reconstruire un cookie de mon site?
 
Merci à tous

Je te conseille deja d'utiliser une session a la place de cookies

 
Heu je suis pas d'accord avec toi   :
Si tu n'utilises pas les cookie pour les sessions, l'id session passe en clair dans l'url alors qu'avec les cookie c'est pas le cas. Donc avec les cookies c'est mieux.  

Et on ne peux pas "imiter" ce que contient un cookie? Par exemple en écrivant un autre cooke?

non, ton serveur n'accepte que les cookies qu'il a créé.

merci sonikbuzz

Les sessions utilisent a leur facon les cookies bien entendu, mais je les trouve beaucoup plus sures parceque par exemple je stoque dans les variables de sessions des info que je ne veux pas que l'utilisateur puisse connaitre, ce qui est difficilement realisable avec les cookies vu qu'ils sont stockés cotés client.
 

 
Tu peu les crypter

On peut mettre ce que l'on veut dans un cookie et le donner au serveur. C'est juste qu'un autre serveur ne pourra pas lire le contenu de tes cookies.

 
Oui mais je trouve quand meme beaucoup plus utiles les sessions. Elles ont une taille  illimitée, nombre de variables illimitées, les risques d'interception de la part d'un tier ne sont pas plus hauts qu'avec les autres scripts (ton truc du id session passé dans l'url je comprend pas trop a quoi tu fais reference).

 
Attention quand meme, les sessions peuvent etre vulnerables mais sur le serveur.
Si tu es heberge sur un serveur mutualise, tes "voisins" peuvent "pirater" tes sessions, bon me semble que c'est pas possible s'il y a le safe mode, mais les sessions ne sont pas "secures".
 
Sinon, il me semble que sonikbuzz fait reference a l'id qui identifie les sessions. En effet quand tu cree une session cette derniere a une id. Cette id sert a la differencier des autres sessions. Mais voila, pour que le serveur sache a quel client appartient telle ou telle session, le client doit lui envoyer le session id.
La 2 methodes :
1) Surement la plus utilisee, c'est de stocker l'id de session dans un cookie chez le client. Cookie avec une duree de vie limitée qui n'est valable que le temps de la session du navigateur. Une fois ferme, le navigateur detruit le cookie.
2) Si le client n'accepte pas les cookies, alors on peut passer l'id de la session par l'url. Cette methode va "creer" des urls du type : "www.monsite.com/mapage.php?PHPSESSID=14524632155".
Ces 2 methodes sont "gerees par php", c'est pourquoi on a tendance a les oublier. Il existe d'ailleurs un parametre php pour lui dire s'il doit ajouter lui meme de facon autmatique le "PHPSESSID=..." a la fin des urls.
 
Enfin bref, dans les deux cas, l'unique chose a laquelle le client peut acceder est l'id de la session. Ici l'unique moyen pour lui de "pirater" une autre session c'est de connaitre son id... Les ids sont faits de telle maniere qu'ils peuvent difficilement etre "devines", donc a moins d'avoir un access quelconque au pc de la "victime" c'est quasiment "impossible".
La plus part du temps on prefere entrer par un autre endroit. Prenons un exemple. Admetons que vous stockez, dans un cookie, le "login" et le "md5" du password d'un user. Comme ca des qu'il revient sur le site, ce dernier detecte la presence du cokiie, puis apres verification du login et du mot de passe autorise l'utilisateur et lui cree une session.
Ici le hacker aura plutot tendance a pirater le site via une attaque du type de "sql injection" afin de recuperer un couple "login / md5(password)" que pirater la session php. Cette derniere etant plus dure a trouver, alors que le fait de pirater la bdd via une "sql injection attack" lui sera surement plus facile.
 
Avec cet exemple relativement simple on peut se rendre compte que le probleme ne vient pas forcement des cookies et/ou sessions, mais plutot de la facon generale dont le site est concu. Le simple fait que le site "reconnaisse" un utilisateur et le relogue sans lui redemander un password peut etre le point faible de votre site. Et dire qu'a l'origine vous ne vouliez que "faciliter la vie des utilisateurs" ont leur evitant de se re authentifier a chaque fois ...
 
Avec cet exemple on peut egalement voir que le fait que les infos soient "cryptees" ne changent pas bcp. Ici le mot de passe est "crypte" puisqu'il n'est pas stocke en clair dans le cookie. Neanmoins sa formee cryptee y est. Le probleme reside plus sur le fait que "la meme information" se trouve a la fois dans le cookie est dans la bdd. Une parade pourrait etre de ne pas utiliser le meme algo dans le cookie est dans la bdd. Mais un autre probleme survient... Generalement le mot de passe n'est jamais stocke en clair dans la bdd pour eviter des problemes si jamais la bdd vient a etre compromise. Mais s'il n'est pas sotcke en clair alors il y a pas vraiment de "moyen" pour pouvoir creer deux "cryptages" differents.
Si le password etait en clair il suffirait d'utiliser md5 dans un cas, puis par exemple sha-1 dans un autre. On pourrait toujours les "comparer" puisqu'on aurait une base commune. Mais cela n'est pas le cas, donc c'est pas vraiment faisable...  
On pourrait "re crypter" le cryptage du mot de passe, mais cela ne fait pas bcp de difference, une fois que le hacker sait quel algo vous avez utilise pour "re crypter" le mot de passe ca ne sert plus a rien...
 
Ce qui pourrait eventuellement augmenter un peu le sentiment de securite serait de stocker en crypte le nom de l'utilisateur. Mais la un autre probleme survient.
Soit vous utilisez un "vrai" cryptage (donc reversible) et a ce moment une fois l'algo "devine" c'est comme s'il n'existait pas.
Soit vous utilisez un "faux" algo de cryptage (donc non reversible) et a se moment votre procedure de login ralentit proportionnelement aux nombre d'utilisateurs enregistres sur le site. Ben oui faut faire un boucle et a chaque fois comparer le cryptage de l'utilisateur que l'on teste avec la valeur du cookie. Il existe d'ailleur un autre probleme, il se peut que deux utilisateurs aient la meme valeur de "cryptage", bon il reste encore le "password" mais (et si ce dernier etait le meme ?)...
 
 
Enfin voila, apres cette longue tirade j'espere vous avoir montre que le probleme n'est pas vraiment la ou on le pense. Et je pense que la meilleure solution reste quand meme la session pour stocker "le boolean indiquant si l'user est logue" (stocker se bool ds un cookie n'est vraiment pas la bonne solution, car le cookie est facilement modifiable).

 
quand je me suis penché sur le fonctionnement des cookies, pour essayer de comprendre, j'ai fait pas mal de test en local (avec easyPHP).
Truc basique, un cokkie avec le pseudo, quand tu arrive sur le site, si le cookie existe il te logue direct, enfin rien de bien innovant.
J'ai essayé à plusieurs reprise de modifier le contenu du cookie (autre pseudo par exemple)  avec un éditeur de texte, ben quand je retournai sur le site, celui-ci se comportait comme si le cookie n'existait pas
--> je suis donc plutot d'accord avec sonikuzz quand il dit:

Si tu ne sais pas modifié un cookie, j'y peux rien .
 
Peux tu m'expliquer comment le serveur distingue un cookie non modifié d'un cookie modifié?

Cerel > Justement, si tu utilises une session avec le phpID dans un cookie c'est deja pas mal securisant, c'est clair qu'on peut encore cracker le serveur pour pouvoir chopper la session et la modifier .. mais ça c0'est une autre histoire

paske j'utilise les sessions, que j'oblige l'ID de session à passer par cookie (via un ini_set())

Je parle du fait que selon toi les cookies ne pourraient être modifiés

 
selon le site suivant:
http://www.adia.fr/Contenu/pages/p_mentions.asp
 
je cite:

 
tu dis:

ben moi non plus

Xav_ je crois que ce que l'article que tu presentes signifie qu'un site ne peut modifier/supprimer seulement les cookies qu'il a créé lui meme, mais le client peut sans doutes modifier les cookies qui sont dans son ordio

Il est possible de modifier les cookies. Par contre il est possible que certains browser integrent un systeme de "checksums" afin de verifier que le cookie n'as pas ete corrompu. Mais neanmoins on peut modifier les cookies et meme les creer. Me semble avoir vu trainer un utilitaire du genre pour IE. Il permetait de forger des cookies pour n'importe quel site.

si ce que j'ai pu lire ainsi que les tests que j'ai fait sont faut, merci par avance de me le prouver...  
le cas échéant je reconnaitrais de bon coeur m'etre trompé...  
 
bien sur qu'avec un éditeur de texte tu modifie un cookie sans pb, sauf que chaque fois que je l'ai fait pour tester, le site d'origine ne tenait plus compte du cookie modifié...
Le serveur arrive à reconnaitre un cookie "modifié" meme si je sais pas exactement comment...
 

Dans ton article il faut comprendre comme dit plus haut que presencepc peut pas lire des cookies de hfr(les exemples ).
Enfin moi je suis sûr de moi, je l'ai déjà fait et ça marche, j'ai rien à te prouver. Maintenant si tu ne veux pas me croire libre à toi . (Tu peux me filer le contenu de ton cookie sur ton forum, tu verras je saurai me loguer. Maintenant c'est une mauvaise idée )

c'est kler

Tiens vu que ca parle de session et de cookie ...
 
Question bête (mais alors très) :
 
Si on utilise les sessions, les cookies expire à la fermeture du navigateur. Mais si on veut que ce meme cookie aie une autre date d'expiration, c'est possible ?