{PHP} cookie protégé
Résolu/Fermé
okuni
Messages postés
1221
Date d'inscription
jeudi 4 septembre 2008
Statut
Membre
Dernière intervention
2 janvier 2014
-
27 juil. 2009 à 18:44
okuni Messages postés 1221 Date d'inscription jeudi 4 septembre 2008 Statut Membre Dernière intervention 2 janvier 2014 - 27 août 2009 à 09:02
okuni Messages postés 1221 Date d'inscription jeudi 4 septembre 2008 Statut Membre Dernière intervention 2 janvier 2014 - 27 août 2009 à 09:02
A voir également:
- {PHP} cookie protégé
- Easy php - Télécharger - Divers Web & Internet
- Cookie manager - Télécharger - Confidentialité
- Php natif - Forum PHP
- Comment récupérer mon jeu cookie jam - Forum jeux en ligne
- Supprimer cookie - Guide
11 réponses
okuni
Messages postés
1221
Date d'inscription
jeudi 4 septembre 2008
Statut
Membre
Dernière intervention
2 janvier 2014
126
28 juil. 2009 à 13:14
28 juil. 2009 à 13:14
Merci beaucoup pour la source :)
Peut-tu me dire comment crée-t-on un algorithme de cryptage ou s'il existe d'autre fonction comme crypt() ?
Peut-tu me dire comment crée-t-on un algorithme de cryptage ou s'il existe d'autre fonction comme crypt() ?
Oui maintenant, faut pas être paranoïaque non plus.
Si ca reste un site perso, y a pas de soucis, de plus le vol de cookies ca ne se fait pas comme ça. Assure toi de ne pas avoir de failles (Notamment en ce qui concerne les injections de scripts, bien utiliser htmlenties pour l'affichage, vérifier l'utilisation que tu fais de tes GET, toussa toussa...).
Même si tu te contentes d'utiliser la toute première solution que j'ai cité et de bien vérif' ce que j'ai dis, alors très franchement les risques de hack sont presque inexistant.
Je dirais que ca dépend pas mal du site que tu comptes faire (A la limite bloque la case "Se souvenir de moi" pour les admins, on sait jamais).
Si ca reste un site perso, y a pas de soucis, de plus le vol de cookies ca ne se fait pas comme ça. Assure toi de ne pas avoir de failles (Notamment en ce qui concerne les injections de scripts, bien utiliser htmlenties pour l'affichage, vérifier l'utilisation que tu fais de tes GET, toussa toussa...).
Même si tu te contentes d'utiliser la toute première solution que j'ai cité et de bien vérif' ce que j'ai dis, alors très franchement les risques de hack sont presque inexistant.
Je dirais que ca dépend pas mal du site que tu comptes faire (A la limite bloque la case "Se souvenir de moi" pour les admins, on sait jamais).
Bonjour,
Je pense que la personne voulait parler de cryptage du mot de passe, pour éviter que le mot de passe ne soit stocké en clair dans le cookie.
Je n'ai pas de solution toute faite en main concernant le chiffrement, mais je peux m'empêcher de conseiller de ne pas stocker le mot de passe dans un cookie, c'est une faille assez grosse. Pour moi un cookie protégé est un cookie qui n'existe pas.
ce site https://www.securiteinfo.com/conseils/cookies.shtml te conseillera et t'orientera peut-être sur la solution.
Je pense que la personne voulait parler de cryptage du mot de passe, pour éviter que le mot de passe ne soit stocké en clair dans le cookie.
Je n'ai pas de solution toute faite en main concernant le chiffrement, mais je peux m'empêcher de conseiller de ne pas stocker le mot de passe dans un cookie, c'est une faille assez grosse. Pour moi un cookie protégé est un cookie qui n'existe pas.
ce site https://www.securiteinfo.com/conseils/cookies.shtml te conseillera et t'orientera peut-être sur la solution.
le cryptage n'est pas une mince affaire et je ne suis pas du tout spécialisé dans ça.
Pour faire simple: il existe 2 types de cryptages: le réversible et l'irreversible. Le réversible est généralement créé à partir d'une clé de cryptage (un code, un certificat...). C'est idéal pour crypter un fichier pour que personne ne puisse le lire autrement. Et en temps voulu on peut le décrypter avec la clé de cryptage.
Le cryptage irréversible a l'avantage d'être (normalement) inviolable. Si on a la partie cryptée, il ne sera pas possible de revenir au code initial.
Dans ton cas je pense que la méthode irréversible est préférable. il suffit de faire les tests de concordance des mots de passe avec la version cryptée.
Pour cela, il existe des algorithmes de hachage tout fait, qui remplissent un rôle de cryptage irréversible.
Ainsi, le plus connu et le plus simple est le hachage MD5. Seulement, il devient vieux et n'est plus aussi sûr. il est possible de retrouver les mots de passe simple à partir de son empreinte (la version cryptée du mot de passe).
Au lieu du MD5, qu'il faut éviter pour crypter des mots de passe, je te propose le hachage SHA-256, considéré comme un des plus sûrs.
Je n'ai pas de solution toute prête et déjà testée de hachage SHA-256 en PHP, mais ce forum https://www.developpez.net/forums/d401955/php/langage/systeme-mise-place-sha-256-a/ a l'air de proposer une solution qui a l'air de marcher.
Pour faire simple: il existe 2 types de cryptages: le réversible et l'irreversible. Le réversible est généralement créé à partir d'une clé de cryptage (un code, un certificat...). C'est idéal pour crypter un fichier pour que personne ne puisse le lire autrement. Et en temps voulu on peut le décrypter avec la clé de cryptage.
Le cryptage irréversible a l'avantage d'être (normalement) inviolable. Si on a la partie cryptée, il ne sera pas possible de revenir au code initial.
Dans ton cas je pense que la méthode irréversible est préférable. il suffit de faire les tests de concordance des mots de passe avec la version cryptée.
Pour cela, il existe des algorithmes de hachage tout fait, qui remplissent un rôle de cryptage irréversible.
Ainsi, le plus connu et le plus simple est le hachage MD5. Seulement, il devient vieux et n'est plus aussi sûr. il est possible de retrouver les mots de passe simple à partir de son empreinte (la version cryptée du mot de passe).
Au lieu du MD5, qu'il faut éviter pour crypter des mots de passe, je te propose le hachage SHA-256, considéré comme un des plus sûrs.
Je n'ai pas de solution toute prête et déjà testée de hachage SHA-256 en PHP, mais ce forum https://www.developpez.net/forums/d401955/php/langage/systeme-mise-place-sha-256-a/ a l'air de proposer une solution qui a l'air de marcher.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
okuni
Messages postés
1221
Date d'inscription
jeudi 4 septembre 2008
Statut
Membre
Dernière intervention
2 janvier 2014
126
28 juil. 2009 à 15:59
28 juil. 2009 à 15:59
Ha, j'aurais plutot dis qu'il me fallais un mode de cryptage réversible pour crypter mon cookie pour le protéger et ensuite le décrypter pour afficher par exemple les identifiants et mdp de l'utilisateurs sur mon site pour qu'il puisse se connecter directement.
Merci pour la doc :)
Je vais lire attentivement ça.
Merci pour la doc :)
Je vais lire attentivement ça.
okuni
Messages postés
1221
Date d'inscription
jeudi 4 septembre 2008
Statut
Membre
Dernière intervention
2 janvier 2014
126
1 août 2009 à 13:27
1 août 2009 à 13:27
UP :)
C'est pas une très bonne idée de l'enregistrer dans un cookie.
En tout cas, il te faut bien un cryptage irréversible (hashage). Lors de l'inscription, le membre enregistre un mdp crypté dans la BDD (Tu dois hasher le mdp avant de l'enregistrer dans la BDD). Par conséquent tu as juste à vérifier que le hash dans ton cookie correspond à celui de ta BDD.
En tout cas, il te faut bien un cryptage irréversible (hashage). Lors de l'inscription, le membre enregistre un mdp crypté dans la BDD (Tu dois hasher le mdp avant de l'enregistrer dans la BDD). Par conséquent tu as juste à vérifier que le hash dans ton cookie correspond à celui de ta BDD.
okuni
Messages postés
1221
Date d'inscription
jeudi 4 septembre 2008
Statut
Membre
Dernière intervention
2 janvier 2014
126
24 août 2009 à 18:39
24 août 2009 à 18:39
Ok je vois mais si on met le code en hash dans le cookie, forcément, si je test pour voir si le code est bon, je ne peux pas hasher le code puisqu'il est déjà hashé donc c'est comme s'il était en clair.
Commet protéger le "lien" entre le cookie contenant le hash et la bdd pour récupérer les info du membre?
Commet protéger le "lien" entre le cookie contenant le hash et la bdd pour récupérer les info du membre?
En effet la méthode que j'ai décrite hier comporte une assez grosse faille : Lors d'un vol de cookies, il suffit de réutiliser celui-ci pour être identifié directement.
Personnellement, je n'utilise jamais de cookies pour sauvegarder des données sensibles, donc je n'ai jamais vraiment pensé au problème. Mais dans le lien proposé par Madien, tu as un élément de réponse : utiliser un ID de session (aléatoire de préférence).
Tu génères un nombre aléatoire (Un grand nombre, à la limite crypte le, ca évitera que quelqu'un tente des nombres au pif ^^) que tu enregistres dans un cookie et dans ta BDD. Et tu changes cet ID de session à chaque requête HTTP (Tu le cases au début de chacune de tes pages en gros). Donc en principe, un cookie n'est utilisable au final qu'une fois. Par conséquent s'il y a vol de cookie, il suffira au visiteur de se reconnecter (ou de recharger une page si le cookie n'a pas été utilisé) pour rendre le cookie volé inutilisable. Mais c'est quand même une requête de plus à chaque chargement de page, ca fait lourd, surtout avec beaucoup de membres.
Maintenant si tu utilises les cookies pour reconnaitre un membre, tu prends obligatoirement le risque qu'il y ai un vol de compte. Il n'existe pas (A ma connaissance en tout cas...) de méthode sûre à 100% avec les cookies.
Pas pour rien que beaucoup de site n'utilise pas de cases "Se souvenir de moi", en particulier les sites de jeux à la Ogame ou encore les banques.
Soit dit en passant, beaucoup de site même très connu, se contente d'utiliser la méthode que j'ai décrite hier sans utiliser de protection. ;o)
Personnellement, je n'utilise jamais de cookies pour sauvegarder des données sensibles, donc je n'ai jamais vraiment pensé au problème. Mais dans le lien proposé par Madien, tu as un élément de réponse : utiliser un ID de session (aléatoire de préférence).
Tu génères un nombre aléatoire (Un grand nombre, à la limite crypte le, ca évitera que quelqu'un tente des nombres au pif ^^) que tu enregistres dans un cookie et dans ta BDD. Et tu changes cet ID de session à chaque requête HTTP (Tu le cases au début de chacune de tes pages en gros). Donc en principe, un cookie n'est utilisable au final qu'une fois. Par conséquent s'il y a vol de cookie, il suffira au visiteur de se reconnecter (ou de recharger une page si le cookie n'a pas été utilisé) pour rendre le cookie volé inutilisable. Mais c'est quand même une requête de plus à chaque chargement de page, ca fait lourd, surtout avec beaucoup de membres.
Maintenant si tu utilises les cookies pour reconnaitre un membre, tu prends obligatoirement le risque qu'il y ai un vol de compte. Il n'existe pas (A ma connaissance en tout cas...) de méthode sûre à 100% avec les cookies.
Pas pour rien que beaucoup de site n'utilise pas de cases "Se souvenir de moi", en particulier les sites de jeux à la Ogame ou encore les banques.
Soit dit en passant, beaucoup de site même très connu, se contente d'utiliser la méthode que j'ai décrite hier sans utiliser de protection. ;o)
okuni
Messages postés
1221
Date d'inscription
jeudi 4 septembre 2008
Statut
Membre
Dernière intervention
2 janvier 2014
126
26 août 2009 à 21:03
26 août 2009 à 21:03
Ok, donc niveau sécurité, le mieux c'est de ne rien faire.
okuni
Messages postés
1221
Date d'inscription
jeudi 4 septembre 2008
Statut
Membre
Dernière intervention
2 janvier 2014
126
27 août 2009 à 09:02
27 août 2009 à 09:02
Ok merci pour tout :)
