Vos avis à propos de MD5

Salut,

il a été démontré en 2004 que le hashage md5 n'était pas fiable (faire une recherche sur collision md5).

En même temps il n'est possible de le hacker (à ma connaissance) qu'en utilisant une attaque de type force brute donc il suffit de limiter le nombre d'essais d'authentification (par ip et/ou dans une période de temps donnée) pour s'en protéger.

Au besoin le plus simple est encore de se tourner vers sha1 ou encore de faire une recherche sur php sha256.

Tymlis a écrit :

...

- str_rot13 n'est pas une mesure de sécurité très convaincante. Il suffit de réappliquer str_rot13 à la destination pour retrouver la source.
...

Nolem a écrit :

... pour noyer le poisson avant le hachage

Je crois que le principe est de cumuler les protections (sans s'emmêler les pinceaux) str_rot13+sha1 ou sha256 ou crypt+un petit peu de sel.

++

Bonjour, j'aimerai soumettre une idée et avoir vos avis la dessus: que pensez-vous de haché en md5 plusieurs fois?

md5(md5($mot_de_passe));

J'ai observé que en tapant le md5 entré en base sur google, celui-ci ne trouvait plus de "traduction". Normal on hache quelque chose qui n'est pas dans les rainbow tables.
Modifié par SuperBen (01 Sep 2009 - 13:57)

C'est une fausse bonne idée de hasher deux fois le mot de passe, cela réduit le nombre de possibilité en l'enfermant dans un espace délimité (strings de 32 caracteres hexadécimaux). C'est alors encore plus simple de construire un dictionnaire des résultats, et annule l'effet du salt

Arhhh .. je sents que je vais faire faire des bons a mes Amis lecteurs,
Et un UP énorme a cette discution..

En préambules la phrase de Coluche;

a écrit :
Ce n'est pas parcequ'ils sont nombreux a avoir tort, qu'ils ont raison
Coluche

Alors nous revoila a parler du MD5 et autres , mais pourquoi faire ?
Si je stoques les numéros de cartes banquaires je les mets enclair non ?
Mais OUI bien sur, par exemple la Fnac ou d'autres ne me les demandent plus
or la contrairement aux mots de passe il leur faut l'info , donc MD5 impossible !
Mais au fait prenons un forum bien fait, sur le micro dans le cookies il n'y a que le pseudo, et un code trés long (avec un format genre session ID)
c'est ça qui circule.

En fait s'il y avait une véritable raison d'avoir un hachage cela voudrais dire que toute valeur d'une base de donnée peut étre lue

NON NON une base bien protégée est pratiquement inviolable ! alors pourquoi y mettre un mot de passe haché ????????
Modifié par Christele (20 Mar 2010 - 14:11)

Bonjour Christele,

Une des idées derrière l'utilisation de MD5 est de stocker de l'information sensible dans une base de données d'une manière théoriquement irréversible, comme un mot de passe, en évitant qu'un individu puisse voir en clair ou puisse déchiffrer ces informations.

Avantages
- Le propriétaire du site et son équipe, lorsqu'ils travaillent dans la base de données ne peuvent pas voir les mots de passe en clair. Avec un MD5 bien construit, ils ne devraient même pas pouvoir les déchiffrer
- Si jamais le site Web se fait pirater et que la base de données se fait voler, l'impact est moins important. Certains utilisateurs utilisent le même mot de passe pour plusieurs sites, alors si un pirate réussi à obtenir le mot de passe d'un utilisateur, il sera facile pour lui de retrouver les autres sites que visite cet utilisateur grâce à ses autres informations (nom, pseudo, courriel, discussions).
- S'il y a une faille d'injection SQL dans le site qui permettrait de faire un SELECT sur les mots de passe ou une autre information sensible, ceux-ci ne seraient pas déchiffrables.
- Je pourrais continuer toute la journée, mais là j'ai faim!

Pour ce qui est des numéros de carte de crédit, ceux-ci peuvent être encryptés (chiffrés) avec une clé, et ensuite déchiffrés avec une clé. Ce n'est pas MD5 qui sera utilisé pour ce type d'information, mais une autre fonction de chiffrement. L'avantage est qu'encore une fois, les données sensibles ne sont pas affichées en clair dans la base de données et si quelqu'un réussi à récupérer ces informations, par une faille d'injection SQL par exemple, s'il ne connaît pas cette clé, il ne pourra pas déchiffrer les numéros de carte.

Christele a écrit :
NON NON une base bien protégée est pratiquement inviolable ! alors pourquoi y mettre un mot de passe haché ????????

Tu réponds toi-même à la question. J'ai mis un indice en gras.
Modifié par Tony Monast (20 Mar 2010 - 16:11)

Hello,

au passage il existe plusieurs formules de paiement en ligne et les sites du genre de la FNAC ont le PACK Mega Plus Plus qui fait que tu crois être sur le site de la FNAC alors que tu es en fait sur le site de la Banque : du coup aucune info bancaire n'est jamais stockée dans la BDD de la FNAC.

Christele a écrit :

mais sagissant de ce que nous gérons boffff.

Le niveau de sécurité à mettre en place peut évidemment varier selon ce que vous gérez. Je pense tout de même que le minimum est de chiffrer (MD5 ou fonction Encrypt/Decrypt) les mots de passe des utilisateurs pour les raisons précédentes, notamment au point de vue de la sécurité, mais aussi par extension au point de vue confidentialité.

Prenons un scénario où tu aurais créé un site sans prétention avec un petit forum, sans chiffrer les mots de passe. Je ne veux pas aller trop dans les détails, mais sachant qu'il est plutôt fréquent que des gens utilisent le même mot de passe pour plusieurs comptes, si par négligence ou incompétence ton petit site sans prétention possède une faille d'injection SQL et qu'un pirate arrive à récupérer très facilement les mots de passe, il pourrait aisément faire beaucoup de dégâts à certains membres. Je reste vague pour éviter de donner des idées. Vulgairement, on le fait donc pour les deux raisons suivantes :

- Si ton site est piraté, c'est quand même de ton devoir de limiter les dégâts à ton propre site
- Par respect et prévention pour les membres, on essaye de les protéger contre leur propre négligence.

Christele a écrit :

Heyoan Oui je sais bien que la fnac et autres opérent ainsi, mais quand symantec par exemple me débite tout les ans sur ma carte ils font comment ?

La même chose. J'ai intégré quelques API de passerelles de paiement et il est possible de créer des paiements récurrents. Le paiement classique et le paiement récurrent est géré par la banque.

Sinon, c'est comme j'ai dit, il est possible d'utiliser une fonction de chiffrement et de déchiffrement pour certaines données sensibles (encrypt/decrypt).

Je me dis que chiffrer les mots de passe est tellement simple que ne pas le faire est tout simplement de la négligence ou de la paresse.
Modifié par Tony Monast (21 Mar 2010 - 19:04)

Bien sur nous cherchons tous avec nos idées, et je vous l'ais dit clairement, vos arguments coulent de source même (ça a fait rire Heyoan) Bien sur nous pouvons en débatre longtemps, mais il faut bien arréter si non Heyoan va me dire que je trolles .

Alors encore un point, puisque tout est sensible, j'en reviens a l'exemple du forum, est'il plus embétant qu' un mot de passe d'un abonné soit trouvé,
ou tout bétement le mot de passe de connection a mysql soit lu ...
même s'il est bien que caché, il est en clair dans un include

Et aprés quand je vois avec horreur le nombre de site ou le mot de passe
de phpmyadmin est damandé tout bétement dans mon_site.com/phpmyadmin/
alors OUI ce mot de passe devrais étre haché mais justement c'est pas possible !
Modifié par Christele (22 Mar 2010 - 02:29)

En cas de piratage, il y a à la base au moins deux conséquences possibles :

A. Le site est attaqué, détruit, altéré et les dégâts se limitent au site lui-même.
B. La base de données est récupérée et le pirate s'attaque aux membres qui utilisent le même mot de passe partout.

Le MD5 est là pour éviter que le piratage se propage jusqu'aux membres, c'est-à-dire qu'il s'agit d'une protection contre la conséquence B.

Christele a écrit :

est'il plus embétant qu'un mot de passe d'un abonné soit trouvé,
ou tout bétement le mot de passe de connection a mysql soit lu ...

Tout dépend du niveau de sécurité mis en place. Le plus embêtant est évidemment que le mot de passe à la base de données soit connu, car cela implique alors que le pirate peut avoir accès à la base de données, donc aux enregistrements des tables, donc aux mots de passe des membres. C'est donc une judicieuse et juteuse raison, encore une fois, de masquer/chiffrer les mots de passe des membres.

Christele a écrit :

même s'il est bien que caché, il est en clair dans un include

La différence est que pour lire le mot de passe de la base de données elle-même, il faut avoir accès au système de fichiers du serveur, contrairement aux mots de passe DANS la base de données qui peuvent être récupérés s'il y a une moindre faille SQL dans le site. Accéder au système de fichiers via une faille SQL demande quand même un peu plus de compétences et une configuration serveur bien particulière.

Je pense comprendre où tu veux en venir, même si je n'en suis pas sûr. Tu te demandes pourquoi on s'acharne à chiffrer les mots de passe des membres, et qu'on ne chiffre pas le mot de passe de la base de données elle-même? Pour y répondre, je vais prendre quelques exemples :

- Si un pirate arrive à accéder au code source du fichier contenant le mot de passe de la base de données, cela implique qu'il y a de fortes chances qu'il a déjà accès à l'ensemble des fichiers du serveur, incluant les fichiers de la base de données. Le mot de passe n'est donc plus vraiment nécessaire pour récupérer les données de la base de données. Son chiffrement serait inutile
- Si on chiffre le mot de passe de la base de données pour éviter que l'équipe de développement le voie, c'est un non-sens , car l'équipe doit de toute façon accéder à la base de données pour travailler

En Coldfusion par exemple, je ne fait qu'indiquer le nom de la datasource dans mes requêtes. En aucun temps les identifiants de la base de données sont dans les fichiers du site. Ils sont gérés via une interface d'administration, elle-même protégée par mot de passe chiffré. Il y a sans doute une possibilité de le faire aussi dans PHP si on souhaite réellement ne pas afficher en clair le mot de passe de la base de données dans un include.

Dans le même ordre d'idées, pour les grandes structures, c'est fortement possible que tous les fichiers entiers soient chiffrés, que ce soit les mots de passe ou le code source lui-même.

Christele a écrit :

Et aprés quand je vois avec horreur le nombre de site ou le mot de passe
de phpmyadmin est damandé tout bétement dans mon_site.com/phpmyadmin/
alors OUI ce mot de passe devrais étre haché mais justement c'est pas possible !

Je n'utilise ni PHP, ni phpmyadmin, alors je ne suis pas sûr de comprendre ce que tu veux dire par là.

En conclusion, même si un moyen de sécurité n'est pas infaillible dans tous les scénarios possibles, ça ne veut pas dire qu'il est futile, et même si une information est moins sensible qu'une autre, ça ne veut pas dire de se priver de la protéger.

Troll-à-Florent-V-qui-n'aime-pas-les-analogies a écrit :

Ce n'est pas parce qu'on peut casser les cadenas qu'il faut arrêter d'en mettre!

Modifié par Tony Monast (22 Mar 2010 - 21:19)

Tony Monast a écrit :
En cas de piratage, il y a à la base au moins deux conséquences possibles :

A. Le site est attaqué, détruit, altéré et les dégâts se limitent au site lui-même.
B. La base de données est récupérée et le pirate s'attaque aux membres qui utilisent le même mot de passe partout.

Bonsoir,
Je rentre et trouves ta réponse mille mercis d'avoir pris ce temps .
Bien des choses que tu dis sont convaiquantes, mais le plus marquant pour moi aura été cet aspect altruiste de dire:
Même si on me pirate mon site et mes bases de données , je protéges mes abonnés !
Cet éclairage change définitivement ma façon de penser merci.
Merci aussi a Heyoan
Des débats sans passion ni brutalitée , voila pourquoi je suis fidéle