Gestion des cookies

a marqué ce sujet comme résolu.
Auteur du sujet

Bonsoir les amis j’ai fini de réaliser mon site et j’ai une question a vous poser sur la gestion des cookies.

  • Lorsque mon utilisateur se connecte je crée un cookie pour celui ci
  • Le cookie contient son login, id de l’utilisateur, password, info1 et info2
  • Lors d’une nouvelle connexion je vérifie s’il existe des cookies.
  • Puisque les cookies peuvent être modifié je vérifie dans ma BD si toutes les informations en haut correspondent aux informations d’un utilisateur.
  • Si oui il se connecte
  • Sinon nouvelle connexion

Est-ce une bonne manière de faire? Le fait de mettre le mot de passe dans un cookie ne crée t-il un problème de sécurité?

Nb: le mot de passe est haché.

Merci pour vos différentes réponses

À la recherche de la connaissance.

+0 -0

Le fait de mettre le mot de passe dans un cookie ne crée t-il un problème de sécurité? Nb: le mot de passe est haché.

Je pense que c’est une mauvaise habitude. Stocke plutôt les hash dans une base de donnée, sinon les pirates ayant accès via le cookie au hash, pourront essayer de le cracker par brute-force ou rainbow-tables.

Puis, pour se connecter, tu dois sûrement déjà avoir stocké le mot de passe dans une base de donnée. Fais bien attention à ne pas stocker le mot de passe en clair, utilise plutôt une fonction de hash cryptographique sécurisée.

En savoir plus si tu utilises PHP : https://www.php.net/manual/fr/function.password-hash.php

+0 -0

Salut !

Non, pas totalement.

password_hash() génère automatiquement un sel qui est utilisé avant le hachage. Ainsi, si tu appelles la méthode deux fois de suite avec le même mot de passe, le résultat sera différent (d’où le besoin d’utiliser password_verify() et non plus de comparer simplement deux résultats de password_hash()), ce qui rend plus difficile la rétro-ingénierie d’un mot de passe haché, et même sur un lot.
Avec un algorithme comme SHA-256, sans sel que tu génères et appliques toi-même — ce qui est relativement fastidieux et inutile suivant comment c’est implémenté —, le résultat sera toujours le même.

Après, un des avantages du couple password_hash()/password_verify() est qu’il va automatiquement prendre une méthode qui soit considérée comme sûre parmi ce que propose le serveur, tout en étant capable de gérer d’autres méthodes si besoin. Si l’algorithme change selon la version de PHP ou le serveur, les données de connexion fonctionneront toujours, et les nouveaux mots de passe seront enregistrés avec le nouvel algorithme.

Édité par Ymox

Evitez qu’on vous dise de les lire : FAQ PHP et SymfonyTutoriel WAMP • Cliquez 👍 pour dire merci • Marquez vos sujets résolus

+2 -0

Cette réponse a aidé l’auteur du sujet

Salut watanga96,

Est-ce une bonne manière de faire?

Non.

Le fait de mettre le mot de passe dans un cookie ne crée t-il un problème de sécurité?

Oui, le mot de passe, même hashé, ne devrait jamais être stocké en dehors de la base de donnée !

Je ne suis pas spécialiste de la question mais une meilleure manière de faire est de générer une chaine de caractères aléatoire lors de la première connexion de l’utilisateur. Côté client, tu mets cette chaine dans ton cookie de connexion. Côté serveur, tu associes l’utilisateur à cette chaine de caractère dans une base de donnée, dans un système de cache ou autre. Quand l’utilisateur se déconnecte, ou après une certaine durée (quelques semaines), tu supprimes cette chaine de caractère et l’utilisateur devra se reconnecter. Par exemple, sur Zeste de Savoir, le cookie de connexion est nommé sessionid et contient une chaine de caractère semblable à f4wjbusf3azxn02fzishkd5vxtclnsax. Je te conseille de ne pas essayer de réinventer la roue, c’est un mécanisme nécessaire à tous les sites web donc tu devrais pouvoir trouver une bibliothèque qui gère ça de la meilleure des manières.

+2 -0

Cette réponse a aidé l’auteur du sujet

En fait, en stockant un identifiant de session dans le cookie et les données de session côté serveur, tu as une garantie que l’utilisateur ne pourra jamais accéder aux données de session (potentiellement confidentielles ou à risque, comme les mots de passe). C’est donc une sécurité bien plus forte que de stocker des données directement dans un cookie.

C’est d’ailleurs ce que fait PHP automatiquement quand tu utilises $_SESSION.

En mettant directement les données dans le cookie, si l’utilisateur est piraté, ses données sont compromises car les cookies sont stockés en clair par le navigateur. De plus, ça favorise le vol de session par vol de cookies, alors qu’en passant par un identifiant tu peux t’en prémunir. Enfin, ça évite que quelqu’un puisse forger un cookie avec des données spécifiques dedans, permettant par exemple d’exploiter une éventuelle faille pour se faire passer pour un autre utilisateur en modifiant l’identifiant dans le cookie. Si tu stockes les données côté serveur, il ou elle ne pourra jamais faire ça.


J’ajouterai au passage, concernant sha256 même salé versus bcrypt (qui est le nom de l’algorithme derrière password_hash de PHP, que tu peux retrouver partout) — bcrypt est conçu pour hacher des mots de passe de façon sécurisée, et est donc :

  • salé par défaut, tu n’as généralement même pas à t’en soucier ;
  • conçu pour être évolutif, comme mentionné plus haut il permet très facilement de prendre au moment du hachage l’algo le plus efficace du moment tout en pouvant vérifier les anciennes empreintes de mot de passe ;
  • lent (oui, c’est une qualité), afin qu’il soit compliqué de tester tout plein de mots de passe hachés d’un coup pour casser un mot de passe par force brute. Ainsi, avec bcrypt tu peux faire quelque chose comme 4 empreintes par seconde sur un ordinateur de bureau, versus des millions avec sha256.

Au contraire, justement, sha256 n’a pas été conçu pour les mots de passe, mais pour vérifier l’intégrité de fichiers (usage de somme de contrôle). Par conséquent, il n’a pas tous ces avantages :

  • il ne gère pas de sel ;
  • il ne gère pas de passage à un système plus performant, vu que dans son cadre d’usage ça n’a pas vraiment de sens, il n’y a pas de problématiques de sécurité quand on calcule des sommes de contrôle de fichiers ;
  • il est conçu pour être le plus rapide possible, afin de vérifier l’intégrité de très gros fichiers avec de bonnes performances — ce qui permet, si utilisé pour des mots de passe, de faire des attaques par force brute performantes (oops).

En bref, dans le doute, utilise bcrypt. Et si tu ne doutes pas, utilise bcrypt quand même.

#JeSuisArius

+2 -0

Mais selon vos expériences combien doit durer un cookie avant qu’on ne demande a l’utilisateur de se reconnecter?

Je n’ai pas d’expérience dans ce domaine donc je ne saurais pas te répondre, mais par exemple Zeste de Savoir utilise une durée d’environ un mois.

+1 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte