Bonjour à tous,

j'aimerais faire un site comme unerencontre.com mais je n'arrive pas à programmer une fonction php d'identification, quelqu'un en aurait une simple à me conseiller, s'il vous plaît ?

Utilise les sessions. Après, pour te faire une implémentation, je ne sais pas quel est ton niveau de programmation (tu fais ça comment ? en php ?), mais bon c'est ce qui est le plus indiqué pour ça.

Oui je fais ça en php.

ben alors c'est koi la question ?????
si c'est pour ton login, stock les password en md5 dans ta base, pis quand kle gars met son password, tu l'encodes direct en javascript avant l'envoi

++

Encrypter le pass en md5 via javascript, c'est pas génial si l'utilisateur a désactivé la prise en compte du langage dans le browser... Si tu fais ca en php, il y a une fonction md5() qui existe. Je ne sais pas quel est le niveau de sécurité que tu souhaite obtenir pour ton appli mais je te conseil vivement de te documenter sur les différentes failles liés aux sessions (fixation de session, SQL injection, etc...). Enfin si tu as besoins de conseils plus précis, soit toi même plus précis dans ton post

Le 05 juin 2007 - 08 h 58, Nitro a écrit : Encrypter le pass en md5 via javascript, c'est pas génial si l'utilisateur a désactivé la prise en compte du langage dans le browser... Si tu fais ca en php, il y a une fonction md5() qui existe. Je ne sais pas quel est le niveau de sécurité que tu souhaite obtenir pour ton appli mais je te conseil vivement de te documenter sur les différentes failles liés aux sessions (fixation de session, SQL injection, etc...). Enfin si tu as besoins de conseils plus précis, soit toi même plus précis dans ton post

nitro, relis ce que tu as ecrit.... si tu relis bein tu verras que c'est un peu tire par les cheveux, je m'explique :
tu dis qu'utiliser javascript pour le md5 est pas top !!!! desactivation bla bla... qu'il faut utiliser php, re bla bla....
alors reprenons les choses au depart :
- javascript est un langage cote client
- php est un langage cote serveur

tester si js est active n'est pas selon moi une grosse epreuve, et bloquer l'acces pour les visiteurs ou js est desactive n'est pas non plus tres complique, c'est un premier point.

ensuite, si tu n'utilises pas javascript, que tu te mets dans la position de l'utilisateur, comment envoies tu ton mot de passe ??????? comment le cryptes tu ?????? TU NE PEUX PAS DONC TU L'ENVOIES EN CLAIR !!!!
la on nage dans le surnaturel tu trouves pas nivo secu, c'est certainement la pire solution.

car, et je reviesn a la difference js / php, il n'est pas envisageable d'utiliser php, pourquoi ? reprenons le process via ta methode :
- l'utilisateur entre son nom d'util et son mot de passe
- les donnees partent en clair sur le serveur
- php crypte le md5 (pourquoi ??? aucun interet...)
- php devrait renvoyer une chjaine cryptee si je suis bein ton raisonnement...

enfin voila, tu te rends bein compte que ce n'est pas viable du tout.

DONC !!!

La solution :
- trouver un algo de crypt qui convienne : md5, sha-1, ...
- faire le formulaire de login avec les champs login + mot de passe
- l'utilisateur entre son login et son mot de passe
- a la soumission du formulaire (clic sur le bouton "se connecter"), l'algo de crypt crypte EN LOCAL le mot de passe via un onsubmit=ma_fonction_de_crypt() sur la balise form.
- le formulaire est envoye au serveur avec le login et le mot de passe CRYPTE
- le serveur compare (via PHP) le mot de passe crypte soumis et celui present dans la base de donnees (crypte lui aussi), typiquement, effectivement on utilise la fonction md5, notons tout de meme que depuis la version 5 de php, il y a au moins une vingtaine de fonctions de crypt dispos dans php, on n'est donc pas du tout limite au md5 qui presente des trous de secu assez beants, j'en ai deja parle dans un topic ya pas longtemps suite a une recherche personnelle.
- les hash sont identiques, le serveur renvoit la page sur l'ecran d'accueil de l'utilisateur logge
- les hash sont differents, le serveur renvoit sur la page de login.

voila le process, comment ca se passe et pourquoi javascript est necessaire. ce'st aussi pour cela que la soluce full php n'est ni envisageable, ni meme exploitable car ne serait ce qu'algorithmiquement, elle est totalement fausse, il n'y a en effet dans ce cas rien a comparer

my 2 cents

Le 05 juin 2007 - 08 h 58, Nitro a écrit : Encrypter le pass en md5 via javascript, c'est pas génial si l'utilisateur a désactivé la prise en compte du langage dans le browser...

je reviens juste sur cette phrase... si le js est desactive, que va t'il se passer ?????
tout simplement le form va etre envoye avec le mot de passe en clair, qui sera compare par php au hash present dans la base. comme ce ne sera jamais identique, il n'y aura jamais de login, donc aucun trou de securite

Le 05 juin 2007 - 08 h 58, Nitro a écrit : mais je te conseil vivement de te documenter sur les différentes failles liés aux sessions (fixation de session, SQL injection, etc...).

on peut securiser ses sessions, crypter de tous les cotes, changer l'id de session a chaque requete serveur, stocker les id session en base pour les travailler, c'est TRES reducteur de dire que les sessions ne sont pas secure, meme si c'est en partie juste, dans la version basique de la chose.
je te conseille un bon tuto de depart sur developpez.com qui explicite parfaitement la securisation des sessions utilsateur en php.

quant aux sql injections, je dirais que c'est du basique, ya til encore des devs qui creent des url genre : index.php?page_a_charger=liste_produits&action=modifier_produit
oui je pense que tu as raison, il y en a encore des tonnes !!! ca fait flipper qaund meme.

pour ma part j'ajouterais que le safe mode est LA 1ere mesure a prendre en terme de securite

La j'avoue que pour le cryptage md5 tu m'as eu grabber , j'aimerais pouvoir dire que je n'ai jamais écrit de pareilles atrocités .

pa grave moi aussi j'en ecris des belles des fois chacun son tour

Le 07 juin 2007 - 10 h 39, grabber a écrit : Le 05 juin 2007 - 08 h 58, Nitro a écrit : mais je te conseil vivement de te documenter sur les différentes failles liés aux sessions (fixation de session, SQL injection, etc...). on peut securiser ses sessions, crypter de tous les cotes, changer l'id de session a chaque requete serveur, stocker les id session en base pour les travailler, c'est TRES reducteur de dire que les sessions ne sont pas secure, meme si c'est en partie juste, dans la version basique de la chose. je te conseille un bon tuto de depart sur developpez.com qui explicite parfaitement la securisation des sessions utilsateur en php. quant aux sql injections, je dirais que c'est du basique, ya til encore des devs qui creent des url genre : index.php?page_a_charger=liste_produits&action=modifier_produit oui je pense que tu as raison, il y en a encore des tonnes !!! ca fait flipper qaund meme. pour ma part j'ajouterais que le safe mode est LA 1ere mesure a prendre en terme de securite

tu peux developper ton exemple sur l'url, je ne vois pas les failles?

pour les injections ????

ben c des injections classiques quoi, tu laisses tout passer sans filtrer, du coup ca laisse la possibilite a un gars de poser du code sql en utilisant des ptis stratagemes bien connus et qui permettent de faire sauter des tables ou pire encore, si le passage de parametre est facilite
ou alors dans l'exemple donne ci-dessus, si le param est page_a_charger=liste_produits et que le dev est assez con pour appeler sa page liste_produits.php, alors il est tres facile de trouver l'arborescence du merdier, ce qui peut entrainer pas mal de problemes si le gars en face decortique les formulaires et donc les variables post voir get...

atta jve te trouver 1 exemple classique qui explique plus precisement comment ca se passe...

http://www.phpsecure.info/v2/article/InjSql.php

Le 13 juin 2007 - 10 h 57, grabber a écrit : si le param est page_a_charger=liste_produits et que le dev est assez con pour appeler sa page liste_produits.php

mais s'il ne l'est pas ?
s'il recup ses variables url via un htmlentities ou specialchars et qu'un switch appelle une page dont le nom n'a rien à voir (ou mm c le mm, le passage pas le switch filtre sur des pages précises justement)... comment peux-tu prétendre rien qu'en voyant ce genre d'url, il y a des failles (ou que le dev est un con) ?

quant au sql injection c lié à un formulaire comme tu dis ou un variable url qui semble appliquer une condition (comme admin=1 par exemple)... encore faut-il que le dev n'est mis aucun filtre sur les données envoyées au serveur...

mais je ne pense pas que rien qu'en regardant une url avec des variables on puisse dire qu'il y a des failles... non ?

ben justement, tu explicites exactement ce que je disais !!!!
ya 2 facons de faire : intelligemment ou a la bourrin, c'est bien pour ca que je disais SI...

le probleme de sql injection a ete souleve par nitro je me borne donc juste a en expliquer le mecanisme.

donc je reprend, nivo url, si le mec est un bourrin, ben ca va peter direct ! maintenant, s'il code correctement, notamment pour des passages de parametres get | post, il enleve deja pas mal de risques.
c'est pas bein complique si tu veux faire peter un site de prendre les parametres et d'ajouter .php a la fin c'est ce ke font tous les casseurs, il n'y a qu'a regarder les loogs apache d'un de tes serveurs, tu verras que c'est plus que courant, chez moi ca arrive tous les jours !!!
ensuite, les gars recherchent aussi des fichiers "classiques" style... euh... admin.php ou autres...

concernant les injections, evidemment qu'il faut faire des html entities, sauf si comme je le disais le gars est un bourrin qui code comme un porc et la tout passe

tu comprends mieux ????

pour repondre a ta derniere question, concernant le fait si de voir les variables indique qu'il y a des failles, ben justement si, il suffit de tester les urls, ca prend 2 secondes a faire en live, et si t malin, tu te fais un pti script a base de curl pour voir ce que ca ramene et tu parses les resultats
je ne pretends pas comme tu l'insinue que ce genre de variable est une faille, je pretends en revanche que c'est la porte ouverte a n'importe quoi si derriere c'est mal gere comme dans l'exemple fourni, donc oui dans ce cas la, si c'est mal gere, c'est que le codeur est bidon

quand on veut se proteger, faut se mettre a la place de celui qui attaque sinon tu vas pas loin, et les portes d'entree sur un site ne sont pas infinies, c'est toujours les memes

Le 13 juin 2007 - 15 h 10, Loading a écrit : Le 13 juin 2007 - 10 h 57, grabber a écrit : si le param est page_a_charger=liste_produits et que le dev est assez con pour appeler sa page liste_produits.php mais s'il ne l'est pas ?

on parle de secu, on part du cas general, donc du debutant, d'ailleurs le public a l'air debutant donc fo s'aligner. c'est sur que si tu pars du principe ke le dev est une bete.... mais dans ce cas, chui pas sur ke M. mitnick passe demander des infos sur un forum

lol grabber ^^

bon de toute façon j'avais bien compris la leçon je bouffe du code constament, mais autant j'admire tes explications là où j'ai abandonné depuis longtemps autant quelquefois tu fais des raccourcis un peu rapide (genre le paragraphe sur les noobs qui mettent le nom de page en dans l'url...) et c de ce dernier point que je parlais en fait xD

ahhhhh moi yen avait pas avoir compris que toi vouloir tailler moi
oui c vrai ct ptet un peu rapide c ke g du taf en ce moment alors je raccourcis un peu

mais mm avec du taff tu expliques aux noobs comment ca fonctionne... chapeau ! (là je taille pas, j'suis impressionné )

bref g malheureusement peur que notre princiapl intéressé ne revienne plus mettre son nez dans tes explications... dommage pour lui.

Pô grave c'est pas tombé dans l'oreille d'un sourd le coup du cryptage md5 en javascript avant l'envoie au serveur !

lol woofy, ne me dis pas que.... nonnnn ? O-O