[wp-trac] [WordPress Trac] #39309: Secure WordPress Against Infrastructure Attacks
WordPress Trac
noreply at wordpress.org
Tue Jan 17 06:17:44 UTC 2017
#39309: Secure WordPress Against Infrastructure Attacks
------------------------------------------+-----------------------------
Reporter: paragoninitiativeenterprises | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: Future Release
Component: Upgrade/Install | Version: trunk
Severity: normal | Resolution:
Keywords: has-patch | Focuses:
------------------------------------------+-----------------------------
Comment (by paragoninitiativeenterprises):
> I don't think shipping a PHP-based SHA512 implementation is worth
anyones time here.
Given that `hash()` is supposed to be in PHP 5.1.2 and newer, anyone using
something as old as 5.2.4 should have still it:
http://php.net/manual/en/function.hash.php
Anyone who claims not to is either lying about their actual PHP version or
running a dangerous configuration, probably by having compiled it
themselves once upon a time.
Either way, I'd agree with not supporting systems without ext/hash.
> All signatures should be transparent to a user, a typical user should
never be prompted to enter hashes, nor see them.
Indeed, the only person who will **ever** need to do anything is the
release managers.
> Individual w.org authors having their own keys/etc, should be kept out
of scope for now and focused on later, don't complicate matters further
than needed for now, focus on the W.org => W link.
Yep. That's why the patch has a hard-coded Ed25519 public key (the exact
keypair given is in my comment above).
> It should also be expected that core would have a minimum of 2 valid
signing keys authorised, to allow for secure revocation and replacement.
This is similar to Airship's requirements, where everyone has at least two
keys: One master key, and one signing key. The master key can revoke or
mint new (master, signing) keys. The signing keys are the ones actually
used for package signing. (This is true for Paragon as it is for anyone
who builds an Airship extension.)
This is a more robust model should the signing key ever be compromised.
> Focusing on Ed25519 seems fine to me, however, I've reached out to a few
others to ask if anyone has other preferences we should look at here.
Please do.
> 39309.2.patch doesn't actually use the libsodium extension, correct?
due to it's reliance upon ParagonIE_Sodium_Compat::*()
It uses sodium_compat. If ext/libsodium is installed, sodium_compat will
just kick off to the extension. If it's not installed, then sodium_compat
uses the pure-PHP implemenation. This is a reasonable trade-off:
* If you can install PHP extensions from PECL, you get greater performance
and less risk of side-channels introduced by the PHP interpreter
* If you cannot install PHP extensions from PECL, you can still verify
signatures etc.
> @paragoninitiativeenterprises I assume it wouldn't be possible for us to
only ship the the Ed25519 crypto (&dependancies) with WordPress, we'd have
to pull the full libsodium compat in, correct?
Strictly speaking, it is possible to isolate Ed25519 and its dependencies.
However, that's a hack job that I don't think anyone is going to want to
perform every time we release an update. Given the delicate nature of
security code, I wouldn't recommend doing so. Additionally, if someone
wanted to use sodium_compat in a WordPress project (e.g. an extension that
communicates via the Noise protocol framework, using our ChaCha20Poly1305
implementation) and you only pulled in part of it, they'd probably have a
bad time.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/39309#comment:14>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list