CTLP parceque l'e-mail a pu être généré et envoyé avant que le mot de passe ne soit stocké dans la base de données :-) BEDP quand même pour l'envoyer en clair.

il est possible que le mail ai été envoyé pendent le traitement de ton inscription et que du coup, il l'ai récupéré directement depuis le formulaire et non pas dans la base de donné...

donc il peut bel et bien être chiffré (en md5 pour aller avec le reste de la sécurité) dans la base de donné

« Veuillez ne pas oublier votre mot de passe étant donné qu'il est crypté dans notre base de données, et que nous ne pourrons pas le retrouver pour vous » => Moi je comprend que si tu perds ton mdp t'es foutu, tu récupèreras plus ton compte ! Après c'est peut être moi qui comprend de travers mais bon...

Ça veut juste dire que le mot de passe ne peut pas être retrouvé ( a priori au moins hashé, j'espère aussi salé). Il peut cependant être changé en un nouveau via une procédure de récupération d'accès au compte. Grand classique du stockage de mots de passe.

Ça n'empêche qu'il a été envoyé en clair, ce qui est bien un PEBKAC.

Niveau sécurité c'est pas loin du néant total.

Tiens, ça me donne envie de poser une question.
Premièrement, je suppose comme certains commentaires ci-dessus l'ont énoncés, que le mot de passe en clair n'a fait que transiter lors du processus d'inscription pour achever sa course dans le mail envoyé au nouvel inscrit.
Ensuite, cela me démangeant tout de même légèrement et entendant derrière moi la horde des puristes disant que moins le site en connais moins il nous expose à ses probables failles de sécurité (ici exemple qui me vient à l'esprit, réaliste ou non : les logs du serveur mail utilisé pour envoyer le mail), je me demande ce qui serait le mieux pour pouvoir identifier un utilisateur sans jamais connaitre son mot de passe.
J'ai pensé, vous me direz votre avis, qu'il pourrait être intéressant de hasher le mot de passe en Javascript côté client une première fois. Un sel serait ici inutile, tout le monde pouvant le lire ; il faudrait donc pour augmenter l'entropie rehasher côté serveur le hash reçu, ici avec un sel. Lors de la connexion, on aurait évidemment la nécessité de ré-effectuer les deux hashs.
Qu'en pensez-vous? Voyez-vous d'autres désavantages que le fait de forcer l'utilisation de JS? Peut-être avez-vous déjà vu ce système implémenté?

Le site doit faire l'envoi du hash du mot de passe?

Ahem, on a dépassé mes compétences depuis longtemps là ^^'

M'enfin, pour moi la solution la plus simple c'est d'envoyer au client un lien pour qu'il entre lui-même son mot de passe et de crypter l'info dans la foulée.

Mon petit avis de néophyte, Noraa :
  Le problème avec le JS c'est qu'il faut s'assurer que la personne accepte de l'exécuter. Certains utilisateurs risquent l'avoir désactivé et, même si tu peux faire en sorte d'afficher un message d'avertissement plutôt que d'autoriser la saisie du mot de passe, il se peut que certains ne sachent pas pourquoi ni comment le JS est désactivé sur leur poste... (si-si, il suffit de lire le contenu de ce site pour en arriver à cette assertion) Ce qui peut-être gênant.
  En plus, le JS devient souvent prise de tête quand il faut gérer les différents navigateurs qui vont se connecter à ton site, et qui ne reconnaitront pas tous les mêmes fonctions, toussa toussa...

  Ensuite, j'ai envie de dire, pourquoi s'embêter avec du javascript côté client quand on peut communiquer avec lui de façon sécurisée grâce au SSL ? A moins que j'ai un train de retard, ça n'a pas encore été cassé, et à part avec un "man in the middle" profitant de l'inattention de l'utilisateur, on devrai être tranquille...
  Non ?

  Les avis de spécialistes en la matière (ou de personnes simplement mieux renseignées que moi, ça devrait se trouver facilement^^) sont les bienvenus !

La question porte sur ce que tu appelles "dans la foulée", plus précisément à si ce hash est effectué côté client ou côté serveur. Merci en tout cas de ta réponse :)

Le JS est à proscrire pour toute démarche sécuritaire et/ou d'authentification, car effectivement comme dit Youpla, on n'est pas sûr que le client l'exécute, et surtout il peut en faire ce qu'il veut. Tout hash doit se faire côté serveur.

Après il n'est pas forcément nécessaire de faire plusieurs hashs, un seul peut suffire du moment qu'il est costaud. (Sel + poivre + SHA 128 ou 256... Déjà faut se lever de bonne heure pour le casser)

(Après je suis pas expert, je raconte peut-être des conneries... Mais le hash des passwords sur PEBKAC, je peux vous dire qu'il faudra probablement un supercluster de la NASA pour passer au travers, et peut être quelques dizaines d'années :)....)

Pour la possibilité que JS soit désactivée, en effet, c'est un souci. Ceci se détectant, on pourrait soit comme tu l'énonces avertir de l'impossibilité de s'inscrire, quitte à perdre des utilisateurs, soit permettre (avec un avertissement) un mode moins sécurisé se passant du premier hash. Un problème se poserait cependant si un utilisateur s'étant inscrit de la sorte essayait de se connecter avec Javascript activé. Je pense que cela serait cependant contournable en stockant à l'inscription le mode de celle-ci.

Pour ce qui est des différences d'implémentation de JS, j'avoue n'en avoir jamais vu poser problème en dehors de l'implémentation de DOM. Tu aurais des exemples? Je crois de plus qu'au moins certains hash se réalisent de manière algorithmique simple qui serait gérable par de vieilles version du langage.

Finalement pour SSL, je suis d'accord que cela sécurise très correctement le médium de transfert. Le problème que je posais est l'existence de ces informations côté serveur, serveur qui peut être vulnérable à des attaques. Sans même tomber dans la paranoïa, je pense que les administrateurs de ces serveurs se passeraient volontiers de ces informations qui, plus qu'un moyen d'authentifier leurs clients, sont aussi un moyen de les faire fuir lorsque qu'un hacking couronné de succès les oblige à avertir ces mêmes clients qu'ils devront changer leur mot de passe, leur système ayant été pénétré.

  "Pour ce qui est des différences d'implémentation de JS, j'avoue n'en avoir jamais vu poser problème en dehors de l'implémentation de DOM. Tu aurais des exemples?"

→ J'aurai du mal à te donner des exemples à froid. J'écrivais cela car j'ai eu l'occasion de développer des interfaces un peu dynamiques pour IE (uniquement IE, pas par flemme mais par cahier des charges), et lorsque "pour voir" je comparais avec Firefox, tout ne se comportait de la même façon (sans parler des différences d'affichage). Après, je n'ai jamais eu la nécessité ni l'envie d'aller lister les différences que l'on peut trouver d'un navigateur à l'autre (je pense qu'en cherchant bien ça doit se trouver sur le net).
  J'ai vu des bouts de code dans lesquels le développeur testait le type de navigateur pour savoir ce qu'il devait utiliser comme fonction (ou quelle syntaxe utiliser peut-être) ... désolé, ça reste assez flou dans mes souvenirs^^

  "Le problème que je posais est l'existence de ces informations côté serveur, serveur qui peut être vulnérable à des attaques."

→ J'avoue que là je ne comprends pas bien : à quel moment le mot de passe "en clair" serait capturé, puisqu'il doit être crypté puis stocké dans une BDD par l'appli serveur ?

Hash, sel, poivre... manque plus que quelques herbes pour faire un tartare...^^

Merci pour les infos sur les différences d'implémentation de JS, il faudra que je me renseigne.

Dans ce pebkac l'envoi par mail montre que le mot de passe en clair est transmis lors du flux d'inscription à différents composants, dont au moins un serveur smtp. Rien n'indique que le mot de passe en clair soit stocké où que ce soit, mais on est jamais à l'abri d'un log un peu trop fougueux affichant par exemple l'ensemble d'une requête, dont possiblement notre mot de passe en clair.

Ok. Je pense que c'est simplement un problème de conception du site* : ils ont pris le parti de balancer le mot de passe dans un e-mail avant de le crypter. Ajouter un cryptage au niveau du client (avec du JS, si on reste sur cette théorie, ou n'importe quoi d'autre) ne résout pas vraiment le problème :
- Soit le cryptage du mot de passe n'a pas été conçu pour qu'il y ait décryptage au niveau du serveur, dans ce cas pas d'e-mail à envoyer avec le mdp en clair dedans
- Soit au contraire, le mdp est crypté avec une clef, connue du serveur ... qui va du coup pouvoir envoyer un e-mail avec le mdp en clair.

Je pense qu'on en revient alors à la question : faut-il oui ou non balancer son mot de passe par e-mail à un utilisateur du site ? (pour ma part je penche pour le "non")
Au final, tout repose sur la décision prise au niveau du développement du site (parce que bon, envoyer un mot de passe crypté à l'utilisateur, je n'en vois pas bien l'intérêt).

*parce que s'ils veulent, le mdp peut-être crypté dès sa réception par leur serveur, sans trace dans aucun log

Tiens, quel différence fais-tu entre sel et poivre? Une rapide recherche semble m'indiquer que le poivre est le même pour tous les hashs tandis que le sel va varier. Est-ce-bien cela? Je croyais pour ma part le sel constant, et ne connaissais pas l'existence du poivre.

J'avoue, je n'avais pas du tout pensé à cette possibilité. C'est moi le PEBKAC, je m'incline !

Pourquoi en md5 ? À choisir, prenez au moins du SHA-256, parce que md5, j'ai personnellement du mal à voir de réel lien avec la sécurité. Ça a vieilli et c'est désormais peu sûr.

Et puis c'est un hash, pas un chiffrement. C'est à sens unique. (Enfin je te l'accorde, md5, ça devient dur de le considérer à sens unique.)

Un hash simple n'est malheureusement plus suffisant, avec les calculs sur les cartes graphiques, on en teste des millions à la seconde.

Le truc qu'il faut faire c'est d'utiliser un algorithme qui prend du temps, et qui soit irréversible.C'est pour ca qu'on utilise généralement des algorythmes d'encryption et eventuellement avec plusieurs passes.

Un seul hashage ca évite que les Kevins...

Comme tu le dis, tout le monde peut lire le premier hash. Tout comme c'est le cas pour un mot de passe classique.

Donc en fin de compte, il suffirait de bombarder le serveur de hash au lieu de mots de passe classiques lors d'un brute force, et ça reviendrait au même, à quelques détails prêts.

La seule chose à sécuriser dans ce schéma, c'est l'envoie des données qu'il faut absolument chiffrer, afin que tout le monde ne puisse justement pas le voir si facilement. On se tourne donc vers SSL.

Après, on n'est pas à l'abri d'une attaque MITM particulière, ou l'intrus fait partie du cercle de confiance (entreprise ou fournisseur d'accès, par exemple) et substitue ses propre certificats SSL aux originaux, afin de pouvoir chiffrer et déchiffrer le trafic à sa guise. Mais ça, c'est une autre histoire !

Hacher le mot de passe côté client revient à utiliser un hash comme mot de passe, donc on revient au même problème.
C'est même pire, car:
1) On se retrouve avec un hash/mot de passe ayant une longueur bien définie, et voir avec un format particulier, donc une attaque par force brut devient plus facile (à moins que la longueur du hash compense).
2) On peut supposer que le site soit moins bien sécurisé que la base de donnée stockant les comptes utilisateurs. À partir de là, un pirate pourrait +/- facilement modifier le fichier contenant la fonction de hachage pour qu'elle lui envoie directement les mots de passe.

Du hash, du hash, du hash, vous n'avez que ça à la bouche.
Vous voulez ouvrir une fumerie ici ???

bon OK ----------->[]

Y'a pas que les forums, j'ai inscrit ma carte Franprix sur leur site, c'est du http et j'ai reçu le courriel de confirmation avec le mot de passe en clair. Top sécurisé.

Le site ne doit surtout pas envoyer le mot de passe, point. Le hash, le user s'en fout, donc le site n'envoie rien, ou alors c'est une passoire sécuritaire. Chaque site qui me renvoie mon mot de passe par mail me donne une grande envie de supprimer mon inscription sur le champ.

Pour un exemple de système ou le hashage se fait coté client en javascript pour que le serveur n'ai pas connaissance de ce qui est envoyé : http://sebsauvage.net/wiki/doku.php?id=php:zerobin
C'est tout a fait possible. Le but n'étant pas de garantir la sécurité du message, mais plutôt l'impossibilité pour le serveur d'être capable de le lire. Un stockage en mode banque suisse, quoi.

Je ne suis pas expert en hashs et en crypto, donc pas hésiter à taper si je raconte des bêtises... Mais j'ai lu y'a un petit moment un article dans une revue américaine sur le SHA-256, ça donnait l'impression que pour passer au travers, il fallait plus qu'un Kévin avec une grosse carte graphique.

EDIT @PaulBlanche : on a posté à peu près en même temps :) donc je n'avais pas vu ton commentaire, fort intéressant comme procédé je ne le voyais pas comme ça.

Une bonne pratique est d'envoyer le mot de passe par e-mail pendant l'inscription, sans avoir besoin de le stocker. Il est en parallèle stocké encrypté.

On récupère son compte en générant un nouveau mot de passe, via email.

Aucune PEBKAC ici...

PEBKAC pour le mot de passe en clair et l'usage du mot "crypter" (à moins que tu sois inscrit sur le forum de Canal + :D)

Je ne suis pas d'accord sur le fait d'envoyer le mot de passe par e-mail "au moment de l'inscription et juste avant de le stocker, hashé". Du coup dans l'e-mail, comme le mot de passe est apparent, si le membre se fait piquer sa boîte e-mail ou pire encore, s'il a utilisé un e-mail jetable type Yopmail et consorts, une personne non habilitée peut ainsi avoir accès au mot de passe du compte, simplement en ouvrant l'e-mail généré à l'inscription.

Pour moi je trouve la pratique meilleure quand on s'inscrit ici : on définit un mot de passe, on ne le reçoit pas par e-mail (quel intérêt ? On vient juste de créer le compte, on s'en souvient). Et quand on a oublié son mot de passe, une procédure de MdP oublié demande juste l'e-mail, ça envoie un e-mail avec un lien à suivre pour définir un nouveau mot de passe (avec une sécurité dans l'URL, genre "token" ou "key" en hash qui est vérifié, et qui a une date d'expiration (cependant je ne sais pas si c'est le cas ici)).

Ça fait un peu lèche, mais je trouve qu'ici, c'est la pratique à suivre :)

Je rejoins ce que dit Shirluban. Un hashage côté client ne servirait à rien. Pour un serveur web, le plus simple (enfin selon moi) est un hash côté serveur (avec sel, poivre et vinaigrette si vous voulez ^^) et un système de filtre/tempo sur les IP. En gros vous n'autorisez qu'une à deux tentatives par seconde et par IP, avec un bannissement de 30 minutes toutes les 5 tentatives en échec. ça calme déjà pas mal.

Pas de souci, j'ai pas de problème avec la lèche. (Mais je préfère quand c'est une fille dans le cadre privé).

@Noraa En fait je ne faisais pas de distinction entre sel et poivre au niveau de l'algorithme... Mais seulement pour faire la vanne.

Plutôt que d'utiliser deux "salts", je trouve rigolo dans le code d'avoir une variable (ou une constante) $salt et une $pepper ... Ça fait un peu sauce tartare, comme dirait Youplà.

Crypter c'est chiffrer sans connaitre la clef, ce qui rend les données indéchiffrables.
Or, pour un mot de passe, on veut justement qu'il soit chiffré de manière indéchiffrable. /o/

Donc ca ca marche très bien si vous vous faites pas pirater votre base. Si vous vous faites pirater votre base et qu'ils ont tous les hashs et que ces hashs sont trop rapide à générer, c'est pas loin d'être comme si ils étaient en clair.

Autant pour moi alors. Je me suis tellement fait pourrir en utilisant "crypter" que je pensais qu'on ne l'utilisait pas du tout.
En gros :
- crypter <=> hash
- chiffrer <=> encrypt

C'est ça?

Personnellement, j'utilise le terme "cryptage" pas toujours à bon escient...

Cryptage : Transformation d'un message en clair en un message codé compréhensible seulement par qui dispose du code. (Larousse)

Chiffrement : Opération qui consiste à transformer un message à transmettre, dit « message clair », en un autre message, inintelligible pour un tiers, dit « message chiffré », en vue d'assurer le secret de sa transmission. (Larousse)

Encrypt : convert (information or data) into a code, especially to prevent unauthorized access. (Oxford)

@vincent: C'est très simple, cryptage n'existe tout simplement pas. C'est un néologisme introduit dans les années 80 par Canal + (Merci les marketeux !). D'ailleurs on a bien toujours parlé de "service du chiffre" dans l'armée...

Chiffrer: Rendre une information inintelligible à l'aide d'une clé que seule toi et ton destinataire connaissent.
Déchiffrer: Rendre une information intelligible grâce à une clé que seule toi et ton destinataire connaissent.
Décrypter: Réussir à rendre une information intelligible, malgré le fait que tu ne possèdes pas la clé.

Crypter: Réussir à rendre une information inintelligible, mais ni toi, ni ton destinataire n'en possède la clé. ?!?

Attention, le hachage n'est pas un chiffrement, et encore moins un "cryptage". C'est une opération non bijective. Que tu connaisses la "clé" (le sel ou toute information complémentaire) ou non, tu ne pourras pas "déhacher". Crypter != hacher (si on considère que "crypter" existe, ce qui à mon sens est une abération)

>> bannissement de 30 minutes toutes les 5 tentatives en échec. ça calme déjà pas mal.
Aïe, c'est tellement une mauvaise solution :(
Ça part d'un bon sentiment, mais cette technique n'est pas terrible pour un utilisateur lambda. Si un utilisateur légitime rate son mot de passe (il n'a pas vu qu'il était en caps lock, et s'acharne un peu, par exemple), tu le banniras. Ce n'est pas très professionnel, et il ne le mérite pas.

Il existe une technique bien plus adaptée. Elle consiste à augmenter très très légèrement le temps de réponse à chaque essai (de quelques ms à chaque fois). Un utilisateur ne sentira vraiment pas la différence, mais un outil de brute force, se retrouvera à ralentir de plus en plus, au point qu'il devienne inutilisable.

Je ne connaissais pas cette technique. Intéressant ^^

J'avoue que le coup du bannissement est un peu méchant pour un utilisateur lambda mais assez facile à mettre en place et assez formateur pour ces utilisateurs lambda (on ne fait pas la même erreur deux fois). Après tout dépend du site et tout et tout.

Le problème des attaques d'aujourd'hui est qu'elles se font depuis plusieurs IP (botnets) et sur plusieurs comptes en même temps ! Du coup, le throttling (traduction : étranglement) par membre et par IP est inutile. Plusieurs articles s'accordent à dire qu'il faut faire une moyenne globale en permanence du nombre d'authentifications foirées sur l'ensemble du système et appliquer le filtre aussi sur cette base.
Un gars a résumé tout ça très bien sur StackOverflow : http://stackoverflow.com/a/477578

Ah en effet, je présupposais la réponse non : je parle en effet de hash et non de cryptage.

1) La longueur du hash compense normalement. De plus, si le hash d'un utilisateur est retrouvé, cela ne permet pas aisément de s'authentifier sur le site de sa banque où il a le même mot de passe.
2) Si l'attaquant peut modifier le site, une fonction de hashage ne changera pas grand chose. Elle peut légèrement empirer le cas en effet si l'utilisateur a spécifiquement activé JS pour cette fonction.

Pour ma part j'ai tendance à régulièrement utiliser le mot "cryptage" quand je devrai dire "hash", ce qui ne rends pas forcément mes précédents commentaires très clairs maintenant que j'y pense... (gome nasaï)

Genre dans ma phrase :
"- Soit le cryptage du mot de passe n'a pas été conçu pour qu'il y ait décryptage au niveau du serveur, dans ce cas pas d'e-mail à envoyer avec le mdp en clair dedans"

Le mot qui convient en fait est hashage et non cryptage (puisqu'on ne cherche par à récupérer le mdp en clair côté serveur).

En position 7 monsieur esclave je vous prie...

C'est très bateau comme question, tout bon développeur sait ça :-P
Tu mérites la Flagellation au clavier + Le tube avec le hamster. (Comment ça, c'est gore ?!)

Au passage, un mot de passe est (doit être) hashé et non crypté :D (relancement de débat ?)