Il faut faire attention avec les problemes de securite.
Tout d'abord, les problemes des snifeurs, a moins d'avoir un certificat ssl sur le site est d'etre en https, les informations transmittent en clair. Et pas besoin qu'elles soient dans un cookie. Lors de la validation du formulaire de login, les infos sont trasmises en clair.
Ensuite vient le probleme du "relogin" automatique.
Certes cela peut etre util, mais cela est egalement un risque supplementaire.
Eh oui, au moins dans le cadre d'une procedure de login normale, la personne doit connaitre le mot de passe pour se loger. Car le mot de passe qu'elle va introduire va etre ensuite hache puis compare au hashage qui se trouve dans la base.
Or si l'on utilise un cookie, on va bruler une etape. L'utilisateur n'aura pas a rentrer de mot de passe, car le hashage se trouve dans le cookie.
Malheureusement, un cookie n'est pas infalible. Il suffit que ce dernier soit compromis, pour que n'importe qui puisse l'utiliser et se loguer sur le site.
Il suffit par exemple de voler le cookie si c'est possible (les cookies sont rarement "proteges" ). On peut tres bien utiliser un snifer pour recuperer le hachage pour ensuite forger un cookie avec ce dernier.
Meme si les mots de passe ne sont pas stockes en clair dans la BDD, il suffit que le site soit vulnerable a une attaque de type "SQL injection" pour que quelqu'un puisse afficher le contenu de la table des logins. Bien qu'il n'ai access qu'aux hachages, il pourra les utiliser par la suite en forgeant un cookie et en utilisant le systeme de "relogin" automatique (vous vous souvenez, celui qui rend la vie plus facile ...).
Au moins, sans un systeme de relogin automatique, la personne doit rentrer le password (et non le hash) pour pouvoir passer... (Bon, ok, le probleme est plus embetant si le password est snife car il n'est pas protege, mais il est "plus facile" de faire une attaque de SQL injection que d'aller snifer les paquets chez quelqu'un)