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é à 6 (+4/-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 ¯\_(ツ)_/¯
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…
# FUD ?
Posté par mahikeulbody . Évalué à 5 (+3/-0). 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é à 3 (+3/-3).
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é à 4 (+1/-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 nud . Évalué à 6 (+4/-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 ted (site web personnel) . Évalué à 5 (+3/-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é à 1 (+0/-1).
à 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é à 4 (+2/-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 jtremesay (site web personnel) . Évalué à 4 (+2/-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é à 4 (+2/-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é à 2 (+0/-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é à 4 (+2/-0).
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…
# bah oui
Posté par steph1978 . Évalué à 7 (+6/-1).
Ils font la terminaison SSL, donc bien sûr qu'ils voient tout en clair.
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.