As part of our Application Security offering, we offer a free feature that checks if a password has been leaked in a known data breach of another service or application on the Internet. When we perform these checks, Cloudflare does not access or store plaintext end user passwords. We have built a privacy-preserving credential checking service that helps protect our users from compromised credentials. Passwords are hashed – i.e., converted into a random string of characters using a cryptographic algorithm – for the purpose of comparing them against a database of leaked credentials.
Posté par nud .
Évalué à 10 (+11/-0).
Dernière modification le 18 mars 2025 à 22:26.
Cloudflare c'est un reverse-proxy géant. Quand on parle de hasher les mots de passe, on parle du stockage de ceux-ci dans la base de données. Sauf exception le mot de passe n'est pas chiffré entre le navigateur et le serveur, que ce soit avec HTTP Basic ou un formulaire, et donc il transite "en clair" dans la session TLS entre le client et le serveur.
Donc dans la mesure où la session TLS est terminée au niveau de Cloudflare, les informations d'identification (username et mots de passe) transitent techniquement en clair à un moment ou à un autre dans l'infrastructure de Cloudflare, et il est techniquement possible de les intercepter pour, je sais pas, faire des statistiques sur la réutilisation de mots de passes sur plusieurs sites. Ce n'est pas une surprise, c'est nécessaire pour que Cloudflare puisse fournir le service pour lequel leurs clients les paient !
Après, du coup, il est effectivement théoriquement possible pour eux d'intercepter les mots de passe et d'en faire ce qu'ils veulent, y compris les transmettre à la NSA ¯\_(ツ)_/¯
Donc en gros on est en train de dire que CloudFlare voit passer x% du transit Internet en clair quoi. HTTPS ta mère.
C'est évident maintenant qu'on en parle (je m'étais jamais posé la question), mais je vais me mettre à boycotter autant que possible (c'est jamais si facile) les sites l'utilisent.
Tu peux pas dire aux gens "mettez HTTPS partout" et ensuite mettre en place un proxy géant qui déchiffre tout, le traite, et re-chiffre tout.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
C'est évident maintenant qu'on en parle (je m'étais jamais posé la question), mais je vais me mettre à boycotter autant que possible (c'est jamais si facile) les sites l'utilisent.
Tu as la même chose avec un site déployé sur un cloud provider et dont la terminaison TLS est managé par le cloud provider. En soit tu peut discuter de si ce sont des sites sûre ou non, mais je trouve plus simple d’avoir une bonne politique de mot de passe et donc de cloisonner autant que possible les problèmes.
Avoir une bonne politique de mot de passe permet non seulement de mitiger les problèmes de sites qui font des choix discutables, mais aussi ceux codé avec les pieds (genre stockage de mot de passe en clair) et ceux qui se font voler leur base de mot de passe.
À noter que l’usage d’un second facteur endigue le problème.
Bref si tu suis les recommandations classiques sur les mot de passe tu n’a pas vraiment de problème.
Avoir une bonne politique de mot de passe permet non seulement de mitiger les problèmes de sites qui font des choix discutables, mais aussi ceux codé avec les pieds (genre stockage de mot de passe en clair) et ceux qui se font voler leur base de mot de passe.
Je suis pas sûr de comprendre? Mon mot de passe fait 97 caractères avec des majs, des mins, des chiffres et des symboles, mais la base de mot de passe stockée en clair a fuitée. Le pirate a donc accès à mon mot de passe. Je vois pas comment ma politique a mitigé (?) le problème?
À noter que l’usage d’un second facteur endigue le problème.
A se demander à quoi sert le mot de passe du coup.
La politique de mot de passe qui endigue le problème, ce n'est pas le choix des symboles que tu met dedans mais celle consistant à ne pas réutiliser le même mot de passe pour plusieurs sites.
À noter que l’usage d’un second facteur endigue le problème.
A se demander à quoi sert le mot de passe du coup.
À fournir le premier facteur ;)
Ceci dit, je suis assez d'accord avec toi : pourquoi utiliser un mot de passe + un algo crypto moyen plutôt qu'un bon protocole d'authentification…
Je suis pas sûr de comprendre? Mon mot de passe fait 97 caractères avec des majs, des mins, des chiffres et des symboles, mais la base de mot de passe stockée en clair a fuitée. Le pirate a donc accès à mon mot de passe. Je vois pas comment ma politique a mitigé (?) le problème?
Tu ne peut rien faire contre le fais que ton mot de passe d’un site parte dans la nature. Que ce soit volontaire de leur part, une malfaçon ou qu’ils subissent impossible à endiguer. Par contre tu peut faire en sorte que la fuite d’un moi de passe n’aille pas plus loin que de poser problème sur le site en question. Tu as mon mot de passe linuxfr ? Tu ne pourra pas le réutiliser ailleurs.
A se demander à quoi sert le mot de passe du coup.
Le second facteur peut aussi être compromis, mais on imagine peut probable qu’un attaquant arrive à casser les 2 simultanément.
Je comprend pas, à quel moment le mot de passe est hashé? Comment ils font pour hasher un mot de passe sans y avoir accès?
Les mots de passe des sites webs sont (devraient) hashés et salés avant d'être stockés sur les serveurs. Mais lorsqu'on entre son mot de passe au login, le mot de passe est envoyé tel quel au serveur qui le hashe (à travers une connexion chiffrée). À ce moment là le serveur peut voir le mot de passe en clair, et un intermédiaire technique peut aussi y accéder. D'ailleurs il y a déjà eu des fuites parce que ces mots de passe apparaissaient dans des logs (chez Facebook de mémoire).
Donc pour moi, dire que Cloudflare accède aux mots de passes ça ressemble à une lapalissade, je veux bien qu'on m'explique si je me trompe.
à partir du moment où il y a du javascript (provenant d'un tiers, comme Cloudflare par exemple), alors tu ne peux pas garantir une quelconque sécurité et confidentialité. Puisque tu n'as pas de contrôle sur le code javascript, et, qu'il peut lire le formulaire, le clavier, la sourie, etc. et tout envoyer ailleurs.
Sinon, une pratique qui se faisait avant qu'il n'y ait Let's Encrypt partout, c'était de hasher le mot de passe avec un sel etc. avant de l'envoyer le formulaire sur le serveur.
Le serveur n'ayant pas besoin de connaître le mot de passe en clair, il suffisait juste de comparer le hash en base de donnée avec celui reçu.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
Euh, non. Si tu compares directement le hash envoyé par le client au hash stocké par le serveur, c'est le hash qui est le mot de passe effectif et tu es de retour au point de départ.
Ce qui se faisait, c'était une authentification par digest, dans laquelle (en très simplifié) le serveur envoie une nonce avec laquelle le client est censé chiffrer le mot de passe avant de l'envoyer au serveur. Le serveur fait de même et compare le résultat avec celui envoyé par le client. Si c'est le même c'est que le client connaît le mot de passe. C'est un peu tombé en désuétude, cependant, probablement à cause des formulaires de login, mais de toute façon ça a l'inconvénient d'empêcher le stockage sécurisé des mots de passe au niveau du serveur.
Once enabled, leaked credentials detection will scan incoming HTTP requests for known authentication patterns from common web apps and any custom detection locations you configure.
If Cloudflare detects authentication credentials in the request, those credentials are checked against a list of known leaked credentials.
(…)
Cloudflare does not store, log, or retain plaintext end-user passwords when performing leaked credential checks. Passwords are hashed, converted into a cryptographic representation, and then compared against a database of leaked credentials.
Oui le SI de CloudFlare voit passer tes mots de passes mais non les gens de CloudFlare ne sont pas censés y accéder.
Est-ce à dire que le gouvernement américain pourrait exiger d'avoir connaissance des mots de passe sans que CloudFlare ne puisse le dire publiquement ? Ça parait assez incroyable si c'est vrai.
C'est arrivé à l'entreprise Lavabit plusieurs fois. Le patron a fini par fermer l'entreprise car il trouvait cette pratique contraire à l'esprit du service qui était rendu.
Moi, si j'étais Cloudflare et que le gouvernement me demandait ça, je ferais un article de blog disant HÉ VOUS AVEZ VU? ON A ACCÈS À VOS MOT DE PASSES IL FAUDRAIT PAS QUE ÇA TOMBE ENTRE DE MAUVAISES MAINS. À défaut de pouvoir être plus explicite…
Je pense que tous les employés de Cloudflare ne sont pas des milliardaires de la tech, et j'espère que la mise en place du nouveau régime technofasciste américain ne va pas se faire sans un minimum de résistance.
Quelle autre raison pourraient-ils avoir pour faire un message de blog dont le but principal est de dire "coucou, on voit vos mots de passe"? Le risque de "bad buzz" me semble assez évident avec un tel message, non?
En réutilisant des données, le sous-traitant du responsable du traitement initial devient responsable du traitement ultérieur : il devient donc responsable de la conformité de son traitement à l’ensemble des exigences du RGPD. À défaut, il peut être sanctionné par la CNIL en tant que responsable de ce traitement.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
J'avoue que je ne vois pas où es le point également. C'est justement leur métier de terminer la sécurisation, donc par définition après eux, c'est en clair.
(Juste par curiosité, pour quelle raison certains ont moinsé mon commentaire sous le lien alors que je ne faisais que poser une question (une vraie, en ce qui me concerne) ?
# FUD ?
Posté par mahikeulbody . Évalué à 7 (+8/-3). Dernière modification le 18 mars 2025 à 19:44.
https://blog.cloudflare.com/password-reuse-rampant-half-user-logins-compromised/
As part of our Application Security offering, we offer a free feature that checks if a password has been leaked in a known data breach of another service or application on the Internet. When we perform these checks, Cloudflare does not access or store plaintext end user passwords. We have built a privacy-preserving credential checking service that helps protect our users from compromised credentials. Passwords are hashed – i.e., converted into a random string of characters using a cryptographic algorithm – for the purpose of comparing them against a database of leaked credentials.
Vous en pensez quoi ?
[^] # Re: FUD ?
Posté par fearan . Évalué à 1 (+6/-8).
que sebsauvage est un adepte du putaclic avec des compétences limité en ce qui concerne la sécurité.
J'ajouterai qu'un grand nombre de site oublient de saler les mots de passes, c'est pourtant pas compliqué : hash(id_compte+sel_du_site+mdp)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: FUD ?
Posté par Renault (site web personnel) . Évalué à 6 (+3/-0).
Autant faire un sel par compte directement, ce qui est recommandé par ailleurs. Plus besoin de l'id du compte.
[^] # Re: FUD ?
Posté par fearan . Évalué à 3 (+0/-0).
si le sel est l'id du compte, c'est un sel par compte :P
je rajoute le site pour éviter qu'un couple id/mdp se retrouve dans les rainbow table, mais si l'id de compte est un uuid, cela devient facultatif.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: FUD ?
Posté par nud . Évalué à 10 (+11/-0). Dernière modification le 18 mars 2025 à 22:26.
Cloudflare c'est un reverse-proxy géant. Quand on parle de hasher les mots de passe, on parle du stockage de ceux-ci dans la base de données. Sauf exception le mot de passe n'est pas chiffré entre le navigateur et le serveur, que ce soit avec HTTP Basic ou un formulaire, et donc il transite "en clair" dans la session TLS entre le client et le serveur.
Donc dans la mesure où la session TLS est terminée au niveau de Cloudflare, les informations d'identification (username et mots de passe) transitent techniquement en clair à un moment ou à un autre dans l'infrastructure de Cloudflare, et il est techniquement possible de les intercepter pour, je sais pas, faire des statistiques sur la réutilisation de mots de passes sur plusieurs sites. Ce n'est pas une surprise, c'est nécessaire pour que Cloudflare puisse fournir le service pour lequel leurs clients les paient !
Après, du coup, il est effectivement théoriquement possible pour eux d'intercepter les mots de passe et d'en faire ce qu'ils veulent, y compris les transmettre à la NSA ¯\_(ツ)_/¯
[^] # Re: FUD ?
Posté par fearan . Évalué à 3 (+0/-0). Dernière modification le 18 mars 2025 à 23:16.
oups mauvais fil
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: FUD ?
Posté par gUI (Mastodon) . Évalué à 5 (+2/-0).
Donc en gros on est en train de dire que CloudFlare voit passer x% du transit Internet en clair quoi. HTTPS ta mère.
C'est évident maintenant qu'on en parle (je m'étais jamais posé la question), mais je vais me mettre à boycotter autant que possible (c'est jamais si facile) les sites l'utilisent.
Tu peux pas dire aux gens "mettez HTTPS partout" et ensuite mettre en place un proxy géant qui déchiffre tout, le traite, et re-chiffre tout.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: FUD ?
Posté par barmic 🦦 . Évalué à 5 (+3/-0).
Tu as la même chose avec un site déployé sur un cloud provider et dont la terminaison TLS est managé par le cloud provider. En soit tu peut discuter de si ce sont des sites sûre ou non, mais je trouve plus simple d’avoir une bonne politique de mot de passe et donc de cloisonner autant que possible les problèmes.
Avoir une bonne politique de mot de passe permet non seulement de mitiger les problèmes de sites qui font des choix discutables, mais aussi ceux codé avec les pieds (genre stockage de mot de passe en clair) et ceux qui se font voler leur base de mot de passe.
À noter que l’usage d’un second facteur endigue le problème.
Bref si tu suis les recommandations classiques sur les mot de passe tu n’a pas vraiment de problème.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: FUD ?
Posté par octane . Évalué à 2 (+0/-0).
Je suis pas sûr de comprendre? Mon mot de passe fait 97 caractères avec des majs, des mins, des chiffres et des symboles, mais la base de mot de passe stockée en clair a fuitée. Le pirate a donc accès à mon mot de passe. Je vois pas comment ma politique a mitigé (?) le problème?
A se demander à quoi sert le mot de passe du coup.
[^] # Re: FUD ?
Posté par aiolos . Évalué à 3 (+1/-0).
La politique de mot de passe qui endigue le problème, ce n'est pas le choix des symboles que tu met dedans mais celle consistant à ne pas réutiliser le même mot de passe pour plusieurs sites.
À fournir le premier facteur ;)
Ceci dit, je suis assez d'accord avec toi : pourquoi utiliser un mot de passe + un algo crypto moyen plutôt qu'un bon protocole d'authentification…
[^] # Re: FUD ?
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
Tu ne peut rien faire contre le fais que ton mot de passe d’un site parte dans la nature. Que ce soit volontaire de leur part, une malfaçon ou qu’ils subissent impossible à endiguer. Par contre tu peut faire en sorte que la fuite d’un moi de passe n’aille pas plus loin que de poser problème sur le site en question. Tu as mon mot de passe linuxfr ? Tu ne pourra pas le réutiliser ailleurs.
Le second facteur peut aussi être compromis, mais on imagine peut probable qu’un attaquant arrive à casser les 2 simultanément.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: FUD ?
Posté par ted (site web personnel) . Évalué à 6 (+4/-0).
Je comprend pas, à quel moment le mot de passe est hashé? Comment ils font pour hasher un mot de passe sans y avoir accès?
Les mots de passe des sites webs sont (devraient) hashés et salés avant d'être stockés sur les serveurs. Mais lorsqu'on entre son mot de passe au login, le mot de passe est envoyé tel quel au serveur qui le hashe (à travers une connexion chiffrée). À ce moment là le serveur peut voir le mot de passe en clair, et un intermédiaire technique peut aussi y accéder. D'ailleurs il y a déjà eu des fuites parce que ces mots de passe apparaissaient dans des logs (chez Facebook de mémoire).
Donc pour moi, dire que Cloudflare accède aux mots de passes ça ressemble à une lapalissade, je veux bien qu'on m'explique si je me trompe.
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: FUD ?
Posté par GG (site web personnel) . Évalué à 3 (+3/-2).
à partir du moment où il y a du javascript (provenant d'un tiers, comme Cloudflare par exemple), alors tu ne peux pas garantir une quelconque sécurité et confidentialité. Puisque tu n'as pas de contrôle sur le code javascript, et, qu'il peut lire le formulaire, le clavier, la sourie, etc. et tout envoyer ailleurs.
Sinon, une pratique qui se faisait avant qu'il n'y ait Let's Encrypt partout, c'était de hasher le mot de passe avec un sel etc. avant de l'envoyer le formulaire sur le serveur.
Le serveur n'ayant pas besoin de connaître le mot de passe en clair, il suffisait juste de comparer le hash en base de donnée avec celui reçu.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: FUD ?
Posté par nud . Évalué à 10 (+8/-0).
Euh, non. Si tu compares directement le hash envoyé par le client au hash stocké par le serveur, c'est le hash qui est le mot de passe effectif et tu es de retour au point de départ.
Ce qui se faisait, c'était une authentification par digest, dans laquelle (en très simplifié) le serveur envoie une nonce avec laquelle le client est censé chiffrer le mot de passe avant de l'envoyer au serveur. Le serveur fait de même et compare le résultat avec celui envoyé par le client. Si c'est le même c'est que le client connaît le mot de passe. C'est un peu tombé en désuétude, cependant, probablement à cause des formulaires de login, mais de toute façon ça a l'inconvénient d'empêcher le stockage sécurisé des mots de passe au niveau du serveur.
[^] # Re: FUD ?
Posté par octane . Évalué à 8 (+6/-0).
c'était cloudflare: https://fr.wikipedia.org/wiki/Cloudbleed
[^] # Re: FUD ?
Posté par jtremesay (site web personnel) . Évalué à 8 (+6/-0).
https://developers.cloudflare.com/waf/detections/leaked-credentials/ :
Oui le SI de CloudFlare voit passer tes mots de passes mais non les gens de CloudFlare ne sont pas censés y accéder.
[^] # Re: FUD ?
Posté par mahikeulbody . Évalué à 7 (+5/-0).
Est-ce à dire que le gouvernement américain pourrait exiger d'avoir connaissance des mots de passe sans que CloudFlare ne puisse le dire publiquement ? Ça parait assez incroyable si c'est vrai.
[^] # Re: FUD ?
Posté par cg . Évalué à 7 (+5/-0).
C'est arrivé à l'entreprise Lavabit plusieurs fois. Le patron a fini par fermer l'entreprise car il trouvait cette pratique contraire à l'esprit du service qui était rendu.
[^] # Re: FUD ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 6 (+5/-1).
Moi, si j'étais Cloudflare et que le gouvernement me demandait ça, je ferais un article de blog disant HÉ VOUS AVEZ VU? ON A ACCÈS À VOS MOT DE PASSES IL FAUDRAIT PAS QUE ÇA TOMBE ENTRE DE MAUVAISES MAINS. À défaut de pouvoir être plus explicite…
[^] # Re: FUD ?
Posté par Voltairine . Évalué à 7 (+5/-0).
C'est certain que des milliardaires de le tech américains vont tout faire pour ne pas coopérer avec le gouvernement fédéral.
[^] # Re: FUD ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Je pense que tous les employés de Cloudflare ne sont pas des milliardaires de la tech, et j'espère que la mise en place du nouveau régime technofasciste américain ne va pas se faire sans un minimum de résistance.
Quelle autre raison pourraient-ils avoir pour faire un message de blog dont le but principal est de dire "coucou, on voit vos mots de passe"? Le risque de "bad buzz" me semble assez évident avec un tel message, non?
[^] # Re: FUD ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 3 (+0/-0).
Que Cloud Flare est sous traitant au sens du RGPD.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# bah oui
Posté par steph1978 . Évalué à 10 (+11/-1).
Ils font la terminaison SSL, donc bien sûr qu'ils voient tout en clair.
[^] # Re: bah oui
Posté par Jean Gabes (site web personnel) . Évalué à 3 (+1/-0).
J'avoue que je ne vois pas où es le point également. C'est justement leur métier de terminer la sécurisation, donc par définition après eux, c'est en clair.
[^] # Re: bah oui
Posté par octane . Évalué à 2 (+0/-0).
chez eux, c'est en clair, mais j'espère qu'ils rechiffrent entre eux et le serveur final :-o
# pas que les mots de passe
Posté par mahikeulbody . Évalué à 5 (+3/-0). Dernière modification le 19 mars 2025 à 10:36.
https://blog.cloudflare.com/fr-fr/exploring-internet-traffic-shifts-and-cyber-attacks-during-the-2024-us-election/
Ils analysent aussi le contenu des mails.
(Juste par curiosité, pour quelle raison certains ont moinsé mon commentaire sous le lien alors que je ne faisais que poser une question (une vraie, en ce qui me concerne) ?
[^] # Re: pas que les mots de passe
Posté par Misc (site web personnel) . Évalué à 3 (+0/-0).
Tu veux dire que la boite qui te vends un service de filtrage de mail contre le spam et le phising fait ça en regardant les mails pour les filtrer ?
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.