Forum d'entraide PHPFrance

Bonjour à tous,

Maintenant que mon forum fonctionne correctement, je m'occupe de la partie des membres.

Mais j'aimerais sécurisé un peu le tout.
En session, je fais passer le pseudo, le groupe et l'id du membre, mais c'est pas vraiment sécurisé comme méthode, puisque je n'identifie le membre qu'avec l'id.

Donc j'ai pensé à ajouter le mot de passe crypté dans la session, mais c'est pas conseillé du tout, et j'ai compris pourquoi.

Alors j'ai vu une méthode consistant à brouiller les pistes en ajoutant des trucs aléatoires.

J'en suis arrivé à faire un truc de ce genre :

xxx = chaine de caractères aléaoire(7) + mot défini + chaine de caractères aléatoire(6) + id du membre + chaine de caractères aléaoire(9)

J'enregistre ceci tel quel dans un champ de ma table, et je le crypte en sha1() dans la variable de session, et si le membre veut par exemple modifier son profil, je vérifies si sur une même ligne de la table si l'id, le pseudo, et la valeur de session[xxx] est égal au sha1() du champ.

Voilà, n'y connaissant pas grand chose en sécurité des sessions, j'aimerais un avis pour savoir si c'est assez fiable comme méthode.

Merci.

Tu risques fort d'avoir une surprise : si la chaine aléatoire est différente à chaque nouvelle connexion du membre (ce qui serait logique), ta chaine ne correspondra plus dès la seconde connexion... et le membre devra s'inscrire à nouveau.

Oui, elle sera différente à chaque connexion, mais la table sera également mise à jour à lors de cette nouvelle connexion.

Ca ne va pas ?

Pour la perte de mot de passe, je vais bien sûr mettre un espace prévu pour.

les sessions sont sécurisées... c'est des coockies stockée SUR LE SERVEUR

quel interet de garder le mot de passe quand l'utilisateur est loggé ?

Niet, les cookies de session son envoyés au navigateur sauf si ce dernier est configuré pour les refuser auquel cas, il faut espérer que la configuration du serveur permet de passer l'identifiant de session via l'url et dans ce cas effectivement le cookie sera conservé coté serveur.

Ceci dit, première règle de sécurité : ne JAMAIS garder un mot de passe en variable de session ni dans aucune autre variable du reste.

les sessions sont sécurisées... c'est des coockies stockée SUR LE SERVEUR

quel interet de garder le mot de passe quand l'utilisateur est loggé ?

Mais je ne stocke pas le mot de passe dans une variable, je veux juste identifier un utilisateur autrement que juste par un nombre représentant l'id de la table.

A moins que l'on me dise qu'un numéro seul, c'est suffisament sûr.

Si on prend le problème à l'envers, comment un utilisateur peut-il s'enregistrer et lancer une session ? en passant par un script, qui lui est protégé, en utilisant un mot de passe, non ? si le script de connexion est suffisament "robuste" il n'y a pas de nécessité de conserver le mot de passe en session.

Pour ceux qui se demandent pourquoi une variable privée ne doit jamais être stockée en session (il y a lieu de se poser la question : une variable de session passe du serveur au serveur, elle ne transite jamais sur le réseau et n'est donc pas susceptible d'être interceptée !), je vous invite à consulter les fichiers de session créées sur le serveur, en voici un exemple : Qui correspond à

$_SESSION = array(
  'counter' => 67,
  'login' => "naholyr",
  'id' => 1
);

Toutes les données y apparaîssent en clair, et si jamais l'un de ces fichiers pouvait être récupéré, ce serait donc le drame si parmi elles se trouve un mot de passe
Il s'agit donc comme toujours d'une précaution qui ne prend sa valeur que dans le cas d'un piratage du serveur, mais c'est à ne pas négliger.

Voilà, c'était juste histoire de justifier ces conseils que vous entendez souvent sans les remettre en question mais sans les comprendre.

Pour le problème initial, je plussoie iclo. Mais si tu veux vraiment conserver plus d'infos dans ta session, a priori tu as conservé des données dans ta base (vraisemblablement md5(password), éventuellement si tu as été prudent md5(sel.password)), tu peux très bien trimballer la même donnée, ça ne sera pas moins sécurisé pour autant.