benjojo.co.uk

one honk maybe more

dangoodin@infosec.ex.. posted 18 Mar 2025 17:03 +0000

To follow up on yesterday's discussions about privacy implications of Cloudflare detecting the use of reused passwords in traffic passing through its infrastructure, Cloudflare has disclosed this practice previously. The protocol behind this check, known as Might I Get Pwned (in a nod to @troyhunt), was described in a 2022 Usenix paper called Might I Get Pwned:
A Second Generation Compromised Credential Checking Service. It devises what it claims is a privacy-preserving way to check for credential reuse. It involves comparing hashes. Cloudflare says passwords are never logged.

I'm home recovering from a Covid infection, so I don't have the energy to dig into this any deeper right now. I am interested in responses from people qualified to evaluate the privacy-preservation claims, including @benjojo @cR0w @Viss and @matthew_d_green

Relevant links:

https://arxiv.org/pdf/2109.14490

https://blog.cloudflare.com/helping-keep-customers-safe-with-leaked-password-notification/

https://blog.cloudflare.com/privacy-preserving-compromised-credential-checking/

benjojo replied 18 Mar 2025 17:28 +0000
in reply to: https://infosec.exchange/users/dangoodin/statuses/114184514710797895

@dangoodin @troyhunt @cR0w @Viss @matthew_d_green

(Bear with me on the long reply, trying to cover all bases here)

I don't think the "leaked credentials detention" product is a red flag per say, Maybe the automatic enablement of it is a can of worms, reason being is that people do not typically think that their web proxy is going to snoop their users credentials, even if it is not storing the full outputs of that snooping.

There is probably bigger set of discussions that should be made about the data source of these leaked credentials, given they are inevitably sourced actual data breaches of other people's stuff! Though this is basically the commercial exploitation of stolen user data, it is probably for the greater good to use such leaks (however dubiously obtained) to detect leaked credentials in the future, but idk!

The thing I really wanted to point out in the original post on my side was that it seems relatively unsettling for a company to be very confidently showing off data outputs that have been derived from non explicit consensual snooping of passwords. A lot of replies suggested they could be storing data, but they are almost certainly not storing the passwords themselves (because any breach of that would probably be a company ending event), but CF's demo of the metrics (given how they were obtained) shows a level of hubris which is perhaps a little alarming.

A lot of replies suggest this is a GDPR problem, I am not a legal guy but I don't think any of this is a GDPR problem, but there is a somewhat obvious question in 2025 (to someone in Europe that is) of an american company snooping the user submitted data of your requests that likely has other PII in it to provide a WAF/etc, but none of this is new to cloudflare.

Ultimately the websites impacted by default are the ones who don't pay cloudflare anything, there may be a lesser amount of care because of that, but there are probably limits to what kind of stuff people are willing to swallow. Password snooping without explicit consent seems (to me) to get very close to that line, but I am just 1 guy.

It's worth stepping back a bit and acknowledging that there is a reason that people use cloudflare. It's because the product is actually kind of good, it's solves a bunch of problems of people in a cheap and reasonable way. I don't think there's any foul play going on the widespread adoption of cloudflare, it's more that people will choose what is convenient, and cloudflare is mighty convenient. I wish for better alternatives like many others, but right now some of the alternatives are worse either technically or ethically.

troyhunt@infosec.exc.. replied 18 Mar 2025 19:58 +0000
in reply to: https://benjojo.co.uk/u/benjojo/h/fGpc3SfYQL75r3v1RF

@benjojo @dangoodin @cR0w @Viss @matthew_d_green I suggest the term “snooping” is the problem here. A huge part of the value proposition of any reverse proxy with WAF features (not just Cloudflare) is the ability to inspect traffic. By design, a service like this sits in a position where they can inspect traffic, and that’s a decision the site operator makes. Inspecting traffic then also provides the ability to report on it; I can pull back traffic stats based on the UA string, for example. There’s no explicit “consent” involved in people sending that data, just like there’s no explicit consent in them submitting a form with PII in it; it’s implied. It’s also up to the site owner to enable leaked credential check, who already has the ability to decide what happens to passwords submitted to their service whether CF exists or not: https://developers.cloudflare.com/waf/detections/leaked-credentials/

benjojo replied 18 Mar 2025 21:01 +0000
in reply to: https://infosec.exchange/users/troyhunt/statuses/114185201005562624

@troyhunt @dangoodin sure, I use "snooping" very much on purpose, I'm also really aware of what a WAF is given I wrote a very high % of the whole Cloudflare WAF from 2014 to 2017 :P

https://blog.cloudflare.com/author/ben-cartwright-cox/

I am working in a different industry now though.

There’s no explicit “consent” involved in people sending that data

I'm not talking about the consent of the users, my larger problem is cloudflare enabling features that handles arguably some of the most sensitive data on free customers without asking them, and then publishing metrics on it, It just has a bad vibe.

It’s also up to the site owner to enable leaked credential check

This is verifiably not true for free users.

Here is what I did to confirm that.

1) I take a domain that is on the free plan, that I have not touched the cloudflare settings for years, check the security tab, 0 "Password leaked" hits

2) Make a subdomain test.<domain> to point to a test instance

3) Write a "hello world" test web server that dumps headers

4) fire a mimic login that wordpress would use:

$ curl -X POST -d 'log=username&pwd=password&wp-submit=Log+In' https://test.xxxxx.com/wp-login.php

5) There is no header to confirm it was a compromised password, but if we reload the cloudflare dashboard, it detected the password.

This is the crux of my problem. I don't think it's ethical to have this kind of feature enabled by default with no consent. The product as a concept is fine, as long as people opt into it.