problème cryptage sha1

[Fab le Fou]

Bonjour,

J'ai un soucis avec l'accès à la zone d'admin d'un mes sites.
J'utilise l'algo de cryptage sha1 pour les mots de passe des auteurs.

De mon côté, que je passe par IE ou FireFox tout fonctionne et c'est aussi le cas pour les majorité des auteurs mais certains n'arrivent pas à se connecter alors qu'ils m'ont dit bien faire attention à la casse.

Au début le cryptage se faisant via un javascript je pensais que ça venait de là mais maintenant qu'il se fait en php, le problème persiste :

$mail=trim($_POST["mail"]);
$passe=sha1(stripslashes($_POST["passe"]));

Comme tout se passe bien pour moi, difficile de trouver d'où vient le lézard. :cry:

A+, Fab

 

[Sir Dipp]

SHA1 n'est pas un cryptage, c'est un hashage.

Sinon, dans ta base de donnée tu as combien de caractères pour le champ du mot de passe ?

A+

 

[Fab le Fou]

SHA1 n'est pas un cryptage, c'est un hashage.

Sinon, dans ta base de donnée tu as combien de caractères pour le champ du mot de passe ?

Actuellement 40 caractères.

 

[Sir Dipp]

Est-ce que tu as comparez l'entrée de la base de donnée avec un mot de passe hashé ?

Genre deux ligne avec ce qui est dans la base de donnée puis une autre avec le mot de passe entré hashé.

A+

 

[Fab le Fou]

Oui et les 2 sont identiques, sinon je pense que la connexion ne fonctionnerait jamais et là le problème ne se pose qu'avec certains utilisateurs.

Est-ce qu'il n'y a pas un risque qu'un même caractère (visuellement) soit en fait codé différement (niveau ASCII) suivant le navigateur, et donc différent une fois hashé ?

Je viens de constater que la dernière personne qui rencontre le problème est chez aol...

En tous, le problème doit bien venir du côté client.

 

[julisube]

Tu fais bien la comparaison de strings avec strcmp et non avec == ?

Sinon coté client tu peux avoir un problème d'encoding, tu peux forcer le client avec header() à accepter un encoding.

 

[mowmow]

Essaie d'enlever le stripslashes, ca sert à rien vu que ta chaine hashée n'aura que des chiffres et des lettres

 

[Fab le Fou]

Essaie d'enlever le stripslashes, ca sert à rien vu que ta chaine hashée n'aura que des chiffres et des lettres

Ouai mais elle est haschée après le stripslashes, donc si je laisse les slash, le résultat devrait être différent, non ?

Je vais regarder du côté de la fonction header() si je peux forcer le codage des caractères, comme conseillé.

Ce qui est marrant que les mêmes utilisateurs n'avaient pas de problème lorsque je laissais les mots de passe tel quel, alors que le problème aurait dû être le même

 

[julisube]

Pour localiser le bug, essaye sans hachage et regarde ce qui atterit dans la bd .

Ce n'est surement pas SHA-1 qui est en cause, mais le traitement de la string password et/ou l'encodage de la bd, de ton formulaire, ou bien encore la comparaison de strings.

 

[rog]

lol

pas evident

néanmoins si tu ne traite pas la variable en stripslashe avant le hashage au moment de l'insertion, en db, ça pourrait expliquer que des pass contenant des quotes ou doubles quotes ne correspondent pas au moment du test

rog

 

[Fab le Fou]

Re: lol

néanmoins si tu ne traite pas la variable en stripslashe avant le hashage au moment de l'insertion, en db, ça pourrait expliquer que des pass contenant des quotes ou doubles quotes ne correspondent pas au moment du test

Non justement ce qui m'étonne c'est que le mot de passe temporaire que j'ai moi-même créé ne contient que des caractères "normaux" (lettres + chiffres).

Et puisque ça marche avec la majorité des utilisateurs, cela ne peut venir que du côté client (navigateur sans doute).

 

[rog]

lol

c'est pas tout à fait ce que je disais

en desossant pour debugger on peut affirmer que le probleme ne peut pas venir du navigateur

l'hypothèse que j'émettais etait la suivante

au moment de m'enregistrer comme user je saisi un passe rog12'12

si magic_gpc est a on l'apostrophe va chopper un slash

si tu n'appliques pas un stripslash avant de hasher mon pass pour l'insérer dans la table

tu auras une requete qui comparera sha1(rog12'12) avec sha1(rog12\'12)

sinon il pourrait peut etre y avoir un probleme de passage de caracteres accentués si tu n'as pas declaré le charset de la page html mais c'est pas sur

rog

 

[Fab le Fou]

Re: lol

au moment de m'enregistrer comme user je saisi un passe rog12'12

Oui me justement là il n'y a ni apostrophe, ni caractère accentué.
ça devrait passer comme une lettre à la poste.

 

[rog]

lol

la ça se corse

faut debugger

fait des print
compare les types de variables etc...

rog

 

[julisube]

La question vitale: peux-tu reproduire le bug chez toi ? ou est-ce seulement certains utilisateurs qui ont ce bug ?

Dans le dernier cas, il te faut la config (OS, version(SP1/SP2..), navigateur etc) et essayer de reproduire le bug.

 

[Fab le Fou]

La question vitale: peux-tu reproduire le bug chez toi ? ou est-ce seulement certains utilisateurs qui ont ce bug ?

Dans le dernier cas, il te faut la config (OS, version(SP1/SP2..), navigateur etc) et essayer de reproduire le bug.

C'est bien mon problème !
Surtout que les utilisateurs sont pas toujours très collaboratifs, ou ne comprennent pas ce qu'on leur demande...

ça tient au fait que le même caractère (visuellement) n'est pas codé de la même façon suivant les cas de figure.

J'ai rencontré des problèmes similaires lors de classements par ordre alphabétique qui fournissaient des résultats erronés.

Ce n'est manifestement pas un problème pour mysql lorsqu'on lance une recherche directement avec l'expression saisie, mais par contre sha1 produit un résultat différent qui ne peut donc être retrouvé.

 

[thierry8]

est-ce que tu enregistre le mot hasher de la même manière que tu le compare ?

par exemple quand tu récupère ton mdp pour l'enresgitrer tu fais:

$mail=trim($_POST["mail"]);
$passe=sha1(stripslashes($_POST["passe"]));

et quand tu compare tu fais pareil ?
tu n'a pas par exemple oublié la fonction trim() ?
(ce qui fais que l'espace tappé maladroitement à l'enregistrement n'a pas été supprimé mais que lorsque tu compare il est supprimé = donc pas le même hashage)

 

[Fab le Fou]

Oui j'ai vérifier tout ça.

Je pense qu'une solution sera de vérifier tous les caractères saisis pour supprimer / remplacer tous ceux que je ne reconnais pas.

C'est la solution que j'ai utilisée pour un problème similaire où je devais traiter tous les caractères saisis non compatibles avec une url.

 

[thierry8]

Oui j'ai vérifier tout ça.

Je pense qu'une solution sera de vérifier tous les caractères saisis pour supprimer / remplacer tous ceux que je ne reconnais pas.

C'est la solution que j'ai utilisée pour un problème similaire où je devais traiter tous les caractères saisis non compatibles avec une url.

ça règlerait le problème, mais ce n'est pas la bonne solution.

si tout est bien fait, les caractères accentués ou non, ne posent pas de problème surtout lors d'un hashage..

 

[julisube]

ah les bugs non reproductibles, c'est la pire des choses qui puisse arriver

 

[Fab le Fou]

ah les bugs non reproductibles, c'est la pire des choses qui puisse arriver

C'est surtout que dans le cas d'un site web la majorités des visiteurs sont incapables de te dire quel est leur navigateur, leur système d'exploitation, etc. parce qu'ils ne savent de quoi tu leur parles.