{PHP} cookie protégé [Résolu]

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 http://www.securiteinfo.com/conseils/cookies.shtml te conseillera et t'orientera peut-être sur la solution.

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() ?

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 http://www.developpez.net/... a l'air de proposer une solution qui a l'air de marcher.

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.

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.

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?

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)

Ok, donc niveau sécurité, le mieux c'est de ne rien faire.

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).

Ok merci pour tout :)