The fallout for Automattic’s behavior is felt by the rest of the community: anxiety, cancelled contracts with prospective clients, and an unclear vision for the long-term future of the WordPress open source project. There has been serious discussion about forking WordPress (a topic that I wouldn’t have imagined being discussed seriously as recent as two months ago!) to claw it out of Automattic’s death grip.
After I published my previous posts about this topic (highlighting the work I did since 2015 to improve the security of PHP and WordPress), the AspirePress team reached out to me and shared their vision for the future of WordPress.
Most critical to the WordPress community: The goals of AspirePress can be achieved without a hard-fork or fracturing the community.
If the AspirePress project is successful, one man’s ego will no longer be an existential threat to the future of an estimated 43% of websites on the Internet, or to the livelihoods of the people that rely on them.
I bring to the table years of experience with open source software development, application security, and applied cryptography. I’m committed to ensuring that the decentralization of the WordPress package ecosystem improves the security and trustworthiness of WordPress without unnecessary cognitive load on people who don’t care about security nerd stuff.
A better future is possible, and we will build it together.
One reason why the community might not want to do a hard-fork is that it could be disruptive to the entire WordPress Developer job title. Namely, it would make plugin and theme development and maintenance painful to support both WordPress and whatever the fork is named.
But that’s not actually a significant technical hurdle.
Because WordPress (and, by extension, its plugin and theme ecosystem) is copyleft licensed, the Forkers could easily write some infrastructure involving Rector (or a more specialized fork of Rector, heh) to plumb plugin/theme updates into the forked ecosystem.
That is to say, because of the existing work into helping open source software support wider ranges of PHP versions, I believe the “supporting WordPress and ForkPress” is not a significant technical challenge.
Additionally, if the ForkPress leadership sets up the plumbing to make this happen, the existing WordPress developers the world over won’t need to lift a finger to make it happen. (And since it’s all copyleft, they’re already licensed to do so, provided the output of their code transpiler is similarly licensed.)
There would still be some friction, naturally.
If the people leading a hypothetical WordPress fork actually heed my advice about making code-signing ubiquitous (and controlled by the developers of each plugin and theme), there would need to be an identity verification and hand-off process for the third-party developers to decide, “Instead of ForkPressAutoTranspileBot, I should be the one to ship this code and sign releases.”
Doing this hand-off on a first-come, first-serve basis would be a nightmare for the forked ecosystem.
We would need a way to make key management easy and secure, even for developers who don’t live in privileged countries with booming economies. As fun as it would be to say, “FIDO2 Tokens or Bust,” that’s prohibitive to many, and we need to be conscientious about those challenges.
But the one thing we have the technology to prevent today is forcing plugin/theme developers to write two different versions of their code to manage different APIs that follow different naming conventions. In that regard, it could be made painless (but not frictionless).
If Matt Mullenweg decided to be intentionally disruptive to these forks, it would require making drastic changes to the WordPress core that breaks compatibility with all existing plugins and then using some legal mechanism to prevent the forked code from following suit (which the GPL enables the fork to do). Not only would it be stupid to try that, it wouldn’t accomplish anything productive.
But, okay, so what? We can guarantee plugin/theme compatibility in a fork. What does that give us?
First, it gives the fork free reign to make breaking API changes (i.e., to remove any trademarks from the source code and avoid legal peril from Automattic), which matters for non-technical reasons.
But it also allows the fork to use “newer” PHP language features (i.e., namespaces). And new plugins can be written for modern PHP then transpiled to support WordPress’s norms.
As cool as that is, there is still an open problem to the plugin ecosystem.
And it’s not a new problem, by any means.
But since I promised I have ideas for security enhancements, I’d like to offer this one to the community to chew on.
Who Sources Your Source Code?
Code-signing addresses supply-chain custody problems: Did the software come from the person that it should have? It doesn’t solve the problem of, “What if the developer of a plugin or popular theme goes rogue and ships crypto-miners?”
When I proposed Gossamer, I specified Third-Party Attestations as a building block for building defenses against this sort of attack. That certainly could be useful for WordPress (or a fork thereof): Require a third party to at least spot check the code changes from the previous release to make sure nothing deliberately malicious was shipped.
Another idea I’d like to propose is to perform a differential analysis of the cyclomatic complexities of each unit of PHP and/or JavaScript code.
When a new release is proposed, compare the new code release with the previous one.
Large differences in the structure of the code should be flagged for manual review (especially if it’s only a minor version bump or patch release).
Additionally, compare the current snapshot with the last version that was marked as manually reviewed. If each piecemeal change was small, but there was a lot of them, it may add up to warrant additional third-party scrutiny.
This isn’t entirely novel. In fact, this sort of work sounds right up the alley of the WordFence team to build, should they choose to embark on this task.
WordPressed For Time
I have several other ideas about ways to improve the assurance and robustness of the ecosystem, but some of them require secure code delivery (code-signing + transparency logs + reproducible builds) to already exist to be worthwhile.
In the interest of a positive and productive conversation about the future of the ecosystem that accounts for damn-near half of websites, consider the ideas shared on these pages freebies.
A better future is possible, if only we have the will to build it.
Now, as I wrote on a Hacker News thread, I’d been staying out of this drama. It wasn’t my fight, I wasn’t deeply familiar with the lore of the players involved, etc.
Mullenweg’s behavior also calls into question the trustworthiness of WordPress not just as a hosting platform (WP.com, which hosts this website), but also the open source community (WP.org).
I do not have a crystal ball that tells me the future, so whatever happens next is uncertain and entirely determined by the will of the WordPress community.
Even before I decided it was appropriate to chime in on this topic, or had really even paid attention to it, I had been hearing rumors of a hard-fork. And that maybe the right answer, but it could be excruciating for WordPress users if that happens.
Regardless of whether a hard-fork happens (or the WordPress community shifts sufficient power away from Mullenweg and Automattic), this vulnerability cannot continue if WordPress is to continue to be a trustworthy open source project.
Since this is a cryptography-focused blog, I’d like to examine ways that the WordPress community could build governance mechanisms to mitigate the risk of one man’s ego.
Revisit Code-Signing
The core code, as well as any plugins and themes, should be signed by a secret key controlled by the developer that publishes said code. There should be a secure public key infrastructure for ensuring that it’s difficult for the infrastructure operators to surreptitiously replace a package or public key without possessing one of those secret keys.
I had previously begun work on a proposal to solve this problem for the PHP community, and in turn, WordPress. However, my solution (called Gossamer) wasn’t designed with GDPR (specifically, the Right to be Forgotten) in mind.
Today, I’m aware of SigStore, which has gotten a lot of traction with other programming language ecosystems.
I think, at the intersection of both systems, there is a way to build a secure PKI where the developer maintains the keys as part of the normal course of operation.
Break-Glass Security with FROST
However, even with code-signing where the developers own their own keys, there is always a risk of a developer going rogue, or getting totally owned up.
Ideally, we’d want to mitigate that risk without reintroducing the single point of vulnerability that exists today. And we’d want to do it without a ton of protocol complexity visible to users (above what they’d already need to accept to have secure code signing in place).
Fortunately, cryptographers already built the tool we would need: Threshold Signatures.
From RFC 9591, we could use FROST(Ed25519, SHA-512) to require a threshold quorum (say, 3) of high-trust entities (for which there would be, for example, 5) to share a piece of an Ed25519 secret key. Cryptographers often call these t-of-N (in this example, 3-of-5) thresholds. The specific values for t and N vary a lot for different threat models.
When a quorum of entities do coordinate, they can produce a signature for a valid protocol message to revoke a developer’s access to the system, thus allowing a hostile takeover. However, it’s not possible for them to coordinate without their activity being publicly visible to the entire community.
The best part about FROST(Ed25519, SHA-512) is that it doesn’t require any code changes for signature verification. It spits out a valid Ed25519 signature, which you can check with just libsodium (or sodium_compat).
Closing Thoughts
If your threat model doesn’t include leadership’s inflated ego, or the corruption of social, political, and economic power, you aren’t building trustworthy software.
Promises and intentions don’t matter here. Mechanisms do.
Whatever the WordPress community decides is their best move forward (hard forks are the nuclear option, naturally), the end result cannot be replacing one tyrant with another.
The root cause isn’t that Mullenweg is particularly evil, it’s that a large chunk of websites are beholden to only his whims (whether they realized it or not).
If you aren’t immune to propaganda, you aren’t immune to the corruption of power, either.
But if you architect your systems (governance and technological) to not place all this power solely in the hands of one unelected nerd, you mitigate the risk by design.
(Yes, you do invite a different set of problems, such as decision paralysis and inertia. But given WordPress’s glacial pace of minimum PHP version bumps over its lifetime, I don’t think that’s actually a new risk.)
With all that said, whatever the WordPress community decides is best for them, I’m here to help.
Musing about Password-Based Cryptography for the Government
What would a modern NIST standard for password-based cryptography look like?
Obviously, we have PBKDF2–which, if used with a FIPS-approved hash function, gives you a way to derive encryption keys and/or password validators from human-memorable secrets.
However, PBKDF2 isn’t memory-hard.
In 2012, several cryptographers initiated the Password Hashing Competition (PHC) to study the state-of-the-art for password-based cryptography at the time. Part of this motivation was that memory-hard hashing (first developed by Colin Percival in scrypt a few years prior) provided greater defense against the increasing parallelism of modern password cracking techniques.
After a few years of cryptanalysis, the PHC selected an algorithm called Argon2, and gave special recognition to four other finalists.
If you’ve never heard of NIST SP 800-108 before, or NIST Special Publications in general, here’s a quick primer:
Special Publications are a type of publication issued by NIST. Specifically, the SP 800-series reports on the Information Technology Laboratory’s research, guidelines, and outreach efforts in computer security, and its collaborative activities with industry, government, and academic organizations. These documents often support FIPS (Federal Information Protection Standards).
One of the NIST 800-series documents concerned with Key Derivation using Pseudorandom Functions is NIST SP 800-108, first published in 2009.
In October 2021, NIST published a draft update to NIST SP 800-108 and opened a comment period until January 2022. This update mostly included Keccak-based Message Authentication Codes (KMAC) in addition to the incumbent standardized designs (HMAC and CMAC).
Upon reviewing a proposal for NIST SP 800-108 revision 1 after its comment period opened, Amazon’s cryptographers discovered a novel security issue with the standard.
I was a co-author of the public comment that disclosed this issue, along with Matthew Campagna, Panos Kampanakis, and Adam Petcher, but take no credit for its discovery.
Consequently, Section 6.7 was added to the final revision 1 of the standard to address Key Control Security.
This post examines the attack against the initial SP 800-108 design when AES-CMAC is used as the PRF in KDF Counter mode.
Head’s up: This is a blog post about applied cryptography, with a focus on web and cloud applications that encrypt data at rest in a database or filesystem. While the lessons can be broadly applicable, the scope of the post is not.
One of the lessons I learned during my time at AWS Cryptography (and particularly as an AWS Crypto Bar Raiser) is that the threat model for Encryption At Rest is often undefined.
Prior to consulting cryptography experts, most software developers do not have a clear and concise understanding of the risks they’re facing, let alone how or why the encrypting data at rest would help protect their customers.
Unsurprisingly, I’ve heard a few infosec thought leader types insist that encryption-at-rest is security theater over the years. I disagree with this assessment in the absolute terms, but there is a nugget of truth in that assertion.
The million dollar question.
Let’s explore this subject in a little more detail.
Here’s a “fun” challenge: Try to articulate valid criticism of some bullshit artist business executive high in the org chart that has no real technical chops, which unfortunately manifests in their poorer decisions, without also somehow alienating junior technical employees who might feel unsure of themselves (skills, experience, qualifications, or even “culture fit”) if they overhear it.
If it sounds impossible to you, don’t worry! I’m probably going to fail, too.
I didn’t want to add my voice to the cacophony of hot takes about the xz backdoor incident because I’m sure many people are already sick of hearing about it.
However, there is something related to it that I’ve been noodling over for a while. As a compromise, I won’t summarize or rehash the xz incident to spare anyone from having to read that for the thousandth time.
Most of the postmortem conversation I’ve witnessed has centered around the burnout of open source developers, corporations’ reliance and profiteering from volunteer labor, and how these factors can create a perfect storm for any nation state or sophisticated cyber-crime group that wants to backdoor infrastructure for their own gain.
Like most cryptography and security experts familiar with JWT, I would much rather you use something else if you can. I even proposed a secure alternative called PASETO in 2018 (with an optional extension called PASERK to handle advanced use-cases; namely key-wrapping and asymmetric encryption).
The DB-ESDK is the successor to the DynamoDB Encryption Client (DDBEC) for Java and provides a lot of cool improvements and features, such as searchable encryption through Beacons.
While most of the cool and interesting parts of the DB-ESDK can be found in the User Guide, there are some subtle aspects that you will only discover from reading the source code or talking with the people who designed the cryptography the new SDK uses.
Fortunately for this blog, I was the security engineer responsible for designing the new message format used by the DB-ESDK in 2021.
The final product you see online today is a significant improvement upon my original vision, thanks to the hard work and diligence of the rest of the AWS Crypto Tools team and the cryptographers at Amazon, so please do not ascribe the credit for any of these design decisions solely to me.
As a supplement to the user guide and specification, I’d like to highlight some of the decisions we made and how they benefit anyone who uses the AWS Database Encryption SDK.
But first, a quick disclaimer:
This blog post is the sole opinion of some guy named Scott and does not represent the views or opinions of any company or its employees, least of all Amazon.
Like most humans, Scott is often wrong or mistaken about lots of things. This blog post is provided for educational and entertainment purposes, and should not be taken as an official source for anything except Scott’s personal opinion about cryptography nerd topics.
Seriously. This is just for fun, because crypto is cool.
