knowing when to trust a login page on a Cloudflare site
from coffeeClean@infosec.pub to cybersecurity@infosec.pub on 27 Mar 2024 08:10
https://infosec.pub/post/10262373
from coffeeClean@infosec.pub to cybersecurity@infosec.pub on 27 Mar 2024 08:10
https://infosec.pub/post/10262373
Question for people willing to visit Cloudflare sites:
How do you determine whether to trust a login page on a CF site? A sloppy or naïve admin would simply take the basic steps to putting their site on Cloudflare, in which case the authentication traffic traverses CF. Diligent admins setup a separate non-CF host for authentication.
Doing a view-source on the login page and inspecting the code seems like a lot of effort. The source for the lemmy.world login page is not humanly readable. It looks as if they obfuscated the URLs to make them less readable. Is there a reasonably convenient way to check where the creds go? Do you supply bogus login info and then check the httpput headers?
threaded - newest
I think you can assume that your credentials go via Cloudflare.
But the only thing you can do on lemmy is post stuff publicly, and presumably you are using randomised passwords, so what’s the cyber security risk?
That would be my natural assumption until the contrary is verified.
I would not register on a CF site for anything AFAICT, and most certainly not a CF Lemmy site amid non-CF Lemmy sites (it would be a compromise for nothing and also help grow a walled garden that excludes people and centralizes the fedi to the detriment of undermining fedi philosophy). Lemmy.world is just a good example for my question because the code is obfuscated.
My problem is often that I register on a non-CF service then it becomes CF and it’s not always social media. Indeed I use unique unguessable passwords for each site. But that’s not what the masses do (I’m asking as well to work out how the masses could detect this - in principle their browser should tell them; what should I tell my grandma to look for?). I’m also trying to work out what diligent users do.
I’m not sure how many people will evade my question. So I’ll try some examples to overcome that.
Example 1
Suppose my bank becomes Cloudflared, without announcement (thus no time to pull my money out before it happens), and they charge a high fee for paper statements. The customer may choose good unique passwords, but this does not mean that password does not need to be protected. Most banks’ terms of service make customers liable for sharing creds with a 3rd party, and the ToS also includes an indemnity/disclaimer for that bank. So if creds are compromised via CF the ToS is written to make the customer liable.
Example 2
Suppose I am reporting a GDPR offender to a regulator. I want my report to be complete. If they are sloppily passing sensitive info like login creds through Cloudflare, I should check that and if yes smear them for it in my report.
Examples aside, I’m asking how a diligent user checks whether their creds are shared with CF.
Yes, CF can view your login creds as the reverse-proxy effectively acts as a MitM handling the encryption and decryption.
It’s not always the case though. If you look at vivaldi.net and stackexchange, the creds take a CF-free path.
You don’t. Assume the password is hashed server side and are sent unhashed via the TLS session that CF mitm.
What if I am reporting a GDPR offender who (e.g.) neglected my article 15 request? If I make the assumption you are suggesting and add to my Article 77 complaint that the data controller also needlessly exposes passwords to Cloudflare and it turns out to be untrue for that particular service, then my report loses credibility and puts a DPA on a run around.
.
You seem to make the assumption that CF is storing that level of your data. In all likelihood CF are inspecting the traffic for malicious intent and if there is nothing malicious the non metadata is dropped.
What have I said that would imply a presumption of retention?