@cy @cR0w If you read carefully you'll see that I applied Hanlon's Razor to the blog post, not the operational practices. On that part my argument is that they'd need to go far out of their way to do evil, which doesn't mean they don't do it, but I'm pretty sure they won't do it for a security-awareness blog post.

@cR0w @mark Yes, a MitM-as-a-Service provider *may* see and misuse your passwords.

Does this particular stat make any difference to that equation? No.

Validating Leaked Passwords with k-Anonymity - from #CloudFlare blog, 2018:

https://blog.cloudflare.com/validating-leaked-passwords-with-k-anonymity/

@cR0w @mark In fact, it was CF that contributed k-anonymity to HIBP:

https://blog.cloudflare.com/validating-leaked-passwords-with-k-anonymity/

@cR0w @mark As I see what needs clarification here is the security/privacy guarantees of the HIBP system (that's been around for some time), as that is the one accessing sensitive data. In a good architecture it should be impossible for that data to leak during/after real-time analysis, making the dispute about this particular statistic mute.

And again, let's not forget that participating origins agreed to this type of data use (hell, they may even need to configure what fields to snoop on!) - I wonder if their end-user privacy policies include this detail...

@cR0w I agree the post is far from optimal, but try to look at it this way: in a system as big as CF's you rarely see individual request data, but you can correlate HIBP alerts with status codes and write a blog post with big %s about password stuffing. You don't write about anonymization because you never saw anything that'd need anonymizing so there's nothing you did that's worth writing about. Again, I agree this should've been flagged by PR, but we've seen bigger blunders from that department...

#HanlonsRazor

@wdormann fulldisclosure () seclists org

I simply cannot. even.

@cR0w Mishandling the data is surely a concern, but I don't think this particular case is an indicator of such misuse:
HIBP API is anonymized in the first place. They must already have an "even more" anonymized yes/no signal from their detection service (whether it's using the anon API or a full HIBP copy), and at CF's scale I don't think anyone wants to receive all the non-anonymized request fragments for perf/bandwidth reasons alone.

Sure there may be an evil team at CF who secretly look at creds, but this stat is not an evidence of that.

This was one of the instances of insecure openid connect keys I blogged about recently https://blog.hboeck.de/archives/909-Mixing-up-Public-and-Private-Keys-in-OpenID-Connect-deployments.html the host auth.univie.ac.at has an openid connect configuration file. It points to https[://]auth.univie.ac.at/jwk for its jwks_uri that contains the public keys. Apparently, one of those keys is an example key used in the software "OpenID-Connect-Java-Spring-Server". Therefore, the private key is what I like to call a "Public Private Key".

@cR0w I mean users seem to have explicitly asked CF to look at the credentials passing through them. I don't get how workstations come to the picture, please clarify!

This is an important bit in the #Cloudflare post (emphasis mine):

"Our data analysis focuses on traffic from Internet properties on Cloudflare’s free plan, which *includes leaked credentials detection as a built-in feature.*"

We have released the files for the research that led to CVE-2024-36904. It contains the codes, the original kernel source, the patch and the modified kernel source that help to trigger the KASAN splat. If you want to play with the vulnerability, you can use the files.

https://github.com/alleleintel/research/tree/master/CVE-2024-36904/

There's another Office "intentional crash" detected by @expmon_ (background for the 1st one: https://www.linkedin.com/posts/haifeili_if-you-need-a-real-world-office-sample-triggering-activity-7304034115706597376-eVnM), it's a bit different (as I just quickly analyzed) but I'd like to leave it to anyone who is interested in investigating. :)

https://pub.expmon.com/analysis/254228/

So, Cloudflare analyzed passwords people are using to log in to sites they protect and discovered lots of re-use.

Let me put the important words in uppercase.

So, CLOUDFLARE ANALYZED PASSWORDS PEOPLE ARE USING to LOG IN to sites THEY PROTECT and DISCOVERED lots of re-use.

[Edit with H/T: https://benjojo.co.uk/u/benjojo/h/cR4dJWj3KZltPv3rqX]

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

#cloudflare #password #cybersecurity

Question to the Fediverse:

I'm looking for a mailing list / newsgroup solution (it can be SaaS or self hosted).

I need a couple things:
- Easy subscribe and unsubscribe functions
- Ability to send out mass emails to subscribers (basic functionality)

- Most important... and this is the weird part... I need all the subscribers to be able to "reply all" or to email the list as a whole, to also send messages to everyone. But I don't want them to be able to see everyone on the list.

I need an oldschool mailing list proper, where people can track the threads and replies, right.

All the marketing email lists are only top-down - the emailer mails all the recipients, but there is no allowing the recipients to email each other.

The best I have found is GNU MailMain: https://www.gnu.org/software/mailman/

Does anyone know any other examples?

Edit to add better nomenclature (my brain is not forming words right now):
- Allows for email discussion
- Allows for email threading
- Email Newsgroup - that's a good one

Editing to add answers to my own question:
- GNU Mailman: https://www.gnu.org/software/mailman/
- Gaggle Email: https://gaggle.email (cheers @zebbm)
- Groups io: https://groups.io (cheers @TNLNYC )
- Gray Duck Mail: https://grayduckmail.com
- mlmmj: https://mlmmj.org

Classic Microsoft: they force software you never asked for and didn’t want onto your PC. Then they ship a bug that accidentally removes it

https://www.thurrott.com/a-i/318558/windows-11s-march-security-update-may-remove-copilot-from-your-pc

@0xtdec @tante personal experience: when I served 403 to crawlers, they came back in disguise: no longer identifying themselves, and from entirely different ip ranges.

Same happened when I served them a static page.

Ever since I trapped them in a maze, apart from alibaba, they do not disguise themselves - and alibaba never identified itself in the first place.

So IME, a maze helps keeping them honest and busy. It does eat resources, but a LOT less than if I'd let them through.

I also ratelimit them at 100req/sec. If there are 100req/sec incoming into the maze, then everyone routed there gets 429'd. Normal visitors do not.

I wrote a summary of my experience running a maze since mid January: https://chronicles.mad-scientist.club/tales/a-season-on-iocaine/

My savings were massive: over 50gb traffic saved daily on my forge alone. Less cpu and ram used for anything that isn't served directly from the filesystem. And the rate limiting on top of this saves even more - more than the cpu & ram cost of garbage generation over serving static files.

@nemo Original article with comments from Signal: https://therecord.media/signal-no-longer-cooperating-with-ukraine

I feel like the message of Sir Tim Berners-Lee's latest op-ed in the Financial Times may suffer from its medium.

But don't worry, you can read his pitch for Solid here:

https://archive.ph/4Vvms