Discussion :

[grunk]

L'envoie d'un nouveau mot de passe par mail me semble plus sécurisé car cela nécessite un accès à la boîte mail (sécurisée par un login/mdp) pour utiliser ce nouveau mot de passe.

Sinon, cela veux dire que si la personne (le hacker) qui tente de réinitialiser le mdp sur le site n'aura qu'à avoir les infos prétendues confidentielles et uniques....

En principe on ne met pas de mot de passe dans un mail puisqu'ils sont dans 99% des cas envoyés et lu en clair. Sans compter qu'ils sont généralement pas détruis.
La meilleure solution (à mon sens) est d'envoyer un lien unique et valable une seule fois par mail qui permettra d'afficher le mot de passe à l'utilisateur.

La conter partie c'est que ça ajoute une étape à l'utilisateur et que sans SSL sur le site ça n'a aucun intérêt (pas plus que le pass dans un mail en tout cas).

[RunCodePhp]

Sinon, cela veux dire que si la personne (le hacker) qui tente de réinitialiser le mdp sur le site n'aura qu'à avoir les infos prétendues confidentielles et uniques....

Je ne vois pas vraiment le rapport avec l'envoie (ou pas) du mot de passe par mail ?

Il me semble que si les informations demandée à l’utilisateur sont suffisamment confidentielles (comme : mail + nom + prénom + question secrète/réponse secrète) ça devrait suffire.
A savoir que je sous-entend que ces infos là seront vérifiées par rapport à ce qu'il y a dans la Bdd, que l'utilisateur doit (re)fournir les mêmes.

Maintenant, ça dépend de son secteur (grand risque, faible risque).

Avoir une notoriété genre FB ou un site de jeu d'argent en ligne (poker ou autre) demandera très certainement de mettre en place d'autres techniques plus sécurisés.
De l'autre, faut peut être éviter la paranoïa.


Ceci dit, c'était juste quelques exemples pour répondre à Redoran que ce n'est pas un problème que le Webmestre/Admin n'est pas connaissance des mots de passes des membres/utilisateurs, au contraire, théoriquement il vaut mieux.

[RunCodePhp]

En principe on ne met pas de mot de passe dans un mail puisqu'ils sont dans 99% des cas envoyés et lu en clair. Sans compter qu'ils sont généralement pas détruis.

Beaucoup le font.
D'ailleurs, mon hébergeur m'envoie le mot de passe Admin de la gestion de l'ensemble du site.
C'est avec ces identifications où il sera possible de tout paramétrer : La Bdd, FTP, serveur de mail, etc, etc ...
C'est dire que ce login/mot de passe est important.
Mais il bien précisé dans le mail qu'il ne faut pas le conserver, mais le détruire.


Peut on ou doit on être responsable des imprudences des utilisateurs ?
Dans certaine mesure que dis que non.


Ceci dit c'est juste une remarque.
J'adhère totalement qu'il est préférable de lui envoyer un message que le mot de passe a été modifié, (voir demander une activation en plus), et l'affaire est réglée.

[Marc3001]

Je ne vois pas vraiment le rapport avec l'envoie (ou pas) du mot de passe par mail ?

Il me semble que si les informations demandée à l’utilisateur sont suffisamment confidentielles (comme : mail + nom + prénom + question secrète/réponse secrète) ça devrait suffire.
A savoir que je sous-entend que ces infos là seront vérifiées par rapport à ce qu'il y a dans la Bdd, que l'utilisateur doit (re)fournir les mêmes.

Ben il suffit que la personne malveillante connaisse tout simplement la personne à hacker et elle sera capable de facilement trouver toutes ces infos.
Par contre pour hacker sa boîte mail, il faudra fournir un peu plus d'efforts.

[Marc3001]

En principe on ne met pas de mot de passe dans un mail puisqu'ils sont dans 99% des cas envoyés et lu en clair. Sans compter qu'ils sont généralement pas détruis.
La meilleure solution (à mon sens) est d'envoyer un lien unique et valable une seule fois par mail qui permettra d'afficher le mot de passe à l'utilisateur.

La conter partie c'est que ça ajoute une étape à l'utilisateur et que sans SSL sur le site ça n'a aucun intérêt (pas plus que le pass dans un mail en tout cas).

Oui ou dans le même genre mais peut-être plus simple c'est d'envoyer un mot de passe mais que l'appli obligera à modifier à la prochaine connexion.

[ABCIWEB]

Et le principe pour ce forum : un lien de validation est envoyé par mail en fournissant son adresse email et son login. Suite au clic sur le lien de validation un second mail est envoyé avec un nouveau mot de passe que l'on peu changer (mais ce n'est pas obligatoire) dès l'authentification.

[RunCodePhp]

La meilleure solution (à mon sens) est d'envoyer un lien unique et valable une seule fois par mail qui permettra d'afficher le mot de passe à l'utilisateur.

Je ne suis pas convaincu.

Pourquoi vouloir afficher le mot de passe ?
N'est-il pas mieux de lui demander de saisir son nouveau mot de passe tout de suite et juste lui avertir que ça été fait (avec confirmation ou pas) ?

Lui fournir un mot de passe aléatoire risque fort de ne pas plaire (trop compliqué à retenir), donc ça suppose de proposer de le modifier une fois l'opération terminée, ce qui provoque 1 étape supplémentaire.


Le principe d'activation (lien unique et temporel) après changement de mot de passe me semble plutôt pas mal.
Par contre concernant le SSL, quand on regarde les stats c'est loin d'être généralisé.
Apparemment à peine 10% des sites qui (théoriquement) demanderait de l'avoir ne l'ont pas.
Si ce chiffre est proche de la réalité, les sites Web seraient très loin d'être si sécurisés que ça.

[grunk]

Je ne suis pas convaincu.

Pourquoi vouloir afficher le mot de passe ?
N'est-il pas mieux de lui demander de saisir son nouveau mot de passe tout de suite et juste lui avertir que ça été fait (avec confirmation ou pas) ?

Oui effectivement. l'idée général étant de ne pas afficher un mot de passe dans un environnement potentiellement non sécurisé.

[ABCIWEB]

Par contre concernant le SSL, quand on regarde les stats c'est loin d'être généralisé.
Apparemment à peine 10% des sites qui (théoriquement) demanderait de l'avoir ne l'ont pas.
Si ce chiffre est proche de la réalité, les sites Web seraient très loin d'être si sécurisés que ça.

Cela dépend aussi de comment on positionne le curseur, sur quels critères on définit la nécessité d'avoir une liaison SSL. Aussi je suis assez curieux d'en savoir un peu plus sur ces stats. Tu as un lien qui détaille ça ?

[ericd69]

en effet et n'oublie pas que c'est une option payante sur la plupart des hébergements...

[bob633]

Justement je suis en train de faire cette étape de "mot de passe perdu" sur mon site et je me posais ce même genre de question.

J'étais partis sur l'idée que l'utilisateur saisissez son mail ainsi que la réponse à une question secrète. Mais c'est vrai que répondre à "Quel est le nom de vos grand parents" sont devinables très facilement par un proche ou même des algos ....

Finalement j'ai opté pour la solution du mail.

L'utilisateur saisi son mail. Je créé dans la BDD un numéro unique à cet email. Dans le mail, un lien avec cet ID unique renvoi vers une page. Sur cette page on vérifie la présence dans la BDD de ce numéro unique (être sûre que la personne n'est pas changer l'ID dans l'url ...). Une fois sur la page, le user peut saisir son nouveau mot de passe.

Beaucoup de sites utilisent cette méthode (du moins dans l'idée, je sais que je suis loin d'avoir la meilleur technique de coder).

Par contre, la technique du md5() est très simple d'utilisation en PHP, c'est celle que j'ai opté.

Quelles sont les dernières méthodes de hashage et plus "sécurisée" ? Sur chaque poste je vois des méthodes différentes, et c'est vrai que le temps me manque pour me renseigner sur toutes les méthodes ...

[grunk]

Une solution assez commune pour les mots de passe est quelque chose de ce genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
$login = 'toto'; // Récupéré du formulaire d'inscription par exemple
$pass = 'titi';
 
$pass .= hash('sha256',$login);
$pass = hash('sha256',$pass);

Ainsi ton mot de passe est salé avec un grain de sel dynamique (ici le login). L'exemple est très simple mais peut être complexifié. L'idée générale étant qu'un hacker ayant récupéré et décrypté le hash final ne puisse pas avoir le mot de passe réel.

J'utilise ici sha256 qui est actuellement considéré comme une des références depuis l'attaque du md5 et du sha1.

Pour finir , il faut être bien conscient que tous ces petites astuces n'ont que peu d'intérêt tant que tous le process d'identification ne se fait pas en ssl puisque qu'entre le client et le serveur le mot de passe va transiter en clair et donc être vulnérable au attaques du type "man in the middle".

[Marc3001]

La page sur la sécurisation des mots de passe de la doc php est intéressante à ce sujet.

[ABCIWEB]

Pour finir , il faut être bien conscient que tous ces petites astuces n'ont que peu d'intérêt tant que tous le process d'identification ne se fait pas en ssl puisque qu'entre le client et le serveur le mot de passe va transiter en clair et donc être vulnérable au attaques du type "man in the middle".

Pourquoi le mot de passe transiterait-il nécessairement en clair ? Qu'est-ce qui t'empêche de le hasher côté client avec une lib javascript avant de l'envoyer dans le post d'authentification ?

[ericd69]

Une solution assez commune pour les mots de passe est quelque chose de ce genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
$login = 'toto'; // Récupéré du formulaire d'inscription par exemple
$pass = 'titi';
 
$pass .= hash('sha256',$login);
$pass = hash('sha256',$pass);

Ainsi ton mot de passe est salé avec un grain de sel dynamique (ici le login). L'exemple est très simple mais peut être complexifié. L'idée générale étant qu'un hacker ayant récupéré et décrypté le hash final ne puisse pas avoir le mot de passe réel.

J'utilise ici sha256 qui est actuellement considéré comme une des références depuis l'attaque du md5 et du sha1.

Pour finir , il faut être bien conscient que tous ces petites astuces n'ont que peu d'intérêt tant que tous le process d'identification ne se fait pas en ssl puisque qu'entre le client et le serveur le mot de passe va transiter en clair et donc être vulnérable au attaques du type "man in the middle".

olivier... c'est du HASH pas du cryptage donc tu peux faire une collision avec le résultat mais jamais l'inverser (décrypter)... ce n'est pas une bijection

l'attaque de type "man in the middle" est en effet contrée si tu hashes coté client

[grunk]

olivier... c'est du HASH pas du cryptage donc tu peux faire une collision avec le résultat mais jamais l'inverser (décrypter)... ce n'est pas une bijection

l'attaque de type "man in the middle" est en effet contrée si tu hashes coté client

oui , quand je dit décrypter il faut effectivement comprendre un brute force ou autre joyeuseté

[Marc3001]

l'attaque de type "man in the middle" est en effet contrée si tu hashes coté client

Là j'ai des doutes, le moyen le plus simple c'est de crypter la connexion via ssl par exemple comme ça a été dit plus haut.

[ericd69]

man in the middle, c'est une attaque basée sur le fait de sniffer (intercepter les paquets à la volée) et de les analyser, en temps réel ou non, pour décrypter

or si tu as un hash tu peux rien décrypter...

par contre, il faut faire plus qu'un simple hash et saler celui-ci avec un hash venant du serveur...

par exemple:

• de base, le mot de passe est hashé en sha256 coté serveur (stocké hashé en bd) et coté client avant envoi...
• le serveur hashe un salt (sel) basé sur une chaine stockée et la date et l'heure... (comme ça il varie à chaque demande) l'envoi au client et hashe le mot de passe stocké avec et stocke le résultat en session php
• le client hashe le mot de passe avec le salt et l'envoie au serveur pour comparaison avec la valeur en session...

ce qui empêche ici l'attaque par sniffing et analyse postérieur c'est que tu introduis la variabilité de la connexion et le lien à une session...
il faut noter que tu peux quand même pirater le type si tu as son cookie de session ET le hash final sniffé entre le client et le serveur... mais là c'est que ton hackeur a d'énormes moyens... ce qui veut dire que c'est un état ou un réseau criminel hyper organisé... et là...
RIP

au passage, il faut toujours détruire les sessions au fur et à mesure ça évite l'attaque par hack du cookie de session (le réglage de base dans php est de détruire les sessions toutes les 100 qui se sont terminé (pour un soit disant gain de performance, entre nous ça me fait marrer car ça doit daté de l'époque de php 4 ou avant...)

[ABCIWEB]

Là j'ai des doutes, le moyen le plus simple c'est de crypter la connexion via ssl par exemple comme ça a été dit plus haut.

Le ssl n'est pas toujours disponible sur des mutualisés et est bien souvent payant... il faut donc savoir adapter son système de protection à ses besoins (et à son budget).

Le hash du mot de passe côté client ne demande que peu de temps à mettre en place et peut être intégré assez facilement sur tout type d'hébergement, donc pourquoi s'en priver. On peut aussi affiner la technique avec un sel changeant qui rend le post (mdp+sel) utilisable une seule fois comme mentionné par ericd69.

Avec cette protection ont aura donc une excellente protection du mot de passe (keylogger exclus mais le ssl ne règle pas non plus cette éventualité).

Ce problème réglé (dans le sens où l'on a fait le maximum) on peut ensuite passer aux autres problèmes sur la sécurité des accès aux espaces privés. Notamment celui de la protection des sessions, mais il faut bien distinguer ces différents points même si le ssl semble les régler tous d'un coup.

En envisageant la protection par couches successives que l'on additionne suivant ses besoins on maîtrise bien mieux son sujet et sa protection totale.

Par exemple, je me prends pas la tête et j'utilise ssl en croyant que cela va tout régler d'un coup et donc je n'utilise que cette technologie : oui mais reste le cas ou le certificat ssl a été piraté d'une manière ou d'une autre et tu en trouveras des exemples en fouillant dans les sujets sur ce forum ou en rentrant "ssl piraté" dans google. Alors que si j'avais suivi ma chek liste point par point, certes mon site est devenu vulnérable aux attaques sur les identifiants de session par exemple mais les mots de passe restent protégés, ce qui fait une énorme différence car un mot de passe peut servir pour différents sites (même si c'est déconseillé).

[ABCIWEB]

il faut noter que tu peux quand même pirater le type si tu as son cookie de session ET le hash final sniffé entre le client et le serveur... mais là c'est que ton hackeur a d'énormes moyens... ce qui veut dire que c'est un état ou un réseau criminel hyper organisé... et là...

Heu non pas nécessairement d'énormes moyens... cela dépend surtout de là où le pirate peut intervenir et donc de l'endroit depuis lequel tu te connecte. Si c'est un accès depuis ton lieu de travail derrière un proxy, l'admin réseau peut assez facilement pirater l'identifiant de session. Idem depuis les accès dans un lieu public.