[Plan du site] Vous êtes ici --- > Le Site du Zéro > Les forums > Site Web > PHP > qu'a-t-on le droit de mettre dans un cookie? > Lecture du sujet

qu'a-t-on le droit de mettre dans un cookie?

d'un point de vue sécurité

Vous devez être inscrit pour pouvoir poster des messages

Auteur	Message
Page : 1
1 visiteur sur ce sujet (1 anonyme)
Page : 1
Bertrand57	# Posté le 06/07/2008 à 09:39:44
Groupe : Membres	Bonjour, Je m'interroge sur ce que l'on peut mettre dans un cookie qui soit sans risque pour la sécurité du site? Je m'explique, au départ, je voulais mettre dans les cookies des visiteurs de mon site deux infos : id du visiteur et son niveau d'autorisation (qui lui permet d'accéder ou non à certaines pages). C'est le niveau d'autorisation qui me pose problème, car un visiteur ne peut-il pas modifier son cookie et donc changer le niveau d'autorisation indiqué? Après m'être posé cette question, j'ai eu l'idée de stocker l'id et le mot de passe crypté (et quand la personne se connecte au site, grâce à ces infos je vais chercher le niveau d'autorisation pour le mettre dans une session), mais sur le forum on m'indique de ne pas faire ça. Un visiteur peut-il modifier son cookie comme je le pense? dans ce cas quels types d'infos peuvent être stockés dans un cookie? Merci et bon dimanche
Le Chapelier Toqué	# Posté le 06/07/2008 à 09:51:05
Joyeux Non-Anniversaire ! Groupe : Membres	Pourquoi ne pas mettre le niveau d'autorisation dans une SESSION, qui, elle, est cryptée automatiquement ? <lien url="http://fr.youtube.com/watch?v=X1emMoayRYc">Joyeux Non-Anniversaire !
Bertrand57	# Posté le 06/07/2008 à 10:05:04
Groupe : Membres	le niveau d'autorisation est contenu dans une session mais pour éviter que le membre n'ait à se logger à chaque visite, je voulais mettre son id et son niveau d'autorisation dans le cookie, ainsi quand il arrive sur le site, ces deux infos passent dans la session
peplum37	# Posté le 06/07/2008 à 10:42:50
Groupe : Membres	bonjour, et si tu stockais dans ton cookies le nom et le mote de passe de l'utilisateur avec une date d'expiration (moi je mets 3heures) ? cela t'éviterait d'enregistrer des infos que l'utilisateur n'a pas à connaitre
Geoffroy	# Posté le 06/07/2008 à 10:50:32
Manger!!!!!!!!!!!!!!!!!!!!!! Groupe : Membres	en stockant ces données de manières crypté bien sur! par exemple dans ton cookie tu met md5($login . "\|\|" . $password); et la date d'expiration tu peux la mettre à une semaine, si tu fais une mise à jour correcte du cookie à chaque connexion. Avec ce cookie, il te suffit de faire des vérifications pour pouvoir voir de quel membre il s'agit, et à partir de la récupérer son ID, et son niveau d'autorisation stocké dans la base de donnée. Mon site!!!!!!!
DDR2	# Posté le 06/07/2008 à 10:52:48
sériez vous êtes flickrés ! Groupe : Membres	Oui, sauf que dans l'autre topic, on lui a formellement interdit de mettre des MDP (même crypté) dans un pass, ce qui n'est pas non plus complétement crétin... Par contre, je ne vois toujours pas comment se connecter (automatiquement) sans ces informations (MDP minimum), puisqu'on ne peut pas se baser uniquement sur l'id présent dans les cookies, puisque la sécurité gagnée dans le fait de ne pas mettre le MDP crypté dans un cookie, se perd totalement, puisqu'il suffirait d'une simple falsification du contenu du cookie pour se connecter à n'importe quel compte et ce, sans AUCUNES vérifications... Journal de l'inutile
peplum37	# Posté le 06/07/2008 à 11:01:49
Groupe : Membres	bonjour, je suis d'accord, mais quel est la différence entre la vérification de l'utilisateur , mot de passe saisi dans un formulaire de loggin et la récupération dans un cookie si les vérifications qui suivent sont les mêmes ?
DDR2	# Posté le 06/07/2008 à 11:05:48
sériez vous êtes flickrés ! Groupe : Membres	En gros tu as deux choix : => tu stockes le user/pass dans un cookie (crypté bien entendu), et là tu procédes comme une connexion "normale" à partir d'un formulaire => tu stockes l'id du membre dans un cookie mais alors là, tu n'as aucunes vérificatiosn possible (en même temps t'as qu'une seule donnée xD), la seule vérification que tu peux réaliser serait de voir si cet id exsite réellement. A mon avis, les deux solutions sont peu, voir pas du tout sécurisé, il est donc préférable à mon sesns de laisser l'utilisateur se connecter manuellement à chaque connexion Journal de l'inutile
Geoffroy	# Posté le 06/07/2008 à 11:07:01
Manger!!!!!!!!!!!!!!!!!!!!!! Groupe : Membres	tu peux essayer de corser la chose d'une manière ou d'une autre. Vu que la vérification se fait entrée par entrée, tu pourrait aussi utilisé un cookie de ce type : md5($login . "\|somedata\|" . sha1($password . "\|someotherdata\|" . $id) . "\|alwaysdatas\|" . $auth_level); Pour trouver la manière dont tu as crypté les données, ça mettra déjà du temps, c'est pour ça que je met toujours un petit séparateur, voir plusieurs, àfin d'être sur de ne pas rendre la tâche trop trivial! peplum37 : les vérifications sont pas exactement les mêmes si tu les cryptes comme je l'ai montré, mais ça reste simple à faire. La principale différence réside dans le fait que l'utilisateur n'a pas a entrer les données! Le mieux est toujours de lui proposer la méthode cookie afin de lui faciliter la tâche, bien que dans ce cas la il faut faire attention à sécurisé la moindre donné afin de ne pas laisser de faille qui permettrait de récupérer ces précieuses informations (bon vous me laissez écrire?) Mon site!!!!!!!
peplum37	# Posté le 06/07/2008 à 11:09:19
Groupe : Membres	ok salut et bonne écriture !
K-Phoen	# Posté le 06/07/2008 à 11:16:37
Geek un jour, geek toujours ! Groupe : Membres	Citation : DDR2 => tu stockes l'id du membre dans un cookie mais alors là, tu n'as aucunes vérificatiosn possible (en même temps t'as qu'une seule donnée xD), la seule vérification que tu peux réaliser serait de voir si cet id exsite réellement. Voici grosso-modo comment je procéderais : Il suffirait de stocker l'ID du membre, ainsi qu'une clé "d'autologin" qui lui aurait été assignée pendant la session. Cette clé serait propre à chaque membre, et serait renouvelée à chaque session. La Geek Attitude ----------------------- Tout sur Adobe AIR
DDR2	# Posté le 06/07/2008 à 11:21:32
sériez vous êtes flickrés ! Groupe : Membres	K-Phoen => en effet, ça semble être une bonne solution, reste à la mettre en place et voir ce que ça donne en prod' Journal de l'inutile
Bertrand57	# Posté le 08/07/2008 à 18:48:53
Groupe : Membres	merci à vous tous pour vos réponses instructives les solutions proposées par Geoffroy et K-Pkoen sont intéressantes! merci
Bertrand57	# Posté le 05/10/2008 à 17:16:26
Groupe : Membres	Citation : K-Phoen Voici grosso-modo comment je procéderais : Il suffirait de stocker l'ID du membre, ainsi qu'une clé "d'autologin" qui lui aurait été assignée pendant la session. Cette clé serait propre à chaque membre, et serait renouvelée à chaque session. quel est le gain de sécurité entre cette clé d'autologin et un mot de passe crypté? à part le fait que la clé est renouvellée régulièrement? si quelqu'un copie le cookie dans lequel se trouve cette clé, il accédera au site en se faisant passer pour sa victime...
Jean-Seb	# Posté le 05/10/2008 à 18:14:29
Fi. doo . daa... Groupe : Membres	Bertrand57-> Peut importe l'information du cookies s'il est récupéré par quelqu'un celui-ci pourra se connecter sur son compte. Une chose possible serait d'ajouter dans la génération de l'identifiant de connexion, l'user agent du visiteur. Mais à partir du moment que quelqu'un récupère nos cookies, rien ne l'empêche de récupérer aussi nos mots de passe enregistrés. En tant que dévelopeurs Web, nous devons veiller à la sécurité de notre site, mais pas à celle des visiteurs imprudents... Projets : - App d'envoi de commandes par TCP : Écrit en PHP avec interface graphique avec PHP-Gtk. Parseur de variables et gestion de connexions par onglets. - Tuto sur un système de tâches planifiées en PHP : Peut-être... - CMS au fonctionnement particulier : Création de modules par XML. - total-itech : site personnel, blog, CV
bestpig	# Posté le 05/10/2008 à 20:41:38
Groupe : Membres	Citation : Jean-Seb Bertrand57->Une chose possible serait d'ajouter dans la génération de l'identifiant de connexion, l'user agent du visiteur. Ou l'ip, si l'ip n'est pas la même, meme si le reste du cookies et valide --> tu n'est pas logger Kézako : 53E9726965757820766F7573206C276176657A2064E9636F64E9203F http://videodownloader.fr
nicodd	# Posté le 05/10/2008 à 23:56:01
Groupe : Membres	Oui mais que faire alors des gens qui changent régulièrement d'ip ? Moi chaque fois que je viens sur le sdz, je suis connecté automatiquement, même en changeant d'ip tous les jours, et ca m'embèterais bien d'avoir à me reconnecter à chaque fois... La solution de concaténer le mot de passe avec toutes sortes d'infos et de hash avant de tout re-hasher est bancale aussi, vu que si un 'pirate' arrive à récuperer le cookie, il lui suffit de le copier sur son pc, et le site l'autentifiera aussi surement que si il était sur le pc de sa victime... La solution 1 est sans aucun doute plus sûre, mais plus ou moins inconfortable pour le visiteur. Un autre problème se pose encore, et si le visiteur utilise un proxy ? Il devra se reconnecter à chaque page ? Une possibilité serait de mettre par défaut la solution 1, avec l'user agent intégré, mais de permettre dans les options du membre de désactiver cette vérification, si il se trouve dans un des cas cités où cela risque de poser problème. C'est un peu plus compliqué à implémenter, mais cela me semble un compromis raisonnable
harcher81	# Posté le 06/10/2008 à 00:49:49
Et oui, c'est moi Groupe : Membres	Puisqu'il suffit de récupérer le cookie pour se connecter dans tous les cas, il n'y a pas de meilleur solution, faut mettre plus que 1 cookie, comme cela déjà on rend le travail légèrement plus difficile pour celui qui veut copier les cookies. Mais vous avez beau hasher une chaîne mille fois, le risque est le même que si vous mettez le mot de passe crypter une fois. La seul chose à faire est de faire de la prévention pour que l'utilisateur ne donne pas ces cookies, et ensuite on met id, login et password dans 3cookies différents. Le mot de passe étant bien sur hasher.
Jean-Seb	# Posté le 06/10/2008 à 09:51:21
Fi. doo . daa... Groupe : Membres	personnellement, je trouve inutile et peu sécuritaire d'ajouter le mot de passe dans les cookies qu'il soit crypté, hashé ou peu importe... je préfère un simple identifiant de session unique sinon, c'est comme dire à celui qui mettrais la main sur nos cookies: - voici la session de untel, son login et n'oublie pas de prendre note de son mot de passe crypté. Bonjour et bon vol d'identité... je ne crois pas que les cookies de connexion automatiques doivent être utilisés pour reconnecter l'utilisateur par la retransmission des informations. Si l'on veut prendre note des information du genre IP, User Agent, on peut très bien les mettrent dans une table de connexion. Projets : - App d'envoi de commandes par TCP : Écrit en PHP avec interface graphique avec PHP-Gtk. Parseur de variables et gestion de connexions par onglets. - Tuto sur un système de tâches planifiées en PHP : Peut-être... - CMS au fonctionnement particulier : Création de modules par XML. - total-itech : site personnel, blog, CV