Cookies
mahamourta
Messages postés
85
Date d'inscription
jeudi 6 août 2009
Statut
Membre
Dernière intervention
2 septembre 2016
-
17 oct. 2009 à 00:23
neigedhiver Messages postés 2480 Date d'inscription jeudi 30 novembre 2006 Statut Membre Dernière intervention 14 janvier 2011 - 17 oct. 2009 à 23:46
neigedhiver Messages postés 2480 Date d'inscription jeudi 30 novembre 2006 Statut Membre Dernière intervention 14 janvier 2011 - 17 oct. 2009 à 23:46
5 réponses
TychoBrahe
Messages postés
1309
Date d'inscription
samedi 31 janvier 2009
Statut
Membre
Dernière intervention
5 juin 2013
12
17 oct. 2009 à 10:06
17 oct. 2009 à 10:06
Salut,
Tu devrais plutôt regarder du côté des variables de session, PHP se chargera de mettre un cookie avec un identifiant de session (ou de passer l'identifiant par l'url mais cette méthode est déconseillée) afin que tu soit en mesure de stocker des valeurs côté serveur.
Tu devrais plutôt regarder du côté des variables de session, PHP se chargera de mettre un cookie avec un identifiant de session (ou de passer l'identifiant par l'url mais cette méthode est déconseillée) afin que tu soit en mesure de stocker des valeurs côté serveur.
Lyle56
Messages postés
240
Date d'inscription
jeudi 1 mai 2008
Statut
Membre
Dernière intervention
19 juillet 2012
2
17 oct. 2009 à 14:53
17 oct. 2009 à 14:53
http://fr2.php.net/manual/fr/features.cookies.php
Regarde ici, tu devrais trouver un peut plus d'explications sur l'utilisation des cookies.
Mais comme le message précédent le suggère, préfère plutôt les sessions;
Regarde ici, tu devrais trouver un peut plus d'explications sur l'utilisation des cookies.
Mais comme le message précédent le suggère, préfère plutôt les sessions;
neigedhiver
Messages postés
2480
Date d'inscription
jeudi 30 novembre 2006
Statut
Membre
Dernière intervention
14 janvier 2011
19
17 oct. 2009 à 22:55
17 oct. 2009 à 22:55
Salut,
Moi, personnellement, je déconseille les sessions pour ce genre de fonctionnalité. Voici pourquoi (je tiens ça de malalam, depuis, je ne peux pas être en désaccord tellement je suis d'accord avec... oui je me répète ^^)
- la session est justement, une session : quand on revient le lendemain, c'est une nouvelle session
- conséquence du premier point : la session stocke des informations dont on n'aura pas nécessairement besoin demain (ordre de tri sur une liste, filtres sur des articles, dernières pages consultées, panier, etc)
- une session a une durée de vie limitée. La durée par défaut dans PHP est de 1440 secondes, soit 24 minutes. Faire durer une session plus longtemps n'a pas de sens : si l'utilisateur se connecte depuis une autre machine, les deux sessions perdureront. Suivant le niveau d'activité du site, on peut atteindre un répertoire de sessions franchement volumineux (surtout qu'une fonction d'auto login doit permettre un login auto sur une longue durée comme 1 mois minimum, parfois jusqu'à 1 an !)
Conclusion : utilisez les sessions pour gérer l'environnement de l'utilisateur, pas sa connexion sur une longue durée. Stockez en session, lors de l'identification (qu'elle soit automatique ou pas) les informations du profil de l'utilisateur (la langue du site, le thème graphique, ce genre de chose) et le fait qu'il est bien connecté (son ID user et son niveau d'autorisations). Pour l'identification automatique... Attention, je pense que certains vont crier, mais il ne faut pas : stockez le login et le mot de passe CRYPTES dans un cookie et vérifiez si le cookie est présent lors de la visite de l'utilisateur (s'il n'est pas déjà connecté dans la session).
Quand je dis de crypter, j'entends par la l'utilisation de fonctions de cryptographie, pas de signature (hash md5, sha1). Non non, de la vraie cryptographie sur 256 bits, avec des algorithmes du niveau de ceux utilisés par les services secrets (oui, PHP fournit ça avec la bibliothèque mcrypt).
Je ne prétends pas que cela soit facile à implémenter, juste que c'est certainement bien plus sécurisé qu'une session avec un simple cookie.
Evidemment, il ne faut pas permettre à l'utilisateur de modifier son mot de passe ou son email, sans saisir son mot de passe en cours... Le mot de passe stocké dans le cookie n'est pas déchiffrable sans en connaître la clé privée (et cracker un mot de passe complexe sans la clé privée peut prendre des siècles, alors qu'avec le paradoxe des anniversaires, trouver un hash md5 ou sha1 qui convient pour un mot de passe, aussi complexe soit-il, permet de réduire ce temps à quelques jours voire quelques heures).
--
Neige
N'hésitez pas à lire la doc
Moi, personnellement, je déconseille les sessions pour ce genre de fonctionnalité. Voici pourquoi (je tiens ça de malalam, depuis, je ne peux pas être en désaccord tellement je suis d'accord avec... oui je me répète ^^)
- la session est justement, une session : quand on revient le lendemain, c'est une nouvelle session
- conséquence du premier point : la session stocke des informations dont on n'aura pas nécessairement besoin demain (ordre de tri sur une liste, filtres sur des articles, dernières pages consultées, panier, etc)
- une session a une durée de vie limitée. La durée par défaut dans PHP est de 1440 secondes, soit 24 minutes. Faire durer une session plus longtemps n'a pas de sens : si l'utilisateur se connecte depuis une autre machine, les deux sessions perdureront. Suivant le niveau d'activité du site, on peut atteindre un répertoire de sessions franchement volumineux (surtout qu'une fonction d'auto login doit permettre un login auto sur une longue durée comme 1 mois minimum, parfois jusqu'à 1 an !)
Conclusion : utilisez les sessions pour gérer l'environnement de l'utilisateur, pas sa connexion sur une longue durée. Stockez en session, lors de l'identification (qu'elle soit automatique ou pas) les informations du profil de l'utilisateur (la langue du site, le thème graphique, ce genre de chose) et le fait qu'il est bien connecté (son ID user et son niveau d'autorisations). Pour l'identification automatique... Attention, je pense que certains vont crier, mais il ne faut pas : stockez le login et le mot de passe CRYPTES dans un cookie et vérifiez si le cookie est présent lors de la visite de l'utilisateur (s'il n'est pas déjà connecté dans la session).
Quand je dis de crypter, j'entends par la l'utilisation de fonctions de cryptographie, pas de signature (hash md5, sha1). Non non, de la vraie cryptographie sur 256 bits, avec des algorithmes du niveau de ceux utilisés par les services secrets (oui, PHP fournit ça avec la bibliothèque mcrypt).
Je ne prétends pas que cela soit facile à implémenter, juste que c'est certainement bien plus sécurisé qu'une session avec un simple cookie.
Evidemment, il ne faut pas permettre à l'utilisateur de modifier son mot de passe ou son email, sans saisir son mot de passe en cours... Le mot de passe stocké dans le cookie n'est pas déchiffrable sans en connaître la clé privée (et cracker un mot de passe complexe sans la clé privée peut prendre des siècles, alors qu'avec le paradoxe des anniversaires, trouver un hash md5 ou sha1 qui convient pour un mot de passe, aussi complexe soit-il, permet de réduire ce temps à quelques jours voire quelques heures).
--
Neige
N'hésitez pas à lire la doc
TychoBrahe
Messages postés
1309
Date d'inscription
samedi 31 janvier 2009
Statut
Membre
Dernière intervention
5 juin 2013
12
17 oct. 2009 à 23:21
17 oct. 2009 à 23:21
Salut,
En effet tu as un bon point sur l'utilisation des cookie, par contre stocker des données sensibles (et par dessus tout prédictibles) est a mon sens une grande erreur. Il me parait bien plus sûr d'assigner à chaque compte une sorte d'identifiant non prédictible (par exemple un md5(microtime()) tant que cette valeur n'est pas déjà assignée à un compte) afin d'éviter toute attaque par prédicat sur ce que contient le cookie.
En effet tu as un bon point sur l'utilisation des cookie, par contre stocker des données sensibles (et par dessus tout prédictibles) est a mon sens une grande erreur. Il me parait bien plus sûr d'assigner à chaque compte une sorte d'identifiant non prédictible (par exemple un md5(microtime()) tant que cette valeur n'est pas déjà assignée à un compte) afin d'éviter toute attaque par prédicat sur ce que contient le cookie.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
neigedhiver
Messages postés
2480
Date d'inscription
jeudi 30 novembre 2006
Statut
Membre
Dernière intervention
14 janvier 2011
19
17 oct. 2009 à 23:46
17 oct. 2009 à 23:46
Justement : comment prédire le contenu d'un cookie quand celui-ci est chiffré de manière symétrique avec une clé privée ?
De toute façon, quoi que l'on stocke dans le cookie, le principe reste le même : y mettre une donnée qu'il n'est pas facile (tendre vers l'impossible) de prédire. Dans tous les cas, il est TOUJOURS possible de s'identifier si on laisse trainer le cookie sur un ordinateur public, ou si un "man-in-the-middle" s'amuse à intercepter le contenu des cookies stockés sur le client (il s'agirait alors d'un pirateur expérimenté dans le craquage de mots de passes gmail qui n'aurait vraiment rien d'autre à faire que s'attaquer à un site perso)
P.S. : pardon d'avoir utilisé l'anglicisme "crypter" au lieu de "chiffrer"... Je m'en veux, je m'en veux, oh lala, comme je m'en veux :)
--
Neige
N'hésitez pas à lire la doc
De toute façon, quoi que l'on stocke dans le cookie, le principe reste le même : y mettre une donnée qu'il n'est pas facile (tendre vers l'impossible) de prédire. Dans tous les cas, il est TOUJOURS possible de s'identifier si on laisse trainer le cookie sur un ordinateur public, ou si un "man-in-the-middle" s'amuse à intercepter le contenu des cookies stockés sur le client (il s'agirait alors d'un pirateur expérimenté dans le craquage de mots de passes gmail qui n'aurait vraiment rien d'autre à faire que s'attaquer à un site perso)
P.S. : pardon d'avoir utilisé l'anglicisme "crypter" au lieu de "chiffrer"... Je m'en veux, je m'en veux, oh lala, comme je m'en veux :)
--
Neige
N'hésitez pas à lire la doc