Reprise du message précédent :
Les infos sont stockées en session
 
Les cookies servent à mémoriser la session pour pouvoir se relogguer plus tard, mais ils servent aussi pour des services disponibles sur le site comme le micropaiement.

 
ca m'étonne que tu puisses faire ca puisque les sessions sont détruites au bout d'un moment imparti.
 
en général les script d'autolog, enregistre des information qui permettent de recommencer le processus de log sans l'intervention de l'utilisateur mais pas en relancant une ancienne session ?

Oui, c'est ce que je voulais dire : il sert à stocker les données nécessaires à la session

alors on est d'accord

les controles sur l'adresse IP ne sont pas une solution, c'est se fermer tous les utilisateurs passant par des proxy... AOL entre autres
 
sans les cookies il n'y a pas de vraie solution miracle malheureusement, puisque tout ce que peut envoyer le navigateur (ip, referer...) peut se falsifier

Alors il n'y a pas de solution miracle du tout vu que même les cookies sont falsifiable. (sic)

dans le cookie, tu peux stocker, login et mot de passe crypté
 
là la seule faille que tu aies c'est que l'utilisateur se fasse voler son cookie.
Cependant il sera loggué mais il ne pourra pas retrouver le mot de passe.
 
petite info pour crypter un pass, une bonne technique est de faire ça :
 
$pass_crypte = sha1('unephrasesuperlongueavecdescaracteresbidons'.$_POST['pass']);
 
comme ca la phrase super longue y'a que toi qui la connait et tu peux pas lancer une bruteforce sur le pass crypté comme ca.

la phrase super longue peut être connu, c'est pas un probleme. C'est pas vraiment une protection contre la brute force, mais contre des dictionnaires préparés à l'avance.
 
Par exemple, un mec avec bcp de tps peut se générer un dictionnaire traduisant tous les mots possibles en leur équivalent md5. Avec un md5, il te retrouve donc immédiatement le pass.
Par contre si tu concatenes le pass avec un mot de ton choix quand tu le passes en md5, il devra se refaier tout un dictionnaire en prenant en compte ton mot ajouté. Ce qui est incroyablement long.
 
Donc concatener à un mot de ton choix quand tu crypte, c'est bien efficace, mais le mot peut être connu, c'est pas un probleme

Djebel1, c'est bien ce que je disais, il ne faut pas que le pass crypté simple se retrouve dans le cookie.
 
Avec un md5, il te retrouve donc immédiatement le pass.
--> c'est pour ca qu'il faut pas crypter que le pass mais $pass.$chaine

"comme ca la phrase super longue y'a que toi qui la connait "
c'est par rapport à ça que je réagissais. Tout le monde peut la connaitre la phrase, c'est pas la mort, même si je vois pas l'intéret de la faire connaitre
 
juste pour dire que c'est pas un élément à sécuriser quoi
 
edit : et je voulais préciser que ça protège en rien contre la brute force (sauf si tu lances ta brute force avec un dico de mots usuels, mais bon la brute force c'est aussi tester toutes les combinaisons de mots possibles)

perso je crypte :
 
$motdepass.chaine.adresseip
et le tour est joué

et si il revient avec une autre ip, son mot de passe est invalide.
quelle bonne idée  

C'est justement l'intérêt

???
 
génial. Donc quand mon ip change (parce que j'ai pas d'ip fixe), je suis bon pour me récrééer un compte ??
 
Edit: bon ok, c'était juste pour dans le cookie. Mais ca veut quand même dire que si j'ai pas une connexion permanante, le bouton "Remember me" ne marchera pas. Concretement, ca voudrait dire me logguer chaque fois que je me reconnecte.
 
et encore plus marrant, au taf on a deux fournisseurs, deux proxy, et je sais pas a l'avance quel fai va être utilisé, ca dépends de la charge et de plein d'autres trucs. Donc dans une même sessions, je peux me présenter avec deux ip différentes.

 
hum... j'avais pas pensé à ça.
Mais alors il n'y a pas de solution à ce probleme...
 
Si on ne concerve pas l'ip, on retrouve le probleme que j'evoquais plus haut.
Si on la concerve, les utilisateurs sans ip fixe sont obligés de se relogués tout le temps...

mais si on t'a dit, dans ton cookie tu stockes login ou l'id_user et une clé d'identification par ex (qui n'est pas obligatoirement un mot de passe, mais une clé générée lors de la création du compte)
 
ensuite sur ton site pr l'autologin tu tests si tu as un cookie  
 
si oui tu relances ta procédures de login avec  
 
SELECT * FROM users WHERE id_user=$_COOKIE[''] AND verif_key=$_COOKIE[''];
 
si ta requete s'execute tu reprend tes données que tu mets en session et ton user est encore loggué.
 
En fiat l'autolog va relogguer ton user sans qu'il ait à faire quoi que ce soit. Ca fonctionne comme ca. Apres pour voler sa session, il faut voler son cookie. Si tu crains ca, pour modifier les informations dans son compte par ex, tu peux le faire valider les formulaires par son mot de passe. Si qqn vole son cookie il sera loggué à sa place, mais il n'aura pas son mdp.
 
++

Stocker un username et quelques parametres sans importance dans un cookie pourquoi pas.  
Mais stocker des mots de passe, permettre un processus d'authentification complet ("auto-login" ) c'est pas tres malin...
 
 

 
Vieux motard...