tu peut utiliser blowfish (reversible) ou un chiffrage irreversible (md5) tu chiffre l'entree de l'utilisateur t tu la compare a ce qui est dans la bd. tu peux trouver blowfixh pour php sur google

Juste un petit post tardif pour repondre a Mr Pink, a propos des fonctions base64_encode() et base64_decode()

Je pense sincerement que ce ne sont pas des fonctions de cryptage a proprement parler mais de simple transformation de chaines de caracteres. En effet, il n'y a ici qu'une seule clef, qui est cette fonction, que tout le monde peut mettre en oeuvre.

Autrement dit, un odieux malfrat (et le mot est faible ) repere que tu utilise un codage de type base64, il copie ta donnee cryptee, l'inclue dans une fonction base64_decode et adios muchachos...

Je pense donc que cette fonction est a proscrire pour le "cryptage antivol" des données. Voila.

Faux, une personne qui a "cassé" ta sécurité, ne va s'encombrer à se connecter sur l'appli puisqu'il a accès à la base. Un pirate qui a accès à ta base à accès à l'applicatif et n'a donc plus cure de se connecter avec les login/pass obtenu.

Par contre, reste qu'il a les pass, sachant que les utilisateurs utilisent souvent le même pour leur boite, mail, leur login windows, ...

Comme toujours tout dépend de l'implémentation. Une bonne implémentation génère un "sel" à usage unique pour chaque formulaire. Par exemple, je stocke la clé "abcd" dans la base de données dans l'enregistrement de l'utilisateur 123. Son mot de passe est "password". Pour pouvoir se connecter, il doit envoyer le hash

md5(md5('password') . md5('abcd') . md5('123'))

(le "abcd" est inclus dans le formulaire, mais n'a pas besoin d'être renvoyé vers le serveur, même s'il n'y a pas vraiment d'inconvénient à le faire). Et à chaque fois qu'une tentative de connexion a lieu, la clé est changée. De cette façon, si quelqu'un renvoit le même hash (celui qui correspond à la clé "abcd") celui-ci ne marchera pas car depuis la clé a changé.

Ceci dit, comme je le dis souvent (c'est un topic récurrent ) si quelqu'un peut voir vos paquets TCP alors vous avez un plus gros problème que celui de se connecter à votre place sur un forum ou même sur votre compte mail

au fait : certaine personne te dirnt que le fait de hacher le mdp coteclient augmente la securite, car un hacker qui snifferait la connexion ne verrait pas le mdp. c'est faux, cela diminue au contraire la securite, puisque il suffit au pirate de connaitre la version haché du mdp pour acceder au site. et dans ce cas, s'il parvient a hacker ta BDD, il pourra se connecter avec tous les comptes...

Oki merci pour ces précisions

@+

comme je le faisais remarque plus haut, la recuperation du mdp c'est joli mais pas secure en general. a proscrire a mon avis. mieux vaut fournir un nouveau mdp et laisser l'utilisateur le changer. en effet, un cryptage cote client est inutile, a priori les fonction 64 aussi.

ceci dit, le sniffing sur internet necessite des conditions assez difficile a obtenir, donc le risque est limité a priori.. sauf si tes visiteurs ont un troyen sur leur ordi, mais dans ce cas.....

la seule solution non debile consiste a utiliser le protocole HTTPS ( SSH ), pas forcement disponible par defaut sur tous les hebergeurs...

les fonction md5 () et sha1 () sont à sens unique, elle doivent donc être oublier pour une récupération de mdp (crypt () je connais pas)

le mot de passe transite vers le serveur en clair mais vi le protocole http en POST donc protégée et d'autant mieux protéger que si l'input est mis en mot de passe. un cryptage javascript pourra toujours être trouvé par un hacker puisqu'il sera fait sur sa machine il est donc inutile de coder un mdp en javascript.

ppour les fonction en base 64, je ne connais pas non plus

Oups un oubli :

- Les fonctions base64_encode() et base64_decode() peuvent-elles servir à un encryptage fiable des mdp ? Dans le cas où on crypte côté serveur.

@+

Bonjour,

Je rebomdi (pas trop haut :p ) sur ce sujet pour vous posser quelques questions :

- Dans le cas où on veut pouvoir envoyer un mdp stocker crypter ds sa BDD à un utilisateur, on est obligé de crypter soit par mcrypt() (comme présenté ds le tuto), soit par des algo personnels (dur, dur), employant des méthodes connues ? Ici je suis obligé d'oublier les md5(), sha1(), crypt() intégrés à php ?

- D'autre par, je me dis (je suis totalement néofite dans ce domaine), que quelque soit la méthode, mais si on crypte le mdp via un language interprété côté serveur, le mdp va transité en clair du poste client vers le serveur. Est-ce que je me trompe ? Du coup, vaut-il mieux crypter le mdp côté client avec du javascript ?

- Dernière interrogation, existe-t-il des outils permettant de tester les trames réseau et les informations qui partent du client en direction du serveur afin de contrôler les défauts qu'on laisse passer dans son code. Par exemple, pour le SQL, TOAD fourni une analyse des requêtes assez poussée permettant de visualiter là où on remonte une table complète alors qu'on pourrait mieux faire, etc...

Merci d'avance pour vos conseils.
@+
MrPink

ah, et j'oubliasi : le principe du cryptage assymetrique ( cle publique / prive ) ne s'applique pas du tout dans le cadre de protection de mot de passe.. par contre, si tes utilisateurs possedent PGP ou tnunderbird avec le plugin enigmail, tu peux leur proposer de stocker leur cle publique pour leur envoyer leur(s) mot(s) de passe via un mail cryptés..

je suppose que c'etait "histoire des codes secrets", de Simon Singh ( qui a aussi ecrit "le dernier theoreme de fermat" )... en effet, c'est passionnant, haletant, surtout le passage Alan Turing VS la machine a crypter des allemands ( enigma) pendant la seconde guerre... mathematiques, espionnage, courses contre la montre, un vrai thriller et une part inconstestable de la victoire des allies..

sinon, on a deja eu un debat sur ce sujet ya pas tres longtemps..., fais une petite recherche ! mais en gros, la regle d'or a mon sens en cryptographie, c'est que toute fonction qui n'est pas indispensable est a proscrire. le fait de pouvoir rendre son mot de passe a un utilisateur en cas d'oubli est a mon avis accessoire ( suffit d'en generer un au hasard et de lui envoyer ) : s'il l'a oublie, c'est qu'il ne lui manquera pas, et si vraiment il veut le choisisr, prevoir une fnction qui lui permet de le changer, c'est un effort minime pour l'usager, et cela t'evite d'utiliser un cryptage symetrique... en effet :

- si tu utilise un cryptage symetrique, c'est qu'il y a une cle quelque part. meme si elle est bien planquee, sa simple existence est un danger potentiel et inutile : si un pirate met la main dessus ( c'est tout a fait possible ), il sera en mesure de decoder tous les mots de passe.
- en plus, un cryptage symetrique est plus couteux en temps de calcul, plus complexe a rendre sûr ( cf juste au dessus ). sans parler du fait qu'un mdp hasché a une taille fixe -> bon pour la BDD

donc a mon avis, il n'y a pas a hesiter : c'est haschage point barre. c'est une question de bon sens ( et d'ethique, comme l'a dit qqn plus haut ). a priori, PHP permet de hascher en SHA-1, voire en SHA-256 pour les paranos. ( mais MD5 est encore tres secure et trs loin d'etre cassé, contrairement a ce qu'on entends ici ou la, on a trouve des collisions sur des cas particulier, c'est tout.)

accessoirement, la fonction de hascahge ( contrairement a une fonction de cryptage ) n'as pas du tout a etre planque, vu qu'elle fait toujours la meme chose, mais que ce qqchose est irreversible.

si tu as d'autre question...

Sans entrer trop en détail dans les algorithmes (enfin certains apprécient de comprendre jusqu'au bout), la crypto est très intéressante, surtout quand on regarde comment elle a évolué au fil des siècles.

Dans le cadre d'un exposé sur le cryptographie quantique, j'avais lu un bouquin qui racontait l'histoire de la crypto, faudrait que je retrouve le titre.

ok merci

je pense avoir fait le tour de la question (ou presque)
je met résolu au sujet, mais si certains veulent donnés un point de vue ou un conseil, lacher vous

ça fera un topic interessant pour qui decouvre le cryptage