Yes. Right now. Don't wait for the vendor to notify you.
> What an epic mess. This is the problem with centralization, the system is broken.
Yep.
Yes. Right now. Don't wait for the vendor to notify you.
> What an epic mess. This is the problem with centralization, the system is broken.
Yep.
If it only took 60 seconds per site, it would still take eight hours to change them all.
Might change a few key passwords, though. Couldn't hurt. I only have a couple of bank/financial passwords at this point. And my various hosting service access passwords.
Anything else is not worth the hassle -- and mostly would have 2FA anyway.
So LastPass isn't the password manager mentioned in the post.
Instead I'm using KeePass. KeePass is open source and has its "full stack" of encryption available for review. For LastPass I need to trust they're doing everything right, and that a government actor hasn't asked for some kind of backdoor. It's so easy to screw up security that I'm more comfortable trusting two levels of security: That KeePass has its encryption done right, and that Google Drive keeps my KeePass file out of the hands of bad-guys.
LastPass would become a single point of failure compared to what I'm doing: They just need to make one mistake and suddenly any bad guy gets all of my passwords.
Nice feature for LastPass, though.
The decision to wear a seatbelt isn't driven by the probability of needing it, the decision is drive by the magnitude of exposure to an event where you would need it.
The same isn't quite true for my blogger account.
The cost of your life is much higher than your blogger account, but it's not literally infinite, even from your own perspective.
If it were truly infinite, then it would be irrational for you ever to take any action that were not 100% motivated by the desire to protect your life. (Not just "never take any risks", but literally irrational not to actively spend every waking second solely on that goal).
You misunderstand. My argument is explicitly around "What is the potential effect?" That's why I listed changing financial passwords is on my list of things that I might do. (Though see below for why I won't.)
If I only change passwords where someone can do real damage (my primary social media accounts, my accounts that have a current, saved credit card, and any hosting-related accounts) then I've already hit the 98th percentile in damage avoidance. And as I pointed out above, most (all?) of those accounts are unaffected because they don't use CloudFlare at all.
If someone has stolen my password to the Woodworking Forums, and they ... what, post rabid alt-right spam in my name and get me banned? Oh well, either tell them that it was hacked, or if they don't believe me, let that account die and create a new one, if I ever decide to go back and post something again. No big deal. I haven't used it in years anyway, and I can create unlimited new (wildcard-based) email addresses on any of several domains I own.
Aside from the top 10-15 sites I use, I rarely have logins that are that important, anyway. So I'm totally basing this on worst-case damage assessment, not on "how likely it is I'm attacked."
AND...I just looked through all of the top sites I use, and according to the HTTP header, none of them is served using CloudFlare at all (I only checked the index page of each, but none have the telltale CF-Cache-Status headers). No financial sites, no shopping sites that have my credit card, no social media sites. So where's the fire exactly?
Which one is it? Hacker News.
When I log into the Woodworking Forums, I have to use a password. If someone steals my Woodworking Forums authentication and posts as me there, um....Oh well. Sucks, and I'll clean up the mess.
Glancing through my password vault (kept in KeePass, for those wondering) I have some in there that I literally haven't used since before Cloudfare was founded, like the Creative Labs developer site.
(Where I mean some other sites that are not at all HN, but might plausibly exist.)
$ curl -I okcupid.com
Set-Cookie: __cfduid=...
Server: cloudflare-nginx
CF-RAY: 335f033b77742b76-AMS
EDIT:
Better yet, make that 'curl -IL domain.com' to follow redirects because it may not show in the first response.to get the A Record, then
$ whois 1.2.3.4|grep Cloudflare
Not 100% reliable, but should do the Job.
whois $(dig +short yoursitehere.com) | grep -i 'Cloudflare' 1>/dev/null; if [[ $? -eq 1 ]]; then echo 'Didnt find CloudFlare'; else echo 'Found CloudFlare'; fi
Not at a terminal now, but this long one-liner should work.Like you said, not 100% reliable though. For example, I'm pretty sure Reddit uses CloudFlare, but their whois mentions Fastly, which is a competitor.
digitalocean.com name server walt.ns.cloudflare.com.
digitalocean.com name server kim.ns.cloudflare.com.
$ host -t NS okcupid.com
okcupid.com name server nameserver2.okcupid.com.
okcupid.com name server nameserver1.okcupid.com.
But if you check the response headers you'll see 'CF-RAY:...' and 'Server: cloudflare-nginx'https://chrome.google.com/webstore/detail/claire/fgbpcgddpmj...
https://chrome.google.com/webstore/detail/claire/fgbpcgddpmj...
In other words: Just assume that everything has been compromised. With how much of the web CloudFlare controls nowadays, you're not going to be far off anyway.
append /cdn-cgi/trace to the URL and you will some debug info
Ex:
...but since this bug has been out in the wild since perhaps 2016-09-22, now is indeed, the time to go and reset your active sessions and change all your passwords.