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