Discussion :

[Alain15]

Bonjour,

je suis entrain de réaliser un site pro pour moi...

J'ai cependant une question, je fais un formulaire d'inscription, d'abord je test les champs en javascript et j'avertis l'utilisateur au fur et à mesure si il y a un problème mais comme je sais qu'on peut désactiver le javascript, je fais aussi les verifis en php par la suite...

Pensez vous qu'il faut faire les verifications avec le javascript et le php ou que avec le php??

Merci

[MasterOfChakhaL]

a priori, c'est a toi de décider...

pour le php, c'est nécessaire de faire les tests avant insertion en base (ou autre)
pour le javascript, ca t'évitera de faire un aller retour serveur avant d'indiquer l'erreur. Donc plus rapide pour l'utilisateur...

[spilliaert]

Tu peux toujours faire les deux...mais c'est quand même rare les gens qui désactivent javascript, non?

[MasterOfChakhaL]

ben, déjà, c'est pas si rare que ca...
les gens qui désactivent javascript sont plus nombreux que les gens qui utilisent autre chose que IE (je dis ca car je me souviens plus des chiffres)

Et de toutes facon, même si c'est rare, ca existe...
Il s'agit d'un site pro.
Quelqun de malveillant qui voudrait insérer n'importe quoi, a mon avis, le premier truc qu'il tente, c'est de désactiver javascript ou meme de se faire son formulaire perso...

Donc les vérif php, pour moi, c'est meme pas la peine d'en discuter, il faut les faire...

[Alain15]

OK merci

[kastha]

Y'a quelque chose d'embettant...
Exemple :
Javascript désactiver ...
Dans le formulaire, on cripte le mot de passe avec md5 avant de l'envoyer au serveur (donc avec du javascript).
Si le javascript est désactivé, le mdp n'est pas cripter et il est envoyé en clair... comment savoir si il est cripter par md5 ou pas avant de l'inscrire dans la bdd.

[Eusebius]

Y'a quelque chose d'embettant...
Exemple :
Javascript désactiver ...
Dans le formulaire, on cripte le mot de passe avec md5 avant de l'envoyer au serveur (donc avec du javascript).
Si le javascript est désactivé, le mdp n'est pas cripter et il est envoyé en clair... comment savoir si il est cripter par md5 ou pas avant de l'inscrire dans la bdd.

Là j'ai pas compris ton problème... C'est javascript qui chiffre ton mot de passe ???

[Alain15]

md5 ca crypté au niveau du php, je comprends pas le rapport avec le javascript

[jfjava2002]

et heuresement

j'imagine mal javascript encoder en md5 et le mot de passe envoyé en clair si js est désactivé !!

[kastha]

Ben d'après ce que j'ai lu, au lieu d'envoyer un mdp en "clair" avec un formulaire, on doit dabord le "cripter" avec le md5 (avec une fonction md5 javascript) et après l'envoyer serveur soit pour l'enregistrer dans la bdd(register) ou pour vérifier si il correspond au mdp en md5 déja enregistré dans la bdd(login).

Donc si le javascript est desactivé, pas de criptage en md5 et donc le mdp est envoyé en clair au serveur...

[Eusebius]

Ben d'après ce que j'ai lu, au lieu d'envoyer un mdp en "clair" avec un formulaire, on doit dabord le "cripter" avec le md5 (avec une fonction md5 javascript) et après l'envoyer serveur soit pour l'enregistrer dans la bdd(register) ou pour vérifier si il correspond au mdp en md5 déja enregistré dans la bdd(login).

Donc si le javascript est desactivé, pas de criptage en md5 et donc le mdp est envoyé en clair au serveur...

Non.
Je dirais, comme ça, au flair, que le mot de passe est envoyé en clair par le formulaire au script de traitement (par POST), qui le hashe.
Et avec du bol, tout ça se passe sous SSL2.

[jfjava2002]

pour crypter une chaine en php ca donne un truc dans le genre

$variable = md5($chaine);

Pas besoin du javascript et tout se fait du coté serveur

[MasterOfChakhaL]

Donc si le javascript est desactivé, pas de criptage en md5 et donc le mdp est envoyé en clair au serveur...

Ben justement...
c'est pour ca qu'il faut le faire côté serveur...
tu ne peux jamais présumer de l'utilisateur, donc dès que tu veux faire de l'insertion de données... il faut faire le traitement côté serveur....

Si tu as un utilisateur qui s'inscrit avec un navigateur qui fait le javascript et qu'ensuite il veut venir se logger depuis un navigateur où le javascript est désactivé...
Que penses-tu qu'il va se passer???

le cryptage, ca sert surtout si qqun vient fouiner dans ta base...
si il y a interception lors de l'envoi du mot de passe, qu'il soit crypté ou non, le méchant n'a qu'à renvoyer ce qu'il a intercepté de toutes facons...
pour éviter que le mot de passe soit intercepté, il n'y a que le https me semble-t-il...

[ePoX]

Et puis de toute façon si tu chiffres le mot de passe coté client et qu'il se fait sniffer. Il ne faudra pas bien longtemps pour le cracker à coup de brute force.

[Eusebius]

Et puis de toute façon si tu chiffres le mot de passe coté client et qu'il se fait sniffer. Il ne faudra pas bien longtemps pour le cracker à coup de brute force.

Même pas besoin : tu renvoies directement le mdp chiffré, pour un rejeu bête et méchant.
Un peu comme s'il n'était pas chiffré

Comme il a été dit plus haut, le hachage du mot de passe, c'est pour éviter qu'il soit stocké en clair dans la base, pas pour sécuriser le dialogue entre client et serveur.

[kastha]

Ben justement...
le cryptage, ca sert surtout si qqun vient fouiner dans ta base...
si il y a interception lors de l'envoi du mot de passe, qu'il soit crypté ou non, le méchant n'a qu'à renvoyer ce qu'il a intercepté de toutes facons...
...

Sa sert pas uniquement si on vient fouiller dans la bdd...
Supposons que l'on fasse comme tu dis, l'utilisateur envoie son mot de passe "en clair" (non cripter par md5 en js) par un formulaire au serveur et la le "méchant" intercepte le mdp. Du coup, il a accès au compte et t'es dans le caca.

Par contre, si on effectue déja un traitement en javascript du mdp avec un algo md5 avant l'envoie du formulaire du coté serveur, le "méchant" aura beau intercepter le mdp cripter en md5 sa ne lui servira a rien...

Donc point de vue securité, c'est mieux !!! Par contre, si le js est désactiver sa pose problème...

[ePoX]

Même pas besoin : tu renvoies directement le mdp chiffré, pour un rejeu bête et méchant.
Un peu comme s'il n'était pas chiffré

Oui je sais bien, mais c'était pour en rajouter une couche sur l'inutilitée de cette méthode.

katsha, as tu bien lu les posts ?

[Eusebius]

Sa sert pas uniquement si on vient fouiller dans la bdd...
Supposons que l'on fasse comme tu dis, l'utilisateur envoie son mot de passe "en clair" (non cripter par md5 en js) par un formulaire au serveur et la le "méchant" intercepte le mdp. Du coup, il a accès au compte et t'es dans le caca.

Par contre, si on effectue déja un traitement en javascript du mdp avec un algo md5 avant l'envoie du formulaire du coté serveur, le "méchant" aura beau intercepter le mdp cripter en md5 sa ne lui servira a rien...

Donc point de vue securité, c'est mieux !!! Par contre, si le js est désactiver sa pose problème...

T'as pas compris l'idée... Si le "méchant" récupère le mdp chiffré et que c'est ce qu'attend le serveur, c'est comme s'il récupérait le mdp en clair dans le cas où le serveur attend le mdp en clair.
Dans les deux cas, il y a risque de rejeu.

[MasterOfChakhaL]

ce que tu n'as peut-être pas compris kastha, c'est que le méchant (puisqu'on l'appelle ainsi), n'a aucunement besoin de ton formulaire pour envoyer les infos...

Il lui suffit juste de regarder la source de ton formulaire pour savoir a quelle adresse il doit envoyer tout ce qu'il veut
Ensuite, il se fait son formulaire perso avec ce qu'il veut dedans...

[kastha]

J'invente rien si vous avez des doutes ...
http://www.developpez.net/forums/showthread.php?t=12254

si tu n'est pas en HTTPS, tu peut faire crypter les données que le client tenvoie depuis un formulaire, avec une fonction JavaScript (md5). Ainsi, tu n'as plus (moins) de problèmes d'interception des variables $_POST