Dans un site avec des sessions d'utilisateurs, il est fortement conseillé de hacher le mot de passe et de conserver uniquement l'empreinte dans la base de données.
Ainsi quand quelqu'un se connecte, on compare les deux empreintes.
 
Mais j'ai un petit problème, c'est au niveau de la fonction d'envoi du mot de passe en cas d'oubli.
Soit j'ai le choix d'en générer un nouveau et de l'envoyer à l'adresse mail de l'utilisateur. Problème : des crétins malintentionnés peuvent en toute impunité, s'ils connaissent l'adresse email du compte, générer un nouveau mot de passe pour un compte qui ne leur appartient pas.
Soit je conserve les mot de passe en classe. Mais c'est pas très éthique, confidentiel et encore moins sécurisé.
 
J'ai regardé un forum phpbb, qui lui stocke les mots de passe hachés (MD5 apparement)
Mais quand on lui demande d'envoyer le mot de passe par mail, il est capable de le restituer en clair. Dingue !    
 
Utilise-t-il un algorithme réversible ?
 
Que me conseillez-vous ?
Peut-on hacher avant le transfert en POST autrement qu'en javascript, ou simplement faire le hachage sur le serveur en PHP ?
 
Merci pour vos éclaircissements  

md5 n'est pas réversible mais y'a des rainbow tables pour avoir la réversibilité de certaines signatures.
Avec md5, en cas d'oubli, pas possible de redonner le mdp. Donc, le gars, en cas d'oubli, rentre le mail de son compte, le site regénère un mdp et l'envoi au mail donné. Je vois pas où est le pb puisque qq de malintentionné, même s'il a le mail du gars, il n'a pas le mdp de sa boîte mail, ne fera que changer le mdp mais le proprio du compte recevra un mail comme quoi son mdp a changé mais il aura le nouveau...

Oui, mais tu ne voudrais pas voir ton mail changé tous les jours.
Et je ne veux pas laisser cette possibilité...

Des tas de sites proposes cette fct, ça pose pas de pb. La proba de connaître un gars qui a un compte sur un site et connaître en + son mail avec lequel il s'est enregistré est très faible. Rappel : beaucoup de gens ont plusieurs adresses mails, certaines servant uniquement pour des inscriptions sur des sites où ils ne vont pas souvent. Y'a même des services qui proposent des adresses mail "jetables" (valables 1 fois, juste pour l'inscription). Donc je pense que c'est un faux problème.

utiliser md5 ou autre directement c'est aussi crétin que de stocket en clair. Il faut utiliser un sel + une fonction de hachage.

le sel rend plus sécurisé le hash, c'est clair, mais j'ai pas encore trouvé de rainbow table capable d'inverser le hash md5 d'un mot de passe du genre "ct19@-85é#"

Le sel c'est pas bon pour la tension ...
 
Sinon la seule façon de re-donner le 'vrai' mdp du gars, c'est de le stocker en chiffré (et pas en haché par md5 ou sha) par un algo réversible soit en symétrique (DES, AES, ...) soit en asymétrique (RSA ou autre).
Et pour répondre plus au premier post,
Peut-on hacher avant le transfert en POST autrement qu'en javascript, ou simplement faire le hachage sur le serveur en PHP ?
Le seul moyen crypto sûr de passer un mdp sur le web, c'est du faire du https et là, normalement c'est sécurisé.
Mais si tu restes en http non sécurisé la réponse à ta question est NON.
Et juste pour info : pourquoi tu ne veux pas le faire en js ?
 

Tu te rends compte que personne ne pète les mots de passe en sniffant alors que faire une injection SQL et récupérer le gros lot d'un seul coup c'est 1000x plus facile ?

'personne ne pète les mots de passe en sniffant' => est-ce que tu veux dire que https ne sert à rien ...
 
Dans tous les ça ne veut pas dire pour autant qu'il faut faire passer les mots de passe en clair ... dans ce cas là autant arrêter de faire de la cryptographie ...
L'injection sql, si le code est bien fait, ça ne devrait jamais se produire (bon, je sais c'est un idéal qui est loin d'être atteint en pratique).
 

Le https sert à quelque chose, mais c'est statistiques: l'écrasante majorité des vols de mots de passe se font en pétant un site web, à 99% par injection SQL (faut pas prendre les dev PHP pour des Einstein, 95% d'eux ne savent même pas ce que c'est qu'un prepared statement).
 
Le problème initial étant que les mots de passes sont stockés en clair ou de manière réversibles (simplement).
 
Quand quelqu'un perd sont de passe, on lui en génère un nouveau et c'est tout.
Quand tu perds tes clefs, tu ne demandes au serrurier de te refaire la même, il te change la serrure.
 
A bon entendeur, salut.

Perso les statistiques, je ne les connais pas donc bon, si tu le dis je veux bien te croire.
Après je disais ça juste du point de vue de ce qui est faisable ou pas ...
Moi je ne vois aucun problème à stocker un mdp chiffré avec un BON algorithme réversible mais pas simplement (il ya ... AES, Blowfish, E-C)
Et ce n'est pas pareil d' "oublier un mot de passe" que de "perdre des clés" dans un cas c'est une perte d'information (ça ne veut pas dire que quelqu'un d'autre va pouvoir récupérer ta clé parce que tu l'as perdue) alors que dans l'autre la clé physique n'a pas disparue et donc là, OUI, il faut la changer parce qu'on peut la récupérer ...
 
Dans tous les cas, que tu perdes ou pas ton mot de passe, que tu t'en fasse générer un nouveau ou que tu te fasse récupérer ton ancien, si le mot de passe est bien chiffré, c'est tout pareil ! C'est juste un choix de gestion...
Si tu arrives à récupérer un mot de passe en clair (ou facilement réversible) par injection sql c'est que le mec qui a fait le design de l'appli s'est chié, c'est tout !

Tu peux prendre l'historique sur 15ans de tous les vols de comptes de tous les grands sites web de la planète.

Parce que tout le monde n'a pas javascript activé.
Bon si, peut-être 99.999% des internautes, mais ca me trouerais le cul de faire un vieux truc en javascript tandis que certains site ont réussi à faire un truc en dur.
Mais si tu me certifies qu'il n'y a pas d'autres manière, je ferai ça  

Eh bien ça ne contredit pas ce que je dis, c'est-à-dire que le design de l'appli était à chier ... si les mdp doivent être stockés (non hachés) il faut absolument les chiffrer avec un algorithme assez puissant (algo + taille de clé).
 

Ben, je te conseille de le faire en js et puis après teste sur les 4 ou 5 principaux navigateurs, et si ça marche, tu pourras déjà t'estimer heureux
Comme navigateur je te conseille les suivants :
IE (6-7-8)
Firefox (3)
Safari (3)
Chrome (1)
Opera (9)
Si ça marche avec ceux-là, tu devrais déjà couvrir une bonne population !
Bon courage !
 

pour le md5 en javascript, si t'as pas déjà de script, tu peux prendre la lib que j'utilise dans mon appli Astres (cf ma signature). Elle marche même pour Netscape 4.7 La lib se trouve dans le répertoire /Common/

Merci rufo, je vais sans doute l'utiliser    
 
Wow, 1996, elle date un peu  
 
Je me renseigne aussi sur la fonction Mcrypt() de php, pour ainsi pouvoir restituer le mot de passe...

Et surtout, http://noscript.net
 
Quand au mdp, toujours stocker un salted hash (idéalement du SHA-1 ou plus récent), si il faut renvoyer le mdp, tu en génères un nouveau aléatoirement et tu renvoies ça.

Mais oui !

Non en cas d'oubli, envoyer un lien avec une sorte de clé bien sécurisée, parceque si on arrive à connaître la manière dont les clés sont génerées c'est foutu, et après avoir suivi le lien, l'utilisateur pourra changer de mdp.

ouais, comme ca le formulaire derriere prend la chaine déjà hachée, si la db est exposée il n'y a même plus besoin de cracker ou de fouiller une table quelconque, il suffit de balancer le hash tel quel. Bien joué.

C'est pas con    Dans un tel cas, le hashage ne sert plus à rien. Autant insérer les mdp en clair...

 
C'est pour ça qu'elle fonctionne sur Netscape 4.7

Une des principales règles de sécurité serait de ne jamais reverser un mot de passe.
 

 
Je dirais pas que c'est impossible, mais c'est tellement con que c'est improbable. Tente avec un password que tu es sur qu'aucun site n'a dans sa base de donnée (32 caractères alpha-numériques), et demande de restituer ton pass.
 
Si il t'est renvoyé, la conclusion est simple :
 
L'admin ne chiffre pas, ne hash pas les mots de passe. Pour un script type phpBB, c'est relativement simple, il suffit de supprimer les appels à la fonction md5. Certains le font, souvent des webmasters mal intentionnés pour avoir une base de mot de passe en clair (pour utiliser votre mail par exemple, si c'est le même mot de passe).
 
 
Pour régler le problème de génération intempestive de mot de passe, il y a une solution. Quand un utilisateur fait la demande de changer de mot de passe, générer (côté serveur) une clé aléatoire, stockée la dans votre base de donnée avec son timestamp, et envoyé là par email.
Pour obtenir un nouveau mot de passe, le membre devra valider ce lien reçu par mail, vous comparerez la clé du mail (aléatoire et temporaire, si la clé a été généré il y a plus de 24h, consideré là comme nulle) à celle stockée dans votre bdd, et si elles sont identiques, alors seulement vous générez un nouveau mot de passe.
 
 
De cette façon, seul le détenteur de l'adresse email relié au compte peut réellement changer son mot de passe.

J'ai réfléchi 2 minutes et j'en suis arrivé à la même conclusion. C'est ce que je pense faire.  
Je pense en plus ajouter un lien dans l'email pour permettre à la victime d'empecher le serveur d'envoyer de nouveaux mails à l'avenir à cette adresse.
Ainsi, le serveur n'enverra pas de mail aux adresses blacklistées et la victime ne sera emmerdée qu'une fois au maximum.
Oui oui ca se tient...
 
En revanche pour les forum phpbb, j'ai téléchargé la dernière version et je la fais tourner sur wamp. Or, en fouillant dans la bdd, on voit bien que les mots de passe ne sont pas en clair. Or on peut demander à le restituer en clair.  
J'en conclue que la fonction utilisée est forcément réversible. Or les sources des forum phpbb sont en libre service... ainsi que l'algo de décryptage utilisé. J'en déduis que la protection du phpbb ne sert à rien ? Que n'importe qui ayant accès à la base peut obtenir tous les mots de passe en clair ?

 
Non non non. J'ai utilisé phpBB, et jamais il n'a été possible de reverser les mots de passe, la protection utilisé étant le md5. Je n'ai pas suivi les dernières versions, mais ce serait étonnant d'avoir modifié cela.
Normalement, phpBB génère un nouveau mot de passe mais ne restitue pas l'ancien.
 
 
Par contre, chacun étant libre d'utiliser le script comme il veut, il est possible que des "mods" proposent de supprimer le cryptage md5 à l'inscription, de manière à restituer le password. Dans ce cas, le mot de passe est enregistré en clair (ou chiffré, mais c'est inutile).