[wp-trac] [WordPress Trac] #39309: Secure WordPress Against Infrastructure Attacks
noreply at wordpress.org
Tue Jan 17 03:09:16 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:
Changes (by dd32):
* milestone: Awaiting Review => Future Release
I don't have time to delve deeply into this right now, however, a few very
* Due to our old PHP support, sometimes `ext/hash` isn't available.
#29518 We may be able to require the extension, or simply skip signature
verification for those cases. I don't think shipping a PHP-based SHA512
implementation is worth anyones time here.
* Once again, `ext/spl` can be disabled under PHP 5.2. So no form of
autoloading is possible on those systems.
* Based on the above, supporting back as far as possible is good, but
IMHO PHP 5.3+ is acceptable. PHP 5.2 support here isn't critical. PHP 5.3
may still be able to disable `ext/hash` though, but once again, I'm fine
not supporting that.
Testing against `https://wordpress.org/wordpress-latest.zip` with
signature verification based on [attachment:39309.2.patch] & comment 5
* Under PHP 7.0 local VM performance was ~240ms per sign, ~255ms per
* Under PHP 5.3.3 local VM performance was ~380ms per sign, ~330ms per
* PHP 5.3.3 with CPU throttled to 20%, performance suffered obviously
with ~830ms per sign, ~950ms per verify.
Not super-fast, but not out of the question. I'm not sure why signing was
slower than verifying in the initial PHP 5.3.3 run, I've run it over 50
iterations twice on each setup with similar results.
* It should be expected that signature verification may take up to a
second in the wild, hosts are likely going to be under increased load
during updates and that will affect signature time. Not all WordPress
sites are hosted with adequate hardware resources.
* It should also be expected that core would have a minimum of 2 valid
signing keys authorised, to allow for secure revocation and replacement.
* For example; primary and secondary backup, OR one primary for Core,
one primary for plugins/themes/translations/etc, single secondary to
authorise key replacements, OR something else that made sense.
* If multiple "primary" keys are possible, a way to differentiate which
keys are options for which packages would be needed.
* Secondary keys would add a overhead for failed verifications, but
failed signature verification appears to be rather fast, as it aborts much
* ''This does not affect initial implementation of patches, nor is an
immediate blocker to be solved, it would require discussion on the w.org
systems side to determine what route we would take here.''
A few more random thoughts and notes:
* All signatures should be transparent to a user, a typical user should
never be prompted to enter hashes, nor see them.
* 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.
* 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.
* [attachment:39309.2.patch] doesn't actually use the libsodium
extension, correct? due to it's reliance upon
* @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?
Finally; Marking this as `Future Release` as it's accepted we'll add
something here, but no firm timeline for completion at this point in time.
Ticket URL: <https://core.trac.wordpress.org/ticket/39309#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac