8800 sujets

Développement web côté serveur, CMS

Bonjour,

J'espére ne pas répetter de théme existant, mais je n'ai pas trouvé de réponses claires malgrés la banalité du sujet.

Mon interface n'est pas pour une banque, donc pas de gros risques, mais je voudrait pas non plus faire n'importe quoi. J'ai déja eu des pub pour du viagra ou des sites pornos dans un article de cms, c'est pas super...

Donc jusquelà soit c'est le cms qui gérer le truc soit je faisait un systéme de login sans cookie, uniquement avec des sessions donc pas de probléme.

Maintenant je voudrais faire un systéme d'authentification qui garde en mémoire les visiteurs, mais j'ai quelques doutes :

Voilà comment je procéde :

j'ai une table users avec : id, nom, login, password, status, session

1. je test si le cookie (cripté) correspond à la session par un requete a la table user, si c'est bon on vat pas plus loin l'user est connecté. ensuite un session est créé pour passer de page un page sans requetes mysql

2. pas de cookie, le visiteur envoie sont login et son pass, si ils sont bons ont creer a partir du password cripté et md5 une session et un cookie, et on met a jour le champ session avec ce code.

J'ai bon?

Pour préciser, comment generer un cookie le plus indéchifrable possible, mais reconnaissable par le script?

Est ce une bonne idée de stocker la session sur la table user?

De cette maniére il me semble que sauf récuperation du cookie, on ne peut pas s'authentifier, mais ai je oublier quelquechose?
Modifié par matmat (03 Nov 2007 - 05:31)
Salut,

Personellement je vois pas trop l'intérêt de stocker d'id de session dans la table, sauf peut-être si tu as peur que ton visiteur ne puissent pas accepter les coockies.

Mais dans la mesure ou c'est une admin de CMS je pense que tu peux imposer quelques aspects de configuration au client, dont l'acceptation des coockies et du javascript, par exemple.

Sinon, pour créer un coockie le plus indéchiffrable possible il y a effectivement la possibilité de hashé des données en md5 et de faire un petit contrôle à la suite.

A+
ce que je ne comprend pas, c'est que si tu ne stocke pas le numero de session (ce n'est pas l'id c'est le code de session cripté) comment tu reconnais le visiteur quand tu lis le cookie
Ce que tu fais, c'est au début de ta page tu fais ceci :

SI session existe pas
      SI coockie existe
          on vérifie l'utilisateur et on lance une session et on affiche la page
      SINON
         On renvoi vers le formulaire d'authentification
      FIN SI
SINON
      On affiche la page
FIN SI

Modifié par Hacken (03 Nov 2007 - 19:11)
a écrit :
[b]on vérifie l'utilisateur[/b] et on lance une session et on affiche la page


Comment verifies tu qui est l'utilisateur?

Pour l'intant ce que je fais c'est que quand je crée le cookie et la session, j'enregistre en même temps cette valeur dans ma table user et ensuite je la compare au cookie quand celui-ci revient.
Modifié par matmat (03 Nov 2007 - 20:05)
Ton coockie il te permet de réconnaitre l'utilisateur afin de l'éviter de retaper son mot de passe ou autre non ?

Eh bien, dans ce coockie tu peux mettre plusieurs valeur hashé en md5 par exemple.

Entre autre tu mets le nom d'utilisateur et pourquoi pas le mot de passe tout cela hasé en MD5, quand il revient sur le site, si la valeur de son coockie correspond au valeurs de ta base de donnée hashé en md5 alors c'est un utilisateur connu de toi, alors il te suffira de faire une session d'utilisateur enregistré.

A+
Hello !

Désolé de déterrer un vieux topic mais je suis en plein dedans aussi.
Moi j'ai lu à plusieurs reprises que ce n'était pas une bonne idée sur le plan de la sécurité de stocker un mot de passe dans un cookie, même crypté.

Donc pour éviter de stocker cette information ne serait-ce pas une bonne solution que d'utiliser un code généré aléatoirement lors d'une connexion et le stocker dans la base de données et dans un cookie pour les comparer à chaque fois que le visiteur revient sur le site et que sa session est périmée ?

Ou alors y a-t-il une autre solution ? Smiley murf

Merci pour votre aide ! Smiley cligne
Salut,

CrazyCow a écrit :

Moi j'ai lu à plusieurs reprises que ce n'était pas une bonne idée sur le plan de la sécurité de stocker un mot de passe dans un cookie, même crypté.
C'est vrai (même si les mots de passe sont plutôt hashés - md5, sha256... - que cryptés) sauf qu'à priori la possibilité d'être reconnecté automatiquement est réservée à des sites pour lesquels la sécurité n'est pas primordiale (typiquement un forum).


CrazyCow a écrit :

Donc pour éviter de stocker cette information ne serait-ce pas une bonne solution que d'utiliser un code généré aléatoirement lors d'une connexion et le stocker dans la base de données et dans un cookie pour les comparer à chaque fois que le visiteur revient sur le site et que sa session est périmée ?
Ben du coup le problème est le même puisqu'il s'agit d'un cookie qui contient une valeur suffisante pour se faire "hacker". Smiley murf


CrazyCow a écrit :

Ou alors y a-t-il une autre solution ?
Ne pas permettre cette fonctionnalité ("se souvenir de moi") et obliger le visiteur à ressaisir login et mot de passe à chaque fois. Smiley cligne