Initial Connection Security (adding a site)
MainWP 5.3 introduces new features to enhance the security of the process when adding a Child Site to your Dashboard. These updates address both user feedback and evolving security standards, ensuring an even safer initial connection.
Password Authentication
By default, MainWP now includes an option to use the WordPress administrator’s password for authentication during the initial connection. This feature, enabled by default, adds an extra layer of security by allowing only verified administrators to authorize the setup process.
The password is used solely for verification during the setup process. It is not stored on the Dashboard or sent to MainWP.com.
Once the connection is established, the Dashboard generates an OpenSSL key pair for future encrypted communications, eliminating the need for password reuse.
Per-User Configuration: Password authentication is tied to individual WordPress admin accounts. If one admin disables password authentication, it does not affect other admins on the same Child Site. Each admin must disable it separately if desired, preserving security for other users.
For added security and auditability, consider creating a dedicated “MainWP Admin” account for this purpose. This account can be easily monitored or modified if needed.
Unique Security ID
An optional Unique Security ID provides an additional layer of authentication during the setup process. When enabled, this ID must match for the connection to succeed. This feature is particularly valuable for sites requiring stricter access controls.
Connection Timeout
The MainWP Child plugin now features a connection timeout to minimize exposure. After activation, the plugin will remain active for a limited time (specified in minutes) if no connection is established. Once this period expires, the plugin automatically deactivates itself, ensuring that idle plugins do not remain accessible.
Site Connection Management
A new Disconnect Site option allows users to clear all connection data for a Child Site directly from the Dashboard. This feature is useful for decommissioning sites, re-establishing secure connections, or troubleshooting setup issues.
Connection Security (after the site is added)
All communication between MainWP Dashboard and Child Sites is performed over the OpenSSL encrypted connection.
When MainWP Dashboard connects to a child site for the first time, it generates Public and Private key pairs (2048 bits length) by using the openssl_pkey_new() OpenSSL function. The public key gets saved on the child site and on the MainWP Dashboard, and the Private key gets encrypted and saved only on the MainWP Dashboard.
When communicating with the child site, MainWP will use the openssl_sign() function to generate the request signature. openssl_sign() computes a signature for the specified data by generating a cryptographic digital signature using the private key associated with priv_key_id.
When the request gets to the child site, the MainWP Child plugin will use the openssl_verify() function to authenticate the request. openssl_verify() verifies that the signature is correct for the specified data using the public key associated with pub_key_id. This must be the public key corresponding to the private key used for signing.
To communicate with a child site, the MainWP Dashboard plugin will execute an HTTPS request using cURL.
For example, basic sync (HTTPS) request contains three basic parameters as required:
Username – Administrator user username that is used for establishing a secure connection between MainWP Dashboard and Child Sites
Function – Name of the function to execute on Child Site
MainWP Signature – Authentication signature required for the HTTPS request authentication. If the Auth key doesn’t match, the HTTPS request won’t be executed.
Here is an example of a basic sync request:
https://childsite.com/wp-admin/admin-ajax.php?user=demouser&function=stats&mainwpsignature=dgTOIUbQyBWvCh0pNhnwmxmHoeayfg34PCBJxhszRFASTfFwRqrJaMk%2F%2FLJSQvDKlQ8A2Wf4cwowG1PaL9f%2FdG2DzBDucu9GRMi%2Bq18iauk9JgXR%2FaPd9jSvAzoxc5GSJrDmBOLLZEFe8M0VWJ2VVdRm3Bq%2BPyD4p4AtB0%2BphMRXnP99PVMXkwMJKVnf1OT7jjAYATBuSkkccsZ5bRyZDHuJw78L%2BsGhhvKxoz0IwRNqnV4e09LuPW8CKe6DtyPc9SRD9ojc69NQxZBDa2Zyr%2FvH%2BypFvFxsw0Eh0Tnoiq9giVUSDNlEtR7RLJbtGOEKr4%2BBMtmIb1M9ODy72N9%2Ftg%3D%3D
In that sync request, the mainwpsignature is used as a form of authentication and after that, the data is passed from the Dashboard to the Child site.
But what happens before a request is sent to the child site?
When certain functions that send requests to child sites are triggered, before the request ever gets sent to the child site, MainWP Dashboard will use escape all parameter values in order to make sure that there is no malicious code injected in the request. If we take the Go to WP Admin feature, we can see that the name and value attributes are escaped by using the esc_attr() functions.
How does this make your setup more secure?
In normal use, all values that would be used in requests are generated by MainWP Dashboard, and there are no security issues, but if someone would trick you to click a link that looks like a request from your MainWP Dashboard (with the assumption that the attacker knows your dashboard URL) if the attributes would not be escaped, potentially malicious code would be passed to child site where it could be executed. But since MainWP Dashboard will escape attributes, potentially malicious code that was placed by the attacker will be escaped and harmless for the child site.
So, how the whole system works?
First, MainWP Dashboard will prepare requests by escaping all attributes, making sure there is nothing harmful sent to child sites.
Once this is done, an HTTP request that includes the “MainWP Signature” unique for your Dashboard and the Child site, along with other parameters, will be sent to the Child Site.
When the request finally hits the child site, MainWP Child will detect the MainWP Signature to make sure that the request is really sent from your MainWP Dashboard to authorize the request.