[wp-trac] [WordPress Trac] #43546: Add to the privacy tools UX a means to export personal data by username or email address

[WordPress Trac]

#43546: Add to the privacy tools UX a means to export personal data by username or
email address
--------------------------------+-----------------------
 Reporter:  allendav            |       Owner:  allendav
     Type:  enhancement         |      Status:  assigned
 Priority:  normal              |   Milestone:  4.9.6
Component:  General             |     Version:  trunk
 Severity:  normal              |  Resolution:
 Keywords:  gdpr needs-testing  |     Focuses:
--------------------------------+-----------------------

Comment (by iandunn):

 Replying to [comment:32 azaozz]:
 > Another alternative would be for the admin to always download the zipped
 export and give it to the user in some other way, either email it or share
 it (dropbox, google drive, etc.). Doing this will require more "handling"
 from the admin but will remove all of the above security concerns

 I'm a little leery of shifting the burden from WP to the admin. If the
 admin shares the file via Dropbox, Drive, etc, it seems like they'd most
 likely use an "unlisted" URL, which is essentially the same thing that
 we're doing, except that it won't be automatically deleted after a few
 days.

 If it's an email attachment, then that removes the chance of an
 unauthorized download, but it won't work for attachments larger than ~10
 MB in many cases. It sounded like we may start adding Media Library
 uploads to the export, so that would be problematic.

 Even if we provide a downloadable link, the admin does still always have
 the option of doing what you suggested, though, since we already provide a
 way for them to download the data and then remove the file manually. And
 of course plugins can be written to provide additional alternatives.

 ----

 > Another option we should probably consider is password protecting the
 zip archive

 It seems like adding a password would mainly protect against attempts to
 brute force the URL, right? We'd have to email the password to the user
 along with the link to the file, so a compromised email would also
 compromise the password.

 I think we may already have a reasonable amount of protection against
 brute force, though. For an attacker to succeed, they'll need to:

 1. Know the email address of the target.
 1. Know the 3-day time window when the download will be available.
 1. Brute force a `62^32` search space against a remote network.

 For a worst-case scenario, let's assume the attacker has a large botnet,
 there's no DDoS monitoring, and the attacker is able to achieve !#1 and
 !#2 without much trouble (maybe by initiating a request to pique the
 target's curiosity, so that the target will confirm it, even though they
 didn't request it).

 To calculate the amount of time it'd take to brute force:

 * Alphabet size: 26 lowercase alpha + 26 uppercase alpha + 10 digits = 62
 characters
 * Key length = 32 characters
 * Number of possible values = 62^32
 * Number of guesses per second will vary wildly depending on the target,
 but erring on the side of paranoia, and taking Moore's law into account,
 let's say `150,000`.
 * On average, you only have to search half the space before finding a
 match

 `150000 * 62^32 / 2` = `1.704493413 * 10^62` seconds = `5.404913158 *
 10^54` years =
 `5,404,913,150,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000`
 years

 Somebody definitely needs to double check all of those assumptions and
 calculations, but if I'm right, then it doesn't seem like we need any
 extra protection against a brute force attack.

 If there are some cases that desire password protection, it seems like
 it'd be possible for a plugin to cobble together something that'd work for
 a significant number of users, but not all. e.g., `ZipArchive` AES
 encryption in PHP 7.2 plus multiple fallbacks for older versions, like
 `DotNetZip` on Windows, and `system( 'zip -P' )` calls on Linux. We could
 add an action after the file is written to disk, so that a plugin can
 immediately replace it w/ a encrypted version.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/43546#comment:34>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform