Traitement mot de passe dans un accès login

scoal Messages postés 78 Date d'inscription dimanche 3 juillet 2005 Statut Membre Dernière intervention 8 avril 2012 - 5 mars 2009 à 10:16
TychoBrahe Messages postés 1309 Date d'inscription samedi 31 janvier 2009 Statut Membre Dernière intervention 5 juin 2013 - 8 mars 2009 à 13:58
Bonjour,

J'aimerais faire un accès avec login sur certaines des pages de mon site, la personne s'inscrit au préalable avec un formulaire, pas de soucis ici...
Par contre sur la partie login (formulaire avec identifiant et mot de passe),  il y a un problème lors de ma requete SQL :

 // Valider le mot_de_passe.

     if (empty($_POST['mot_de_passe']))
      {
        $dem_mdp = FALSE;
        echo "Vous avez oublié d'indiquer votre mot de passe.";
      }

// Si il y a un mot_de_passe, traitement de celui-ci

    else
      {
        $dem_mdp = echappement($_POST['mot_de_passe']);
      }

// Meme traitement pour l'identifiant : $dem_ident
// Si tout est OK, consulter la base de données

     if ($dem_ident && $dem_mdp)
      {
//Ici je ne sais pas comment traiter $dem_mdp pour le comparer à celui dans la base de donnée
          $q = mysql_query("SELECT * FROM demandeur_donnee_perso WHERE demandeur_identifiant= '$dem_ident' AND demandeur_mdp=PASSWORD('$dem_mdp')");
          $n = mysql_num_rows($q);
//Si "n" est strictement égal à 1 alors il y a un enregistrement dans la base de donnée qui correspond au données entrée
            if ($n == 1)
             {

//Traitement pour création session

             }
       }
//Sinon c'est qu'il n'y a pas de données correspondantes dan la base de donnée
     else
       {
           echo "Le nom d'utilisateur et/ou le mot de passe que vous avez indiqué ne correspondent pas à ceux de notre fichier.";
        }

Tout marche si j'enleve la recherche avec le mdp dans la requete...
J'ai essayé plusieurs techniques que j'ai trouvé sur le net mais aucun moyen de passe...
J'ai rien mis de spécial coté formulaire d'enregistrement, dans la base de donnée avec PhpMyAdmin on peut voir que le mdp est crypté...

Si quelqu'un peut m'éclairer se serait le bien venu...

Merci infiniment.

14 réponses

chasseur2 Messages postés 33 Date d'inscription vendredi 3 mars 2006 Statut Membre Dernière intervention 10 mai 2009
5 mars 2009 à 11:52
tout d'abors qui fait la fonction password() el fonction echappement tu peut  nous le montrer
si votre mot de passe est enregistrer dans la base de données  crypter avec une fonction MD5() OU crypte () il faut fair le test avec le cryptage de votre formulaire .
0
scoal Messages postés 78 Date d'inscription dimanche 3 juillet 2005 Statut Membre Dernière intervention 8 avril 2012
5 mars 2009 à 12:15
La fonction password() recrée un mot de passe, donc rien à voir ici...
Comme je l'ai dis j'ai essayé pas mal de solutions, se doit être une des dernières que j'ai faite à "l'arrache" et donc pas vérifié lors du copier/coller dsl...
Sinon la fonction echappement récupère la chaine et lui applique un stripslashes() et un trim () avant de la renvoyer, c'est un vieux script, je voulais faire un script fonctionnel avant de l'optimiser... (je vais la supprimer surement).

Comme je l'ai dis j'ai rien mis de spécial coté formulaire d'enregistrement, je récupère le mdp écrit dans le formulaire et je l'envois avec le reste de ces coordonnées dans la base de données...

Quelles sont les possibilités pour le lire le mdp (du formulaire) et le comparer (avec celui de la base de donnée)?
0
chasseur2 Messages postés 33 Date d'inscription vendredi 3 mars 2006 Statut Membre Dernière intervention 10 mai 2009
5 mars 2009 à 12:33
si vous voulez lire le mot de passe de votre formulai par exemple le nom de champs de mot de passe dans votre formulaie apprend un nom comme ça  name="mot_pass" il suffit de de faire echo "$_POST['mot_pass']"; il y a d'autre method mais ca il va  affichier le mot de passe comme vous aves entrer si tu mis 1455 il va afficher 1455 mais si vous avez un mot de passe stocker dans votre NDD crypter il faut aussi crypter le mot de pass de votre formulaire pour etre la verification acciptable par exemple vou aves un mot de passe stocké dans votre BDD COMME SUIT : c45f22e214d4555555551111 et vous aves entrer dans votre formulaire un mdp comme suit 1455 est ce que les mots de passe sont egaux alors il faut crypter le mot de passe du formulaire
sachan que le cryptage de 1455 et c45f22e214d4555555551111 par exemple
0
scoal Messages postés 78 Date d'inscription dimanche 3 juillet 2005 Statut Membre Dernière intervention 8 avril 2012
5 mars 2009 à 12:46
Franchement, merci du temps que vous me consacrez...

C'est pas de la mauvaise volonté de ma part, mais c'est illisible...

J'essaye toujours de me mettre à la place de la personne qui va me relire et j'imagine une "présentation" (c'est certain que sa représente un certain % du temps pour poster un message), mais en face l'impacte est pas le même et donc indirectement la volonté de discuté aussi...

Bref des majuscules, des phrases structurées voir mieux des paragraphes n'est pas un luxe...
0

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question
chasseur2 Messages postés 33 Date d'inscription vendredi 3 mars 2006 Statut Membre Dernière intervention 10 mai 2009
5 mars 2009 à 12:54
tu peut nous montrer qui contien la fonction PASSWORD( )
0
scoal Messages postés 78 Date d'inscription dimanche 3 juillet 2005 Statut Membre Dernière intervention 8 avril 2012
5 mars 2009 à 13:28
La fonction password() recrée un mot de passe, donc rien à voir ici...
Comme je l'ai dis j'ai essayé pas mal de solutions, se doit être une des dernières que j'ai faite à "l'arrache" et donc pas vérifié lors du copier/coller dsl...
0
kohntark Messages postés 3705 Date d'inscription lundi 5 juillet 2004 Statut Membre Dernière intervention 27 avril 2012 30
5 mars 2009 à 20:16
Salut,


C'est quoi "demandeur_mdp= PASSWORD ('$dem_mdp')" ???
Je crois bien que chasseur tentait d'attirer ton attention là dessus. Je ne sais pas ce que tu as voulu faire mais ça ne peut pas fonctionner.
Je vais tenter d'être plus clair que Chasseur :
- l'utilisateur s'inscrit
  => tu récupères son pseudo => insertion DB
  => tu récupères son mot de passe => cryptage md5 => insertion DB

- l'utilisateur s'identifie :
  $pass = md5($_POST['mot_de_passe']);
  $q = mysql_query("SELECT COUNT(*)
  FROM demandeur_donnee_perso
  WHERE demandeur_identifiant='$dem_ident' AND demandeur_mdp='$pass'");
  $n = mysql_result($q, 0);

  if ($n !== 0) { ...

Il ne s'agit que des grandes lignes, il faut tester l'existence des variables post, les traiter pour éviter l'injection (pas besoin pour le pass), ...

//Si "n" est strictement égal à 1if ($n 1)>
heu, non, if ($n === 1) plutôt

//Sinon c'est qu'il n'y a pas de données correspondantes dan la base de donnée
     else
       {
           echo "Le nom d'utilisateur et/ou le mot de passe que vous avez indiqué ne correspondent pas à ceux de notre fichier.";
        }
=>
heu, non, c'est que l'utilisateur n'a pas rempli son mot de passe ou son identifiant

La fonction echappement() ne sert à rien si tu cryptes bien ton pass comme indiqué ci dessus.

Cordialement,

Kohntark -
0
scoal Messages postés 78 Date d'inscription dimanche 3 juillet 2005 Statut Membre Dernière intervention 8 avril 2012
5 mars 2009 à 20:58
Bonjour,

merci, j'avais trouvé une solution identique avec le traitement md5 à l'enregistrement et lors de la récuperation du formulaire login pour les comparer les deux, pas encore eu le temps d'essayer...

Pour finir avec sa, je l'ai quand même dis 2 fois, la fonction PASSWORD() recrée un mot de passe, c'est une fonction php donc j'ai rien à voir sur sa création ou son comportement et sa doc est dispo sur le net...
0
TychoBrahe Messages postés 1309 Date d'inscription samedi 31 janvier 2009 Statut Membre Dernière intervention 5 juin 2013 12
5 mars 2009 à 21:08
Salut,

scoal : La documentation de MySQL concernant PASSWORD() recommande très fortement de ne pas utiliser cette fonction dans les applications. Utilise donc plutôt MD5() ou, mieux SHA1(). Soit dit en passant, tu devrais ajouter un LIMIT 1 dans ta requête SQL afin d'éviter d'éventuels imprévus. Sélectionner un seul champ au lieux de tous (*) est également préférable.
0
kohntark Messages postés 3705 Date d'inscription lundi 5 juillet 2004 Statut Membre Dernière intervention 27 avril 2012 30
5 mars 2009 à 22:23
@Scoal :

Pour finir avec sa, je l'ai quand même dis 2 fois, la fonction
PASSWORD() recrée un mot de passe, c'est une fonction php donc j'ai
rien à voir sur sa création ou son comportement et sa doc est dispo sur
le net...
=>
Plutôt que d'écrire " je l'ai quand même dis 2 fois" tu aurais mieux fait de lire la doc 2 fois, ça t'aurais évité de perdre ton temps sur ton script.
D'une part password n'est pas une fonction php, et d'autre part elle ne recrée pas un mot de passe dans ton cas. C'est quand même dit plus de 5 fois dans la doc dispo sur le net.
D'ailleurs dire qu'elle recrée un mot de passe aurait dû t'alerter, tu cherches à faire une comparaison, pas a réattribuer un pass à un utilisateur mySQL. Menfin ...

@tychoBrahe :
A mon humble petit avis le problème n'est pas la recommandation ou pas. C'est surtout que c'est un algo qui semble propre à mySQL (?), en tous cas ce n'est ni du md5 ni du SHA1.

Pourquoi SHA1 plutôt que md5 ?? Sauf à avoir 10 milliards de visiteurs sur son site je ne vois pas trop C'est sans doute plus long et coûteux en ressources, ....

Bonne fin de soirée à vous,

Kohntark -
0
TychoBrahe Messages postés 1309 Date d'inscription samedi 31 janvier 2009 Statut Membre Dernière intervention 5 juin 2013 12
6 mars 2009 à 00:48
"Pourquoi SHA1 plutôt que md5 ??"

Juste pour avoir la conscience tranquile ;) Je ne saurai rien dire sur le différence de temps de calcul sinon que c'est négligeable, si tu es a ça près il faut faire ton site dans un langage compilé. D'ailleur les requêtes SELECT MD5('toto'); et SELECT SHA1('toto'); s'effectuent chez moi toutes en 0.00 sec.

Sinon l'utilisation de PASSWORD() ne cause pas en elle meme le soucis, il est tout a fait possible de l'utiliser dans le cas présent, mais c'est très peu recommandé de le faire.
Est-il possible d'avoir le résultat d'un var_dump() de la variable contenant la requête ainsi que la structure de la table et le contenu exact de l'entrée avec laquelle le pass devrais matcher ?
0
scoal Messages postés 78 Date d'inscription dimanche 3 juillet 2005 Statut Membre Dernière intervention 8 avril 2012
6 mars 2009 à 07:47
Merci, la vache sa 3 fois que l'on répère la meme chose...

Poster donne des points et accès à quelques chose?

Merci pour les liens docs et merci pour les quelques précisions, c'est vrai que se serait un peu plus confort avec une limite et une selection d'un seul champ...
0
malalam Messages postés 10839 Date d'inscription lundi 24 février 2003 Statut Membre Dernière intervention 2 mars 2010 25
8 mars 2009 à 09:57
Hello,

Socal, ta remarque est limite...les gens essayent de t'aider. Oui, poster donne des points, et ces points ne servent à rien à part à progresser dans un classement des membres les plus actifs; et je doute fort que beaucoup s'en soucient...
Ce post a été laborieux, les gens échangent aussi entre eux...contente toi de dire merci plutôt que de te vexer parce qu'on t'a rabâché des trucs que tu n'as pas tjrs compris du 1er coup.
Bref, je n'ai pas aimé cette remarque...

Et je vais échanger aussi (et crois moi, je n'ai pas grand chose à gagner côté points : je suis admin de ce site depuis fort longtemps...des points, j'en ai à revendre, et je m'en fiche...) : je ne suis pas d'accord sur un concept bien précis, là, c'est le LIMIT 1. Quand on fait de la gestion de compte, on fait déjà en sorte de ne pas avoir de doublon du couple login/password lors des inscriptions.
Ensuite, quand on vérifie l'identité de quelqu'un, on ne s'appuie pas sur le fait que notre code gère les doublons et que donc il ne doit pas y en avoir...ou que si jamais il y en a, pas grave, on va juste sortir le 1er couple : c'est dangereux! Cela implique que si jamais on a un doublon...pas grave, on va filer le 1er compte trouver au toto qui s'identifie.
Imaginez que votre banque fasse pareil...? Ils ont mal géré leurs comptes en ligne...vous avez le même couple d'identifiants qu'un autre gars...l'autre gars s'identifie et comme le développeur était un flemmard, plutôt que de gérer ce cas extrème, il fait un LIMIT 1 dans sa requête...et le gars en question s'identifie sur VOTRE compte.
Quand on développe un applicatif, on gère toutes les possibilités, même les plus improbables.
Moi, mes gestions de compte empêchent les doublons...et quand elles tentent d'identifier quelqu'un, elles vont chercher TOUTES les lignes contenant le login et le password saisi...et si jamais cette requête renvoie plusieurs ligne : je jette le toto, le balance une exception, je m'envoie un mail ; alaaaaarm!!
Ca n'arrive jamais. Mais un jour...ça arrivera parce que j'aurais été hacké, parce que j'aurais fait une connerie dans mon code, parce...la vie est crulle, que sais-je. Mais ça arrivera.
Et j'aurais au moins géré cette improbabilité.

Il est d'ailleurs curieux que ce soit Tycho qui dise ça alors que d'un autre côté il dit : pourquoi sha1() plutôt que md5() ? parce qu'on ne sait jamais...et je suis là par contre d'accord avec lui. Un mec aussi parano devrait aussi l'être sur ses requêtes :-)
md5() est quand même hacké rapidement, de nos jours, de toute manière. Et même si ça este très improbable (dépend du site quand même...), juste au cas où...je penche aussi pour sha1() ces temps-ci. Et en effet, on perd vraiment très très peu...même sur des sites à gros traffic (parce que tester ça sur 1 requête select, c'est pas du benchmark...ça ne veut rien dire).
0
TychoBrahe Messages postés 1309 Date d'inscription samedi 31 janvier 2009 Statut Membre Dernière intervention 5 juin 2013 12
8 mars 2009 à 13:58
«et si jamais cette requête renvoie plusieurs ligne : je jette le toto,
le balance une exception, je m'envoie un mail ; alaaaaarm!!»

En effet c'est la meilleur chose a faire, je pensais limiter les dégâts avec le LIMIT 1 sans penser a cette solution bien plus propre et efficace. Merci de ta remarque, ça m'aura été instructif

«(parce que tester ça sur 1 requête select, c'est pas du benchmark...ça ne veut rien dire)»
Juste comme ça, je n'ai pas fait 1 seule requête mais une petite série de chaque, pas assez pour pouvoir vraiment comparer je te l'accorde. D'un autre côté il n'y a pas trop le choix, je ne vois pas comment faire un boucle en SQL, et faire appel a MySQL depuis PHP ou un script Shell fausserais complètement la comparaison, la réalisation de l'appel n'étant pas négligeable par rapport aux fonctions a tester. Je me basais surtout que quel que soit la fonction (md5 ou sha1) le temps de calcul étais négligeable dans les deux cas (moins de 0.005 secondes).
D'ailleurs, as-tu déjà vu un seul test comparatif réellement sérieux ? Pour ma part je n'ai vu que des test de la forme "je répète n fois chaque chose et je regarde laquelle est la plus grande pour conclure". Où sont les tests statistiques ? Jamais je n'ai vu de référence a la loi normale, a un test de Student ou autre test dépendant de la situation donc bon ... si tu veux commencer a remettre en question les benchmark que tu rencontre tu as du boulot :)
0
Rejoignez-nous