Il est tout à fait possible d'envoyer le mail de confirmation puis de stocker le mot de passe proprement chiffré dans la BDD.
Vu que le reste a l'air sérieux, ça m'étonnerait pas que ça soit comme ça que ça se passe, et j'y vois aucun PEBKAC.

Un mot de passe envoyé en clair, ça te pose pas de problème ? J'espère que t'es pas DSI...

@neeko. Non ca me pose pas de problème de mon coté.

On peut très bien lors de l'enregistrement du compte garder le mot de passe en clair pour le passer à la vue du mail et pour l'insertion en BDD le hasher/crypter/etc.

Ce qui est inquiétant c'est quand on redemande son mot de passe et quand on ne vous propose pas de cliquer sur un lien pour le changer mais que celui ci est visible en clair.

Après le fait de mettre le mot de passe en clair lors de l'envoie du mail ce n'est pas le mieux ça c'est sur. Faut pas que son mail soit intercepté par une tierce personne mal intentionné.

L'éternel débat sur les mots de passe en clair dans les mail, le plus gros marronnier de pebkac et chiant comme la mort... Alors qu'il n'y a aucun consensus en ce domaine parmi les experts en sécurité informatique.... Bleh

Mais un gros ctlp là parce que supposer qu'un mdp en clair dans un mail signifie que celui ci et tous les autres champs de la base sont en clair (et supposer que les infos de paiement sont gardées en base) c'est totalement débile.

CTLP de penser que pour envoyer le mail de confirmation, il faut impérativement le relire de la BDD, alors qu'il peut très bien être mis en mémoire avant son md5 ou autre méthode de codage.

Certes c'est possible. Mais le fait que le mot de passe voyage en clair par un moyen de communication non chiffré est une faille de sécurité.

Si un mot de passe m'est envoyé en clair au moment de la création du compte, je pars du principe qu'il m'est envoyé par sécurité pour ne pas que je le perde ou ressente le besoin de le noter sur un post-it collé sur mon écran. Ainsi, les risques de perte de mdp sont réduits (ainsi que ceux de renouvellement de celui-ci via formulaire dont le lien sera envoyé sur demande à mon adresse mail.)
Après quoi, la logique veut que côté serveur il soit passé à l'algo de chiffrage préféré de la NSA, puis que le résultat soit stocké en BDD alors que l'original est effacé.
Donc non, ça me pose aucun problème. Sauf si mon mot de passe m'est envoyé en clair en cliquant sur "j'ai oublié mon mdp", ce qui implique un procédé bien différent.

Quand au fait qu'il soit en clair dans ma boite mail, vu que le formulaire de perte de mdp est de toutes façons un lien envoyé par mail, quelqu'un à qui j'aurais laissé la possibilité de se connecter à ma boite aurait de toutes façons celle non pas de connaître mon mdp, mais pire encore de le remplacer par celui de son choix.

Tout dépend du site.
Si le site est accessible en HTTP (et non HTTPS), le mot de passe transite de toute façon en clair.
Et il me semble plus probable qu'il soit intercepté (avec un but malveillant) entre l'utilisateur et le site qu'entre le site et le serveur de la boite mail.
Après pour la boite mail on rajoute un tiers qui a accès à l'info ce qui n'est pas bien forcément. D'un autre côté à partir d'un accès à la boîte mail on peut généralement voir à quoi est abonné un utilisateur et réinitialiser son compte (ce qui n'est quand même pas la même chose que connaître un mot de passe potentiellement utilisé ailleurs).
Cela dit l'utilisateur à quand la possibilité de supprimer le mail avec son mot de passe pour éviter une attaque postérieure, donc ça devient en parti son choix.
Après là il s'agit d'un site lié à un achat. Même si pour les informations de paiement, souvent on passe par un site tiers qui lui est correctement sécurisé, avoir accès au compte lié de manière non sécurisé n'est vraiment pas terrible.
Mais bon on voit facilement largement pire avec des petits sites.

@Macaque : Pour ton premier point, y'a rien qui empêche d'utiliser un algo de chiffrage en JavaScript sur le PC client et ensuite de rapatrier le résultat côté serveur pour le stocker en BDD. Là, pas de transit en clair, sécurité au top.

Non javascript seul n'est pas suffisant, il y a plusieurs problèmes.
Déjà sans authentifcation du serveur (rôle des certificats avec des autoritées reconnues par les navigateurs) tu ne peux pas garantir une attaque "de l'homme du milieu".
Et puis même sans parler MITM c'est un peu plus compliqué que ça.
Si tu fait un simple hash du mot de passe côté client, d'un point de vu du serveur, le mot de passe du client est ce hash.
Donc une personne qui a écouté la conversation et connaît se hash pourra facilement se logguer au compte sans avoir à connaître le vrai mot de passe de l'utilisateur.
Donc même pour le login simple, il faudrait en plus un challenge, genre le serveur envoie une chaine aléatoire avec le contenu de la page (qui change à chaque fois), et la réponse du client doit dépendre de celui.
Après il faut aussi prendre en compte le fait qu'il ne faut pas non plus stocker le hash généré par le navigateur directement en BD sinon une personne qui récupérerait les hash en BD serait capable de se logguer sur tous les comptes. Il faut donc conserver un hashage supplémentaire côté serveur.
Et enfin tu as la problèmatique de l'inscription qui doit être encore pire. En effet tu n'as aucun secret partagé entre les deux au départ et tu dois trouver le moyen de stocker une information issue du password de l'utilisateur en BD à la fin.
Donc en gros tu va devoir mettre toute une couche de chiffrement asymétrique et réinventer la roue (avec les risques de grosses failles de sécu qui vont avec) en ayant toujours le problème de ne pas avoir d'authentification du serveur et donc de pouvoir être victime d'une MITM.
Sans parler des problèmes de compatibilité des navigateurs.
Bref dans ces cas là on ne s'amuse pas à ça, on fait de l'https au moins pour l'inscription et le login (quitte à ce que le reste de la navigation sur le site ne soit pas chiffré pour des problèmes de performances).

J'avoue, j'ai du relire 2 fois pour tout comprendre, merci pour ce petit topo.
Juste une tite question sans vouloir abuser : la partie "hashage supplémentaire côté serveur", si je suis pas trop PEBKAC, c'est ce qu'on nomme "salage", non ?

Non pas vraiment.
Le "salage" c'est le fait de rajouter un "grain de sable" (ou sel) à la donnée fournie par l'utilisateur pour qu'on ne puisse pas retrouver les mots de passe utilisateur à partir d'un dump BD et une table "arc en ciel".
En gros une table "arc en ciel" (rainbow) c'est une table dans laquelle on stocke pleins de correspondance "password <=> hash(password)" à partir de tous les mots de passe faible (combinaison de mots du dictionnaires et chiffres).
Donc si ton site stocke simplement "hash(mdp)" dans la BD de ton site l'attaquant peut utiliser cette table "arc en ciel" pour retrouver presque instantamment un mot de passe les mots de passe faibles des utilisateurs (mais les mots de passe "fort" qui ne sont pas dans la table "arc en ciel" ne seront pas "déchiffrés").
Par contre si tu stocke :
hash( "azpeoazepoqsdf" + mdp), l'attaquant ne pourra pas utiliser une table générique qui contient des correspondances de hash pour trouver les mots de passe faible qui sont dans la BD.
Même si l'utilisateur à utiliser le mot de passe "password", l'attaquant devra recalculer hash("azpeoazepoqsdf" + "password") pour voir s'en rendre compte.
Le mieux étant pour le "grain de sable" (ou le "sel") d'être unique par utilisateur, ainsi l'attaquant est obligé de faire une attaque brut force pour chaque mot de passe utilisateur.

Pour moi BEPD pour 2 raisons :
+ Faire chier ceux qui ne sont pas d'accord avec moi
+ Tu t'inscris sur un site, tu rentres 2 fois de suite ton mot de passe, donc tu ne te trompes probablement pas, tu n'as donc pas besoin qu'on te le confirme. Pour si peu probable que soit un MITM entre ton correspondant et ta boite mail, la paranoïa est toujours un point positif du point de vue de la sécurité.

Mouarf... quand j'écris "tite question", c'est une manière de dire "te casses pas la tête à pondre un roman".
Merci bien pour ces réponses très enrichissantes qui à elles seules méritent que je me mette ce PEBKAC en favori pour le cas ou un jour je doive gérer une question de ce type :)

Le transit en clair est une chose, je dirai rien de mieux qu'au dessus.
Maintenant pour la partie paiement, elle passe souvent par un prestataire (ogone par ex), et quasi tout le temps par HTTPS, du coup lier les deux en terme de confiance me parait pas vraiment pertinent.
Si tu nous avais dit que le paiement se passait sur une page non certifiée en HTTPS, là j'aurais compris, mais ça me semble quand même bien décorrelé !
Au pire, mot de passe bidon si t'as un doute sur la sécurité du site. Mais tant que tu lui fournis pas d'infos sensibles...

Non, je ne suppose pas que le mot de passe est stocké en clair dans la base de donnée, quand bien même je le reçois en clair dans le mail.
Le problème d'un mail avec le mot de passe en clair, c'est qu'il peut être intercepté. Alors certes c'est paranoïaque, mais j'avais l'intention de payer sur le site. Si quelqu'un récupère le mot de passe, rien ne me garantit qu'il ne pouvait pas retrouver les infos de paiement et les réutiliser. Parce que des sites qui stockent ton numéro de carte bleue pour que tu n'aies pas à le rentrer à chaque fois, ça existe.

Ensuite, un autre point que tout le monde semble avoir oublié dans les commentaires, c'est que le mot de passe ne devait contenir que des chiffres et des lettres minuscules. Niveau sécurité c'est pas top, j'aime bien personnellement utiliser plein de caractères bizarres. Et comme c'est écrit en gros sur le formulaire d'inscription, ça simplifie beaucoup une attaque brute force.

Bref, pour moi ce site a des lacunes sur la sécurité, surtout pour un site de paiement en ligne.

La problématique n'est pas entièrement posée, vous avez omis l'avis de l'utilisateur et du client. Parfois il est simplement demandé que l'utilisateur ne rentre pas son mdp et c'est ce que je préfère, dans certains cas, ca lui évite de se prendre la tête avec ça.
Le mot de passe en clair dans un mail n'est pas important car il touche un seul utilisateur et ca reste rare et difficile à mettre en place.
Pour la sécurité d'un paiement en ligne, le https me semble obligatoire et c'est tout autre chose.
Pour la restriction de mdp, c'est con mais un petit pebkac.

Le problème avec les sites commerciaux n'est pas forcément le stockage des informations mais ce qui en est fait ensuite. J'avais lu un article écrit par une association de consommateurs qui parlait d'une chaînes d'hôtels (dont le siège est en Belgique si ma mémoire est bonne) pas triste à ce niveau. Pour s'inscrire sur leur site, naviguer et payer aucun soucis tout était sécurisé, vous me direz c'est bien. Le problème c'est après qu'on ait réservé ses nuits...
Il faut se présenter le premier jour de la réservation à la réception de l'hôtel choisi avec la carte bancaire qui a sevi à réserver (comme sur bien d'autres sites). L'association de consommateurs avait choisi un hôtel en Espagne et la chaîne n'a rien trouvé de mieux que de transmettre les données bancaires par fax à l'hôtel en question...
Inutile de vous dire que le fax contenait bien sûr toutes les informations nécessaires pour débiter le compte, puisque si on ne se présente pas à la réception de l'hôtel le premier jour ils ponctionnent quand même une partie du séjour en guise frais d'annulation.