Bonjour, je me permets bien après la bataille quelques commentaires historiques sur la tendance actuelle à vouloir absolument stocker les mots de passe hashés, vu ton obstination à le faire je me disais qu'une petite perspective historique pourrait t'aider à comprendre.
Très historiquement, les protocoles d'authentification étaient effectivement « en clair » et on envoyait les mot de passe directement au serveur, sans préoccupation de divulgation des secrets. Ce problème a été résolu au cours des années 90 avec différentes implémentations de protocoles défi-réponse (challenge-response) comme DIGEST-MD5 (cité plus haut) pour le web, CHAP pour PPP, etc. Ils ont été améliorés par l'ajout de nonce pour éviter les rejeux. Il faut se remémorer à l'époque qu'utiliser des canaux chiffrés n'était pas encore très répandu, et la cryptographie très réglementée et limitée (par les US) : ces protocoles protégeaient l'authentification lorsqu'on utilisait un canal non-chiffré, mais pas le canal de données associé. Le développement de la cryptographie a amené dans le même genre de thème l'authentification défi-réponse par clé dans SSH par exemple, ou l'authentification client par X.509 par certificat. Ces méthodes permettent, contrairement aux précédentes, de ne même pas stocker de secret côté serveur ! Car oui, bien que protégeant le canal d'authentification, les méthodes de défi-réponse citées nécessitent de stocker le mot de passe de manière récupérable sur le serveur (ce qui n'est pas forcément directement en clair, mais pas très loin il est vrai).
Puis est venu le temps de la généralisation du chiffrement des canaux avec TLS, qui a bien sûr commencé tôt sur le web, et s'est généralisé ailleurs après (sachant qu'il existait d'autres techniques aux buts similaires avant, mais qui ont eu moins de succès, ou alors dans des niches, comme IPsec, et SSH — pour son canal chiffré par DH, pas pour l'auth, ici —). Pour différentes raisons, les techniques « anciennes » d'authentification avec communication du mot de passe ou d'autre secret partagé sans souci de la confidentialité de l'échange — puisqu'ici obtenu à travers TLS — sont redevenues populaires, car souvent plus simples à implémenter une fois que le boulot de confidentialité de la couche TLS a été effectué. Certains voient ça comme un progrès, personnellement je vois plutôt ça comme une régression : maintenant, le serveur doit être mis au courant à travers le réseau du secret du client lors de la négociation de l'authentification. Le client doit avoir un moyen de garder ce secret sur le long terme et le présenter au serveur à sa demande ; il ne peut ainsi plus déléguer par exemple le défi d'authentification à un token comme une clé USB de cryptographie, ou utiliser de la cryptographie asymétrique qui lui permettrait de garder les secrets dans un endroits sécurisé et pérenne, puisqu'il n'a pas besoin de le « ressortir » et l'envoyer sur le réseau à chaque authentification. Mais aujourd'hui la cryptographie asymétrique « à l'ancienne » a perdu, les navigateurs veulent même supprimer l'authentification client par certificat X.509.
Bref, on a mis sur le dos du client le poids de devoir garder un secret qu'il doit communiquer « en clair » (mais sur un canal chiffré), pour simplifier la vie des serveurs qui se font facilement poutrer... pour quelle raison ? Est-ce la responsabilité du client si le serveur n'est pas capable de garder des secrets comme il faut ? On avait su inventer des mécanismes évitant tout stockage « chaud » de secret et de communication de secret en ligne grâce à la cryptographie asymétrique, mais aujourd'hui des considérations de practicité utilisateurs (c'est soit-disant trop dur à gérer) et de soit-disant préoccupation relatives au traçage d'identités (LOL c'est Google qui dirige les normes sur les nouveaux token qui empêchent la reconnaissance cross-site... sachant que Google le fait lui-même autrement) ont mis fin à ces mécanismes utilisés tels qu'à l'époque.
Alors aujourd'hui, on a su trouver des solutions intermédiaires différentes, qui ont certains avantages et d'autres désavantage : SCRAM-* par exemple, qui permet de faire du challenge-response d'un secret partagé sans avoir à stocker ce secret tel-quel sur le serveur. Ou les différentes formes d'authentification « fortes » par clé asymétriques comme WebAuthn, qui sont très spécifique au Web contrairement à X.509, et imposent des modèles d'identité et de confidentialité bien différents de ce qu'on avait avant (grand débat de savoir s'ils sont meilleurs ou moins bons...). Pourquoi pas, mais pour ça on a « mis à la poubelle » tout un tas de technologies qui étaient éprouvées et fiables, bien qu'ayant des désavantages (comme le stockage de secret « en clair » côté serveur) cités comme complètement rédhibitoire par certains comme toi, alors que les méthodes modernes ont d'autres désavantages qu'on cite moins. Tout ça est une histoire de compromis, et crier sur les gens quand ils stockent des secrets côté serveur comme si c'était universellement mauvais, alors que ça met un fardeau de gestion de secret supérieur sur le client, ça n'est pas très honnête ni constructif.
[^] # Re: Configuration serveur et écosystème de clients
Posté par benoar . En réponse à la dépêche Messagerie instantanée : ce n’est pas une question d’applications. Évalué à 3.
Bonjour, je me permets bien après la bataille quelques commentaires historiques sur la tendance actuelle à vouloir absolument stocker les mots de passe hashés, vu ton obstination à le faire je me disais qu'une petite perspective historique pourrait t'aider à comprendre.
Très historiquement, les protocoles d'authentification étaient effectivement « en clair » et on envoyait les mot de passe directement au serveur, sans préoccupation de divulgation des secrets. Ce problème a été résolu au cours des années 90 avec différentes implémentations de protocoles défi-réponse (challenge-response) comme DIGEST-MD5 (cité plus haut) pour le web, CHAP pour PPP, etc. Ils ont été améliorés par l'ajout de nonce pour éviter les rejeux. Il faut se remémorer à l'époque qu'utiliser des canaux chiffrés n'était pas encore très répandu, et la cryptographie très réglementée et limitée (par les US) : ces protocoles protégeaient l'authentification lorsqu'on utilisait un canal non-chiffré, mais pas le canal de données associé. Le développement de la cryptographie a amené dans le même genre de thème l'authentification défi-réponse par clé dans SSH par exemple, ou l'authentification client par X.509 par certificat. Ces méthodes permettent, contrairement aux précédentes, de ne même pas stocker de secret côté serveur ! Car oui, bien que protégeant le canal d'authentification, les méthodes de défi-réponse citées nécessitent de stocker le mot de passe de manière récupérable sur le serveur (ce qui n'est pas forcément directement en clair, mais pas très loin il est vrai).
Puis est venu le temps de la généralisation du chiffrement des canaux avec TLS, qui a bien sûr commencé tôt sur le web, et s'est généralisé ailleurs après (sachant qu'il existait d'autres techniques aux buts similaires avant, mais qui ont eu moins de succès, ou alors dans des niches, comme IPsec, et SSH — pour son canal chiffré par DH, pas pour l'auth, ici —). Pour différentes raisons, les techniques « anciennes » d'authentification avec communication du mot de passe ou d'autre secret partagé sans souci de la confidentialité de l'échange — puisqu'ici obtenu à travers TLS — sont redevenues populaires, car souvent plus simples à implémenter une fois que le boulot de confidentialité de la couche TLS a été effectué. Certains voient ça comme un progrès, personnellement je vois plutôt ça comme une régression : maintenant, le serveur doit être mis au courant à travers le réseau du secret du client lors de la négociation de l'authentification. Le client doit avoir un moyen de garder ce secret sur le long terme et le présenter au serveur à sa demande ; il ne peut ainsi plus déléguer par exemple le défi d'authentification à un token comme une clé USB de cryptographie, ou utiliser de la cryptographie asymétrique qui lui permettrait de garder les secrets dans un endroits sécurisé et pérenne, puisqu'il n'a pas besoin de le « ressortir » et l'envoyer sur le réseau à chaque authentification. Mais aujourd'hui la cryptographie asymétrique « à l'ancienne » a perdu, les navigateurs veulent même supprimer l'authentification client par certificat X.509.
Bref, on a mis sur le dos du client le poids de devoir garder un secret qu'il doit communiquer « en clair » (mais sur un canal chiffré), pour simplifier la vie des serveurs qui se font facilement poutrer... pour quelle raison ? Est-ce la responsabilité du client si le serveur n'est pas capable de garder des secrets comme il faut ? On avait su inventer des mécanismes évitant tout stockage « chaud » de secret et de communication de secret en ligne grâce à la cryptographie asymétrique, mais aujourd'hui des considérations de practicité utilisateurs (c'est soit-disant trop dur à gérer) et de soit-disant préoccupation relatives au traçage d'identités (LOL c'est Google qui dirige les normes sur les nouveaux token qui empêchent la reconnaissance cross-site... sachant que Google le fait lui-même autrement) ont mis fin à ces mécanismes utilisés tels qu'à l'époque.
Alors aujourd'hui, on a su trouver des solutions intermédiaires différentes, qui ont certains avantages et d'autres désavantage : SCRAM-* par exemple, qui permet de faire du challenge-response d'un secret partagé sans avoir à stocker ce secret tel-quel sur le serveur. Ou les différentes formes d'authentification « fortes » par clé asymétriques comme WebAuthn, qui sont très spécifique au Web contrairement à X.509, et imposent des modèles d'identité et de confidentialité bien différents de ce qu'on avait avant (grand débat de savoir s'ils sont meilleurs ou moins bons...). Pourquoi pas, mais pour ça on a « mis à la poubelle » tout un tas de technologies qui étaient éprouvées et fiables, bien qu'ayant des désavantages (comme le stockage de secret « en clair » côté serveur) cités comme complètement rédhibitoire par certains comme toi, alors que les méthodes modernes ont d'autres désavantages qu'on cite moins. Tout ça est une histoire de compromis, et crier sur les gens quand ils stockent des secrets côté serveur comme si c'était universellement mauvais, alors que ça met un fardeau de gestion de secret supérieur sur le client, ça n'est pas très honnête ni constructif.