10up / 10up-experience

The 10up Experience plugin configures WordPress to better protect and inform clients, aligned to 10up’s best practices.
GNU General Public License v2.0
129 stars 27 forks source link

Clarify password-protected content warning in admin #141

Open benlk opened 11 months ago

benlk commented 11 months ago

Is your enhancement related to a problem? Please describe.

Screenshot 2023-10-12 at 15 13 27

https://github.com/10up/10up-experience/blob/14c8794c9c9b34764fa379c45d9112045db03ff4/includes/classes/PostPasswords/PostPasswords.php#L67

Enables password protected content. WordPress default password protected post functionality is insecure and does not work with page caching.

This notice is vague:

I'm filing this issue because I couldn't find those answers in this plugin's documentation, or in the WordPress documentation at https://wordpress.org/documentation/article/protect-posts-with-password/ , or in the documentation of the host (WP VIP) for a client project.

Designs

No response

Describe alternatives you've considered

Possible resolutions:

Code of Conduct

benlk commented 11 months ago

I asked VIP, and this is what their support agent said:

Yes, the default post password function included in WordPress works as expected on VIP, as it sets a wp-postpass_{hash} cookie in the user's browser:

https://codex.wordpress.org/Using_Password_Protection#Password_Protected_Posts

The wp-postpass_* is an insecure password stored in plain text in the database. It is meant to be shared with other users, retrievable, and modifiable. Post passwords are not intended to be secure authenticators; for that WordPress has private posts that require full authentication. While the post password is not stored in plain text in the cookie, a hashed version is.

The password-protected content workflow looks like this: WordPress serves the password form Password is submitted via POST to /wp-login.php?action=postpass WordPress talks to the DB and confirms the password matches The wp-login.php page drops a cookie that starts with wp-postpass_, which has a salted version of the post ID and the password, eg. wp-postpass_****=**** The wp-login.php request returns a 302 header which redirects back to the password-protected page The cookie is what validates that they can access the content, and requests with a valid cookie get an x-cache: PASS header for that password-protected page to prevent the content from being cached.