Bonjour,
 
 j'aimerai savoir si il est possible, en PHP, de decrypter un mot de passe encrypter en md5.
 
 Le but est le suivant. J'ai une table qui contient les informations des utilisateurs. Dans cette table il y a 2 champs : 1 champ utilisateur et un champ login et un champ mot de passe.  
Le champ mot de passe contient le md5 du mot de passe associé au login
 
 Quand j'edit l'utilisateur, j'aimerai que dans le formulaire je puisse redefinir le mot de passe. Il me faut donc le mot de passe en clair a mettre dans le champ input type password pour pouvoir le'ancien mot de passe par defaut (et eviter à la validation du formulaire de faire le md5 d'un md5 de mot de passe)
 
Avez vous une solution SVP ?

Malheureusement pour toi, le "Message Digest" correspond a un hachage one-way. Il est donc impossible "avec des methodes standards" de recupérer ton mot de passe nativement "encrypté" par md5.

Comment il fait Joce pour remettre en clair le password dans le champ lors de l'edition des preferences ? Il mettrait le password en clair dans la base  

1) Moi je vois pas le password...
2) il peut très bien crypter le password et non pas utiliser une fonction de hashage.

tu peux comparer 2 passwords cryptés.
pwd dans cookie crypté = pwd dans bd crypté.

Pourquoi pas je vais envisager ça

joce il fait des requètes SQL inutiles pour la sécu mais il met le password en md5 dans les cookies alors...

md5 c'est pas un algo de cryptage

confondre hashage et cryptage c mal

Bon ben tantpis, si l'user paume le mot de passe je lui en redonne un autre

 
D'ou le "encrypté" entre guillemet...
 
Sinon pour Joce je ne connais pas l'implementation qui a été faite pour la gestion des mdp... Ce que je peux te confirmer c'est que si tu veux stocker ton mdp "encrypte" et l'afficher ensuite en clair en modif, c'est pas vers md5 que tu dois te tourner

On dit chiffré
 
"encrypté" c'est un affreux anglicisme.

sinon, méthode Brute Force pour réafficher le mot de passe de l'utilisateur Mais je suis pas sûr qu'il est la patience d'attendre.

Alors... comment te dire... non.
MD5, s'il n'est pas réversible, c'est pas passke c'est un algo super compliqué ou pas hackable. C'est parce qu'il repose sur du modulo. L'idée, c'est que 2 valeurs peuvent très bien être différentes tout en ayant le même encodage MD5.

Et alors, avec la méthode brute ça marchera toujours, il faudra peut être mille an mais ça marchera. Il suffit de demander à l'utilisateur de rentrer un mdp de 4 chiffres max et ça ira vite de le retrouver  

Non. MD5 donne toujours un résultat sur 128 bits, quelle que soit la longueur de chaîne d'entrée. Donc au total, le seul truc en brute force que tu peux espérer faire c'est retrouver une chaîne ayant le même encodage MD5 que le password et pour ça, t'as une chance sur 2^128.

   
je suis pas sûr de tout comprendre... Le principe de la force brute , c'est d'essayer les password 1 à1, dans mon cas 0000,0001,0002 .... Soit 10 000 possibilités et de passer chaque de ces possibilités par la fonction MDM5 et de comparé le résultat obtenu au résultat stocké. Enfin moi je voyais les choses de la sorte, j'ai peut être pas tout capté. Peux tu m'expliquer si je me trompe?

Bin en fait, MD5 introduit un concept de salt dans son algo. Pour bien comprendre le procédé, faut se référer à une page qui explique comment ça marche mais en gros, c'est une variable qui modifie le comportement de l'encodage.
Donc si t'encodes en MD5 de ton côté en utilisant un salt autre que celui qui a été choisi par le développeur, ba tu l'as dans l'os
En même temps, je me base sur ce que j'ai vu dans la certaines fonctions utilisant MD5, je sais pas quel est le comportement sur MySQL. Je crois que cette possibilité de salt n'est pas obligatoire dans l'implémentation de l'algo.

Ben non, tu n'est pas obligé d'utiliser de salt et comme le but c'était de retrouver un password que tu avais encodé, tu connais le salt (enfin même si cette discussion est débile tant retrouver un pass comme ça est débile), et puis même s'il y a un salt, je vois pas le rapport avec la taille du résultat sur 128bits.

si le but est de recupérer le password depuis le MD5, c'est impossible (enfin quasi)! tout ce que tu peux faire (a la limite si tu as plusieurs année devant toi ) c'est de recupérer un password qui donne le même resultat sur 128 bit apres traitement MD5. mais ce ne sera probablement pas celui d'origine.
 
 
 
 
 

Y a quelque chose que je ne saisie pas.
Tu ve changé le mot de passe lors de l'édition?
Parce que tu pourrais détourné ton problème.
par exemple:
formulaire d'édition avec juste le login, si tu veux modifier le login. Et si tu veux aussi modifier le mot de passe tu coche un 'CHECKBOX' et tu met un nouveau mot de passe dans un 'TEXT'.
Après tu fait les modifs dans ta base suivant ce que tu as fait dans le formulaire.
Enfin bref, il ya moyen de contourner ton problème.

 
Sieur Capello eut alors été bien inspiré de relever "implementation" comme anglicisme !!  
 
Sinon pour Taiche, ca n'est pas 1 mais bien 4 var qui sont en entrée. Le resultat est effectivement ue message digest (ou empreinte ou clef) sur 128bits.

Rien à faire, je ne comprends pas... Si la password est au choix a,b,c ou d , en 4 coups de passage dans la fonciton MDM5 on trouve le password non  

Heu 4^4 exactement.
Mais là ce n'es pas le cas, c'est quand même des mot de passe + grand.  

 
le probleme du MD5 ( un problème qui nous arrange d'ailleurs) :
 
ton mdp fait 4 lettres, ex : "mots" apres hashage il va devinir un truc imbouffable sur 128 bits que l'on va appelé par commodité "X"
 
si tu fais un force brute pour retrouver le mdp qui donne "X" (je rappel que le sujet du topic n'est de casser une page de loggue mais redonner à un user son exact mdp !), tu n'auras pas forcement comme resultat "mots" mais peut-être "passe" ou "untrucencoreplus,ons'enfoudetoutefaconleresultatesttoujourssur128bit" qui pourtant on donne "X" après hashage.
 
je ne sais pas si j'ai reussi à me faire comprendre    
 

Ah oui, ça je le savais , je suis bien d'accord. .
Enfin si la fonction de hashage est bonne, le risque de collision est faible. J'étais juste pas d'accord avec le fait qu'il faille tester 2^128 combinaisons... (sauf si le mot de passe est grand .)

Bon, tout çà c'est super, mais :
 
A quoi çà sert de stocker le MD5 d'un mot de passe dans une bdd au lieu de la stocker en clair ?
 
A priori, le mot de passe sert à identifier un utilisateur avant de lui donner accès à certaines fonctions/infos. infos en général stockées dans la même DB...
 
Donc si un Malveillant Personnage parvient à accéder à la BDD, lire les mots de passes des utilisateurs ne lui sert qu'à rigoler devant les choix débiles des utilisateurs moyens en matière de mots de passes !
 
Bref, ce qu'il faut protéger c'est la BDD, pas les mot de passes.
 
En revanche, le MD5 ou équivalent peut être utiliser dans le protocole d'authentification.
Exemple simple :
 
L'utilisateur demande une ressource protégée.
Le serveur lui renvoie un formulaire de saisie du login et mot de passe, et en plus un grain de sel aléatoire ( qu'il conserve dans la session ).
L'utilisateur saisi le login et le mot de passe, et au moment de l'envoyer, un bout de code an javascript remplace le champs "mot de passe" par son MD5 en utilisant le grain de sel reçu du serveur.
Le serveur n'à plus à calculer à son tour le MD5 du mot de passe du login reçu avec le grain de sel conservé en session.
 
Bref, je pense que l'important c'est d'éviter de laisser passer des mots de passe en clair sur les réseaux.
 
Ca sert à rien de construire un coffre fort pour y enfermer la combinaison !

 
Pour pas que l'admin qui voit le contenu de la BD ne soit tenté de se connecter au compte hotmail du gars qui s'est incrit et qui 9 fois sur 10 utilise le même mot de passe partout

je suis à 100% avec Mara's Dad, stocker en MD5 n'apporte quasiment rien à mon sens
 
si l'admin d'un site fais mauvais usage des infos qui apparaissent c'est son problème
 
dans ce cas là on pourrait penser aussi à l'utilisation frauduleuse de toutes les cartes bancaires qui passent entre les mains des commerçants...

 
Mauvaise réponse, çà m'étonne de toi !
 
L'admin, il peut avoir le mdp quand il veut ! Il suffit de l'intercepter au moment de la comparaison par exemple.
 

 
ca sert aussi à assurer aux utilisateurs que ceux qui ont acces à la base de données (le DBA par ex) n'ont pas acces à leurs mots de passe...
 
ensuite pour assurer une authenfication efficace ce que tu décris correspond à la stratégie des navigateurs avec clé publique et clé privée, diablement efficace même !
 
EDIT :grillaid

Euh, et si t'as pas envie que l'admin voie tes mails ou autres joyeusetés cachées par le passoueurde et qui sont pas forcément en base ? C'est pas passke t'es admin d'une BDD que ça signifie que t'as droit d'accéder aux infos disséminées un peu partout qui sont liées au compte et au mot de passe du user

 
   l'admin aura le mdp hashé et pas en claire ! le hashage ce fait coté client, donc l'admin n'a jamais accès au mdp !

  Et comment ? En foutant des traces dans le code ? Passke si c'est le cas, alors personnellement, dans ce genre de cas je distingue admin et développeur. Autant pour un p'tit site perso où admin et dev c'est pareil, le pass en clair peut être utile, autant dans une boîte où l'admin système n'a pas accès au code il faut faire le distinguo

 
ouais enfin entre aller voir le contenu de la BD et intercepter un truc qui s'exécuter sur le serveur y a une grosse différence

 
Doublement    !
 
Et j'insiste !
Pour les admins (et les Malveillants Personnage)s, les mots de passes des utilisateurs ne servent à rien !
Qu'est c'qu'y peut empêcher joce par exemple d'inserer en base un post bidon et de le lier à ton pseudo ? Rien du tout.
 
D'ailleurs, dans le forum les MDPs sont en clair !  
Ne serait-ce que pour pouvoir les envoyer par mail aux pov' gars qui les perdent.

 
Pardon ?? Coté client ??   Euh, on parle bien de PHP la ?

 
Si le gars met le même pass pour sa boîte mail que pour son login sur ton site...

C'est sûr que si je voulais, je pourrais intercepter les mots de passe avant de les passer au mdm5... Mais je préfère les passer au mdm5 simplement pour ne pas le voir quand je consulte la table, je préfère.. De plus si quelqu'un tombe sur la table, il ne verra pas les mdp. Enfin, vu que les 3/4 des gens ont un password de 5 caractères, ça irait vite pour le retrouver mais je préfère ça à l'es voir direct en clair. Je pourrais rajouter un salt mais il serait dans le code ça n'avancerait pas à grand chose.

J'insiste aussi : dans une boîte où l'admin système n'a pas à connaître les infos de chaque user, il est normal qu'il n'ait pas accès au password.
Et si la BDD se fait cracker soit par oubli de patch, soit par utilisation éclair d'un exploit rendu public quelques jours avant avant tout patch de sécu sur ta BDD ? Bin le hacker récolte les pass de tous les users et fait ce qu'il veut derrière