10up/10up-experience

Clarify password-protected content warning in admin

benlk opened this issue · 1 comments

benlk commented

Is your enhancement related to a problem? Please describe.

Screenshot 2023-10-12 at 15 13 27

10up-experience/includes/classes/PostPasswords/PostPasswords.php

Line 67 in 14c8794

<p class="description"><?php esc_html_e( 'Enables password protected content. WordPress default password protected post functionality is insecure and does not work with page caching.', 'tenup' ); ?></p>

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

This notice is vague:

  • What are the security concerns?
  • "Page caching" is implemented in different ways by different hosts, and this warning may not apply to specific hosts or website architectures.

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:

  • expanding this warning on this admin page
  • adding a link to some documentation in this plugin, or elsewhere in 10up's documentation

Code of Conduct

  • I agree to follow this project's Code of Conduct
benlk commented

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.