Bonsoir tout le mode.
J'essaye de faire de l'authentification avec php et mysql.
Selon certains articles sur le sujet, j'ai lu que pour sécuriser l'accés aux mots de passe, il faut les crypter. Pour cela, il faudera quand un nouvel utilisateur veut s'inscrire, il choisit son login et son mot de passe, et si c'est ok alors le login sera chiffré via le md5 et sera stoqué sous une forme crypter. quand le user aura besoin de se connecter, il va saisir son mot de passe alors mon programme va crypter ce mot de passe et va le comparer avec celui stocké dans ma base.
Le problème c'est quand un user demande à récupérer son mot de passe(mot de passe oublié), il sera impossible de le faire puisque le md5 est à sens unique, on pourra pas le récupérer.
Alors comment faire ?
est ce que c'est ça le principe ou je me suis trompé quelque part?

Je suis d'accord avec toi J_G, mais petit conseil comme ca pour progrima, afficher le mot de passe à l'écran pourquoi pas (quoique, si il y a qqun derrière qui regarde, c pas top), mais surtout il faut l'envoyer par mail c'est mieux. D'ailleur ca te permet comme ca aussi de vérifier que c'est le bon utilisateur puisque tu envoie le pass sur le mail qu'il à donné à l'origine.

----------------------
La lumière étant plus rapide que le son, un homme peu paraître brillant avant qu'il se mette a parler
-----------------

Pas faux...
(Puis j'aime bien ta "devise")

Tu peux conserver certaines données utilisateurs sans prévenir la CNIL :)
Mais il y a certaines informations où tu dois être déclaré oui.


Tout dépend ce que tu conserves (login/pass ==> s'en cogne... données personnelles seulements !)

D'accord, mais l'adresse mail constitue déjà une données peronnelle. Alors la frontière est très vite franchie !

Voui mais il parlait d'adresse mail() :)


Mais tu as raison quand même ! C'est vite franchi (et tant mieux d'ailleurs)

Par ailleurs, je ne comprends pas trop cette histoire de stocker les mot de passe en md5 pour les cacher de la vue de l'administrateur...

Moi, j'ai accés à la base de données du site développé.
Bon, je ne peux pas lire le mot de passe... Super !
Je peux le modifier, je peux lire le nom de la personne, le dernier message envoyé sur le site, son numéro de téléphone, ses goûts, ...

Je fais quoi avec ces données je peux pas les hachés... vu quelles doivent être lisible...

Et puis, je fais des base de données RELATIONNELLES. Donc l'identifiant de l'utilisateur, je le crypt avec une clef hachée en md5 ? C'est ça ? Sûr que là, heu... les requètes dans ma base seront bien optimisés.

Bref, je trouve que c'est un peu de la poudre aux yeux ce md5 sur le mot de passe. Mais, certainement parceque quelque chose m'échappe.

"Bref, je trouve que c'est un peu de la poudre aux yeux ce md5 sur le mot de passe. Mais, certainement parceque quelque chose m'échappe."

Tu peux utiliser md5 avec javascript par exemple sur un formulaire, donc tu peux pré-hasher un mot de passe avant son envoi sur le serveur.
Donc même avec un sniffer, tu ne pourras pas lire le mot de passe étant donné qu'il est pré-hashé.

Et pour vérifier ca en php ? Tester la longueur ==> si === 32, alors 'normalement', c'est un mot de passe hashé.
Reste plus qu'à le vérifier avec un preg_match [a-f0-9] et zoup !

Mais c'est vrai qu'un admin peut tout voir... c'est comme ca, c'est la vie :o

FhX => j'ai effectivement déjà vu des fonction "patch" recréant le hachage md5 coté client (en JS).

Mais là encore, je n'ai pas compris le sens de ce hachage pour la sécurité...


Comment un pirate fait-il pour capter un mot de passe ?
Il écoute une connexion, chope les données au vol les parses et en sort le mot de passe.

Bon, que tu envoye le mot de passe en clair ou en haché, c'est pareil !
Il écoute, trouve une chaine de caractère de 32 caractères Hexa qui ressemble fort à un mot de passe. Bon bah il peut réutiliser cette chaine et l'envoyer lui aussi. Comment saura-tu différencier la bonne séquence hachée de l'usurpatrice?


Peut-être que pour bien faire avec ce codes md5, il faut :
* hacher aussi le nom des variables, avec par exemple l'IP afin de retomber sur ces pattes coté serveur
* Mélanger l'ordre des données envoyées (pas toujours le mot de passe en deuxième
* et pour finir, parasiter les données en y incrustant des leures dans tous les sens (données inutiles) afin que le pirate ne puisse lire (password=4eg6f4ez6ds54gg64g86sg4f)

C'est faisable... on peut imaginer encore plus de complexité... Mais à mon avis, jamais totalement sûr.


L'intéret de SSL est que toutes les données sont cryptées ensemble. Donc le mec peut toujours écouter la connexion. Mais accroche toi pour en parser le contenu.

La meilleure solution reste de sécuriser au maximum coté serveur, filtrer les requètes SQL et les fichiers uploader, s'offrir un hébergement avec sauvegardes journalières, toujours contrôler qui fait quoi avant de le faire... et croiser les doigts.