VÉRIFICATION DE LOGIN VIA HASH MD5

Messages postés
10843
Date d'inscription
lundi 24 février 2003
Statut
Modérateur
Dernière intervention
2 mars 2010
- - Dernière réponse : doudou3158
Messages postés
108
Date d'inscription
mercredi 29 juin 2005
Statut
Membre
Dernière intervention
12 mai 2007
- 28 avril 2006 à 17:50
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.

https://codes-sources.commentcamarche.net/source/34166-verification-de-login-via-hash-md5

doudou3158
Messages postés
108
Date d'inscription
mercredi 29 juin 2005
Statut
Membre
Dernière intervention
12 mai 2007
-
Euh juste comme ça mais il manque une parenthèse ligne 14.
cs_Anthomicro
Messages postés
9433
Date d'inscription
mardi 9 octobre 2001
Statut
Membre
Dernière intervention
13 avril 2007
8 -
" Voui, mais ca t'oblige à réécrire une fonction pour en faire fonctionner 2 sur une même variable =)" ? je te suis pas là

ma méthode c'est ça :

vérification get_magic_quote_gpc()
utilisation d'addslashes() le cas échéant
vérification login sql + vérification login php

c'est tout.
FhX
Messages postés
2350
Date d'inscription
mercredi 13 octobre 2004
Statut
Membre
Dernière intervention
18 avril 2015
3 -
Voui, mais ca t'oblige à réécrire une fonction pour en faire fonctionner 2 sur une même variable =)
Donc, est-ce que tu y gagnes vraiment ? Quelle manière est la plus rapide ?
Alors la, j'en sais rien :D

Parce que avec ma méthode :
vérification hash login sql + vérification hash login php
(je ne compte pas le mot de passe qui est lui de toute facon hashé)

La méthode d'Antho (à quelques chose près) :
vérification get_magic_quote_gpc()
utilisation d'addslashes() le cas échéant
utilisation de mysql_real_escape_string() (optionnel)
vérification login sql + vérification login php

Ce que je peux faire très simplement, on peut le faire avec un peu plus de volonté chez Antho ;)
Par contre, je connais pas au niveau temps de traitement ce que ca donne, il se peut que ma méthode soit "largement" plus longue à traiter.
A voir :)
cs_Anthomicro
Messages postés
9433
Date d'inscription
mardi 9 octobre 2001
Statut
Membre
Dernière intervention
13 avril 2007
8 -
C'est sûr, enfin perso je n'ai jamais rencontré de problèmes avec addslashes :-) (et au pire quand on fait une fonction myaddslashes on peut tout à fait mettre un mysql_[real_]escape_string() après :-)
malalam
Messages postés
10843
Date d'inscription
lundi 24 février 2003
Statut
Modérateur
Dernière intervention
2 mars 2010
17 -
Je suis d'accord avec FhX (je sais, c'est inutile comme commentaire, lol, mais j'avais envie de le dire).
mysql_real_escape_string () est en remation plus étroite avec mysql. Dès fois qu'un jour les développeurs de mysql décident de changer les caractères devant être échappés, cette fonction sera mise à jour très vite. addslashes () ne le sera peut-être pas, puisque n'étant pas dédiée.
FhX
Messages postés
2350
Date d'inscription
mercredi 13 octobre 2004
Statut
Membre
Dernière intervention
18 avril 2015
3 -
Oui, mais très personnelement, je préfère faire un mysql_escape_string() ou mysql_real_escape_string() qui est mieux approprié pour échapper des caractères qui vont dans une requète SQL.
cs_Anthomicro
Messages postés
9433
Date d'inscription
mardi 9 octobre 2001
Statut
Membre
Dernière intervention
13 avril 2007
8 -
"mais en même temps, je me prémuni d'un gros problème de sécurité"

if(get_magic_quotes_gpc()===0)
{
$chaine=addslashes($chaine);
}

mysql_query('requete blabla WHERE login="'.$chaine.'" OR machin...');

ça te prémunit tout autant ^^
FhX
Messages postés
2350
Date d'inscription
mercredi 13 octobre 2004
Statut
Membre
Dernière intervention
18 avril 2015
3 -
Je vais me taper la réponse :)
"Car, pour éviter 1 addslashes et le stripslashes qui suit, tu utilises : 2 md5(PHP) et 1 MD5(MySQL). Economie tout relative ;)" C'est vrai, mais en même temps je n'ai plus besoin de savoir si ma variable est passé au nettoyage ou pas (le login dans ce cas la), car à l'inscription du membre, j'aurais viré tous les caractèresqui ne m'intéresse pas. Donc, si quelqu'un tente une quelconque requête à la con lors du login, celle ci est immédiatement erradiqué à cause du hash.

"* Ca nous fait pas un "ERROR headers already sent" un truc comme ça ? (Je n'ai pas testé)" Non, je fais toujours en sorte de ne jamais avoir de sortie HTML avant mes headers :) J'en ai même fait un tuto y'a pas longtemps =) Ne compte pas sur moi pour ce genre d'erreur =)

"ou l'utilisation de mysql_num_rows qui compte jestement le nombre de lignes du résultat..."Non, je ne le fais pas, car le login DOIT et EST TOUJOURS unique. Donc de ce fait, le nombre d'enregistrement possible lors d'un SELECT sur un login doit être :
-> soit de 1 si me membre est bien inscrit.
-> soit de 0 si le login/pass ne corresponde pas.
Le nombre de ligne, dans ce cas la, ne sert strictement à rien du tout :)

Sinon, oui c'est lourd. La comparaison des hashs est beaucoup plus gourmande qu'un pauvre addslashes, mais en même temps, je me prémuni d'un gros problème de sécurité. Si un jour, quelqu'un trouve comment passer à travers d'un addslahes (on ne sait jamais !), passer au travers d'un hash est plus embetant.
Cependant, avec un hash, il y a le risque de collision, bien qu'il soit très faible.
C'est un risque parmis tant d'autres :)
J_G
Messages postés
1406
Date d'inscription
mercredi 17 août 2005
Statut
Membre
Dernière intervention
28 août 2007
6 -
Astuces intéressantes... surtout pour le cryptage des données d'identification !

Car, pour éviter 1 addslashes et le stripslashes qui suit, tu utilises : 2 md5(PHP) et 1 MD5(MySQL). Economie tout relative ;)

Ensuite, j'aurais qques'commentaires :
* Ca nous fait pas un "ERROR headers already sent" un truc comme ça ? (Je n'ai pas testé)
# session_start();
# ...
# header('Location: private.php');

* La COMPARAISON en MySQL est insensible à la casse SI :
"Les valeurs dans les colonnes CHAR et VARCHAR sont classées et comparées sans tenir compte de la casse, à moins que l'attribut BINARY n'ai été spécifié lors de la création de la table" (doc MySQL)

* A propos de la fonction mysql_fetch_row() :
" Retourne un tableau numérique qui correspond à la ligne récupérée, ou FALSE s'il n'y a plus de lignes." (doc PHP)
Donc je te suggère plutôt:
return is_array($data); ou return !($data===false)
ou l'utilisation de mysql_num_rows qui compte jestement le nombre de lignes du résultat...


Voilà, sinon c'est très bien!
A+
FhX
Messages postés
2350
Date d'inscription
mercredi 13 octobre 2004
Statut
Membre
Dernière intervention
18 avril 2015
3 -
return ( $data[0] == 1 ) ? true : false;

Y'a bien un return dans la fonction :)


Au passage, si j'ai fait une fonction, c'est pour un souci de clarté =)
cs_Anthomicro
Messages postés
9433
Date d'inscription
mardi 9 octobre 2001
Statut
Membre
Dernière intervention
13 avril 2007
8 -
y'en a pas besoin ;-)
coucou747
Messages postés
12336
Date d'inscription
mardi 10 février 2004
Statut
Modérateur
Dernière intervention
30 juillet 2012
29 -
il utilises COUNT...
cs_Anthomicro
Messages postés
9433
Date d'inscription
mardi 9 octobre 2001
Statut
Membre
Dernière intervention
13 avril 2007
8 -
" il ne manquerais pas un GROUP BY 1=1 dans ta requette ?"

heu pourquoi il en manquerait un ?
coucou747
Messages postés
12336
Date d'inscription
mardi 10 février 2004
Statut
Modérateur
Dernière intervention
30 juillet 2012
29 -
il ne manquerais pas un GROUP BY 1=1 dans ta requette ?

bon, à part ça, comme tu utilises les sessions, je ne suis pas sur qu'une fonction soit nécéssaire car si tu te débrouilles bien, tu n'appelleras cette fonction qu'une fois...

en plus, t'as pas de return... tu devrais plutot lui faire renvoyer un bool, pour savoir si on est logué, et la partie "main" elle afficherais le résultat...
FhX
Messages postés
2350
Date d'inscription
mercredi 13 octobre 2004
Statut
Membre
Dernière intervention
18 avril 2015
3 -
Pour répondre à Malalam... sisi, SHA-1 est bien pris en compte par MySQL :

$sql "SELECT COUNT(*) FROM ma_base WHERE SHA1(login) '".sha1($login)."' AND password = '".$password."' ";

Et ca marche :)
FhX
Messages postés
2350
Date d'inscription
mercredi 13 octobre 2004
Statut
Membre
Dernière intervention
18 avril 2015
3 -
Bah je savais même pas...
Ca va m'éviter bien des soucis alors !
cs_Anthomicro
Messages postés
9433
Date d'inscription
mardi 9 octobre 2001
Statut
Membre
Dernière intervention
13 avril 2007
8 -
Salut,

inutile d'utiliser LOWER et strtolower dans le login vu que les champs varchar sont insensibles à la casse (et il est préférable d'utiliser ce type de champ pour justement ne pas avoir besoin de faire appel à ces fonctions).
malalam
Messages postés
10843
Date d'inscription
lundi 24 février 2003
Statut
Modérateur
Dernière intervention
2 mars 2010
17 -
Hello,

pour l'ordre, ça devrait être bon ;-)
Pour le reste aussi, c'est pas con! Le seul bémol, ça fait faire 2 hash à chaque login. Mais bon...autre bemol, je ne suis pas certain que MySql sache hasher sha1 (à vérifier). Ce qui oblige donc à garder md5.

Mais bon, bonne idée :-)