Bonjour tlm!
 
g eu l'occasion de lire ici (sur ces forums) de longs et très intéressants posts au niveau de la sécu en http, l'identification, les variables qui transitent en clair ou en codé sur des réseaux, etc...
 
Alors je voulais savoir si g tort ou po:
le seul moment critique au niveau de la gestion d'un password, c quand l'utilisateur l'envoie vers le serveur..
Mais alors: une fois cette étape franchie, quel est l'intérêt de le crypter ?? Le md5 de php n'agit que lorsque ce mot de passe est arrivé jusqu'au serveur (donc il reste en clair avant ça)..
Dès que l'utilisateur est identifié, il n'a + besoin de ce paramètre pour lui permettre d'accéder aux autres parties autorisées d'un site..
 
Le seul "avantage" que je vois dans l'encodage md5-php d'1 mot de passe, c de le rendre illisible pour l'admin de la BDD. Mais est-ce bien un avantage ??
 
Quelle est la fragilité du système suivant:
*lors d'une inscription* saisie du mot de passe > envoi en clair vers le serveur > enregistrement en clair dans la BDD > ID unique & confidentiel mailé à l'utilisateur
*lors d'un problème d'identification* demande du mot de passe > envoi d'une alerte utilisateur (accompagné de l'ID unique & confidentiel) car mot de passe perdu ou oublié > recherche dans la BDD > envoi du mot de passe trouvé à l'utilisateur
 
MERCI D'AVANCE
 
p.s: quoique si un intru accède à la BDD...

Vos avis m'interesse aussi...
sinon ça veut dire que tous les sites proposant l'envoie d'un email avec le mot de passe en cas d'oubli ne le crypte pas en md5...? c'est quand même la majorité des sites !

Le cryptage/hachage des MDPs sert à protéger celui ci une fois qu'il est stocké, au cas ou il y ait une intrusion dans la base ou une faille de sécurité (qui rende tout ou partie de la base accessible), le stockage des MDPs est critique au niveau de la sécurité, car le "hacker" a tout le temps nécessaire pour accéder à la donnée (alors que pendant le transfert il lui faut exercer un contrôlle permanent sur la base)
 
Scarf3ss3 -> le MD5 c'est pas du cryptage a proprement parler, c'est du hachage (comme le SHA), c'est à dire un cryptage non réversible.
Les sites qui peuvent renvoyer le MDP, soit ils ne cryptent pas (et stockent les MDPs en dur) soit ils utilisent un cryptage réversible (avec des clés)

Pour l'intrusion dans la BDD, c au niveau de l'hébergeur que ça se passe..
 
Après c vrai que même si c l'hébergeur qui fait mal son boulot, ça ne change rien au résultat..
 
 
Ptet qu'une sauvegarde journalière de la DBB suffit dans ce cas..?

utiliser l'https pour le transit du mdp, plsu un hashage pour pas avoir le mdp en clair dans la base c'est mieux.
 sinon sans https, tu peux generer le md5 cote client en javascript et l'envoyer vers la base, ca doit etre faisable aussi

Parce que bien sûr le programmeur ne laisse jamais de faille permettant de faire une jolie petite SQL injection

un hashage n'est pas un cryptage, même non réversible. Un cryptage se doit d'être réversible. Le hashage n'as pas le but que le cryptage.

 
le mot de passe a été saisi donc il est connu de l'utilisateur ...
pourquoi le renvoyer en clair ??
 
si il l'as perdu genre bout de papier qui traine alors je considère qu'il a été découvert-cassé, je genere un nouveau mdp que j'envoie en mail et je le change dans ma BDD !
 
mais a ce moment là, (mode parano) comment sécuriser le mail ?  
 
la je vois pas mais bon ....
 

signature pgp

non pas seulement une signature ...
 
mais aussi un cryptage : il s'agis de s'assurer que le mdpest lu que par le destinataire !

un cryptage pgp alors

euh.. A la base je parlais po trop de ça.. https, pgp, ces outils sont intéressants mais c po vraiment là-dessus que je voudrais insister
 
note: ui on peut facilement md5-er un pass avec JavaScript, mais ça implique d'autres contraintes..
 
En fait j'aimerais conserver mes mdp dans la BDD sans les encrypter, ou alors ptet utiliser une méthode de cryptage par clé pour les retrouver simplement, ce qui permet de renvoyer le pass à l'utilisateur.. Je n'aime po trop le principe de regénérer un pass, non po que ce soit inutile ou quoi, au contraire c + sûr, mais en général ce type de pass se perd ou s'oublie trop facilement
 
Ce que je veux c vraiment un max de "convivialité", à commencer par le choix personnel du pass. Dès qu'il y a génération de mdp ça implique une perte d'utilisateurs, qui sont rebutés (trop facilement certes) par l'idée de devoir le retenir etc..
 
ps: bonne remarque Gizmo Mais si on part de ce principe, rien n'est sûr..

Stocker le hash (MD5 ou SHA) du pass une fois que celui ci est arrivé au serveur (donc avant stockage), ca n'empeche pas que l'utilisateur le choize tout seul comme un grand hein
 
Simplement si il l'a perdu, là il faudra en générer un nouveau temporaire

temporaire jusque quand ? qu'il se crée un nouveau compte  
 
je croyais que le md5 était à sens unique

...
ben non quand il arrive sur le site il fait "me renvoyer un mot de passe" en entrant son login, toi tu vérifie le mail associé au login, tu crées un nouveau MDP que tu lui envoies à ce mail et tu stockes le MDP créé aléatoirement dans ta BDD (hashed).
 
Ensuite libre au mec de garder le MDP créé par ton script ou d'entrer un nouveau MDP a lui

jme fais mal comprendre dsl..  
 
 
en gros pour moi s'il y a changement de mot de passe depuis l'extérieur (en l'occurence depuis l'admin - humain ou prog), c mauvais!
 
Je comprend bien qu'à partir du moment où il se logge il peut - si c géré - modifier son mdp. Mais je veux que cette action soit totalement libre, sans aucune contrainte.
 
Je c je bloque ^^
 
note: ptet qu'en fait un cryptage par clé paraît être + approprié à mon "besoin". Mais c - sûr comme systéme.. N'est-ce pas ?

Ben c'est moins sur dans la mesure ou il te faut stocker la cle qqpart, et obtenir la cle donne acces a la DB
 
Et si il oublie son MDP, dans son cul, pas de pitié, il a qu'a apprendre a pas etre con ce trou de balle de lambda user de merde

Vu comme ça en effet c résolu!!!  
 
Mais je ne veux surtout po perdre d'utilisateurs à cause de ça.. (apparemment c vraiment un facteur de perte d'user ce foutu mdp)
 
Bon, je v voir..
 
MICI pour tous les renseignements!!

lol  
 
ouais mais faut être tolérant Masklinn..  
 
 
Même si certains sont des boulets, + y'aura d'utilisateurs et + je serais content