home tags events about login
one honk maybe more

benjojo posted 17 Mar 2025 14:09 +0000

It feels quite uncomfortable that cloudflare is somewhat openly admitting to analysing login credentials that are going through the reverse proxy, and providing aggregated stats on it (without explicit consent of the user it appears?)

Based on Cloudflare's observed traffic between September - November 2024, 41% of successful logins across websites protected by Cloudflare involve compromised passwords.

Don't get me wrong the results are actually pretty interesting, but I just cannot think of a ethical way of doing this, and it feels kind of jarring that they just "did that"

https://blog.cloudflare.com/password-reuse-rampant-half-user-logins-compromised/

mark@mastodon.fixerm.. replied 17 Mar 2025 14:34 +0000
in reply to: https://benjojo.co.uk/u/benjojo/h/Yt3Xb92nHL8R4vTmb6

@benjojo One of the hard things about this entire space (responsibility and liberty of cloud service providers) is how feelings translate into policy.

I'm fine with it; in fact, given that this is their free-service tier and it's on a feature site admins opted into (... and one of the capabilities of the feature is, explicitly, "please analyze this password and send signal back to my service that I should stop trusting it and ask my user to reset their account"), I'm not at all surprised they're collecting aggregate statistics across users (compare GMail spam filitering, which does half of its "magic" by collecting aggregate information on what individual users flag as spam, which is why otherwise-legitimate rule-following email campaigns sometimes get caught in the net because regardless of whether they followed the rules, end-users, who do not know the rules, found them annoying enough to flag 'em en masse).

But I can also see the point of view that says it's creepy, and I don't envy policymakers the challenge of finding common ground between those views.

(FWIW, I doubt they were doing this analysis out of the blue. I'd assume they're always doing this analysis because it's likely necessary for system health and integrity, and the only thing new is they shared some conclusions. I don't have a blanket ethos by which I can evaluate whether other uses of collected data are moral, much less legal; I treat it on a case-by-case basis for my own personal judgment, and in this case I'd assert the net benefit of getting hard numbers behind a known issue outweighs the cost of people being concerned because now they know a third-party is also seeing their password transiting... in fact, this might be win-win because now people know that the reverse proxy can see their password where previously they did not).

benjojo replied 17 Mar 2025 14:54 +0000
in reply to: https://eldritch.cafe/users/amberage/statuses/114178328992511378

@amberage to the best of my understanding they have code that:

1) Looks in POST parameters for things that looks like login credentials

2) Runs the password over something that looks like a bloom filter

3) Adds a header to the request (on it's way to the actual server) to tell it that the password is known to be compromised, and I guess they increment some counter on their backend analytics.

If they are recording the username/password into their infra, that would be completely insane and probably a very fast destruction to their business. I would assume they are not doing that.

amberage@eldritch.ca.. replied 17 Mar 2025 14:56 +0000
in reply to: https://eldritch.cafe/users/amberage/statuses/114178347222273570

@benjojo (plus, I always thought passwords aren't POST sent in plaintext to the actual website; I always assumed the front-end – that is, the website in my browser – already does the hashing and salting and only sends the result from my browser to the server. Distressing to find out that's not the case.)

Edit: You can stop explaining it to me now, plenty of people have.

benjojo replied 17 Mar 2025 15:01 +0000
in reply to: https://eldritch.cafe/users/amberage/statuses/114178351954255959

@amberage almost every website that i have ever looked at sends the password in plain text wrapped in a POST x-www-form-urlencoded.

There is not much point in hashing the password on the browser end, given that hash would just become a proxy of the password, and the channel the POST is sent through is assumed to be secure (https/tls etc).

Also given that a lot of hashing (should) now be things like bcrypt or argon, it would require the website to disclose the salt (which should be random bytes) to the user, and that would probably then also disclose the existence of an account (something that is typically not desirable)

If you have a compromised browser/tls proxy it is already game over, a hashing bit of JS isnt going to help you (and it will just prevent users with javascript disabled from logging into the website)

benjojo replied 17 Mar 2025 14:19 +0000
in reply to: https://plasmatrap.com/notes/a5gpj3sx6b

@privateger One of the throwaway test domains I have appears to have "Account abuse detection" enabled on it, at least according to the analytics, I have not opted into such scanning, and this is a free plan domain. I think they enabled it for a free users by default?

benjojo replied 17 Mar 2025 14:29 +0000
in reply to: https://plasmatrap.com/notes/a5gq3hmf6y

@privateger Seems to be yeah, I can load up the dashboard area, I will admit it's been a very long time since I've been in this area of the CF dash (or really in the CF dash at all), I spent maybe 3 years in it when I wrote a lot of the cloudflare WAF from 2015 to 2017 (ish) :)

jesopo@chaos.social replied 17 Mar 2025 14:53 +0000
in reply to: https://plasmatrap.com/notes/a5gqdirt7n

@privateger @benjojo still sorta true, paid customers get 2 extra things:

- custom login detections (https://developers.cloudflare.com/waf/detections/leaked-credentials/#custom-detection-locations)
- additional exposure detection types (https://developers.cloudflare.com/waf/detections/leaked-credentials/#leaked-credentials-fields)

the tl;dr is
- free customers can only use the login page detection patterns cloudflare provides, so if your login endpoint is atypical, cloudflare wont know it's a login endpoint
- free customers can only know if the password has been leaked, not e.g. if the username and password have both been leaked

benjojo replied 18 Mar 2025 14:21 +0000
in reply to: https://ice.cream.chitanda.moe/notes/a5i4wy8ug23q000s

@eru @matclab @jesopo

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 (the reason being is that people do not typically you think that their web proxy is going to snoop credentials, even if it is not storing the full outputs of that snooping)

That's probably another set of discussions to be made about the data source of these leaked credentials inevitably being form 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.

My wider a comment about all of this is 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, they are almost certainly not storing the passwords themselves (because any breach of that would probably be a company ending event), but it shows a level of hubris which is perhaps a little alarming.

I don't think any of this is a GDPR problem (other than the obvious question of an american owned 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.

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 always 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.