Per
the below discussion, this incident suggests a
feature request: A “logout all” button, which kills all of a user’s active sessions on the server side.
Most high-security sites nowadays have a page where you can view all active sessions, the date, time, and IP address that created each session, kill sessions, and kill all sessions. It would be faster and easier to implement a simple “please destroy
all active sessions, including this one” button.
Use case: I want to clear old sessions routinely, but not to make frequent password changes.
PHP is a much more complex system than PGP or other cryptography algorithms, so theres less a chance a vulnerability exists [in PGP].
I think that it’s less a question of complexity, and more one of
competence. PHP is, and always has been a mess. And its shit code is deeply embedded in the infrastructure of the Web.
There’s no easy way for theymos to stop using PHP, unless he wants to
pay me big BTC for a new new forum project I will probably never deliver. That would(n’t) work!
The project is called Nulltalk, because its distinguishing innovation shall be that it autobans all users, and stores all posts in the /dev/null NoSQL database. Thus, there shall be no talk. Silence!
As for cryptography, let’s put it this way: Could a frontier LLM have discovered
the catastrophic (Castryck and Decru, 2022) key recovery break of SIDH, which was based on an obscure mathematics paper
(Kani, 1997) that cryptographers simply hadn’t noticed before 2022? For better
or for worse (and I think it’s for the worse), after the September 2026 mathematical news, I would not bet no.
It is not that “AI is smart”, but an LLM has an enormous capacity to search stores of human knowledge. And note to newbies: You will not get results prompting a chatbot. For its September 2026 discoveries, OpenAI spent many millions of dollars on computational cost—with a model they haven’t yet made available to the public in any way.
I believe an attacker could also have either created new sessions or obtained sufficient information to impersonate someone using an active session. This would allow them to impersonate someone after the fact until the session is invalidated.
Indeed...
change your password (mainly just to invalidate all of your sessions).
...but in my case, I think I had no active sessions. I distinctly recall that my last long-term login cookie’s expiry was in 2023; does cookie expiry match server-side expiry?
As you note, an attacker could have created new sessions—which a password change would invalidate. This could even affect, say, an acknowledged alt of mine that hasn’t logged in since 2018.
For the time being, I have also stopped using long-term login cookies. It’s inconvenient.
This would be a lot cheaper than trying to reverse the hash of a password that has an unknown complexiety.
In 2017, I created my account with a 30-char alphanumeric random password; that’s infeasible to hashcat, even if the password database used unsalted MD5. It’s now changed to >30 chars, with new code I wrote that builds a base-62 string from
getrandom(2) output with no modulo bias.
YMMV. When password managers exist, why does anyone use a password with <128 bits of min-entropy? (
See also.)
Every since the PHP attack, I have been experiencing this error where Cloudflare is unable to communicate with the forum's web server.
Shortly before you posted this, my scraper failed some of it's attempts. That usually means the forum can't be reached.
I've seen this screenshot on many sites in the past week.
I have noticed that the forum seems sometimes very slow. This perception is qualitative, not quantified. Does this match anyone else’s perception?
Four hypotheses:
- PHP emergency patch is buggy.
- Cloudflare’s emergency WAF rules (which only partly mitigate this 0day) are buggy.
- Attackers gained persistent access to many sites, including the Bitcoin Forum.
- New 0day.
My apologies to everyone, I’m way behind on about a half-dozen threads. Besides other distractions, my forum-fu is rusty.
