10up-experience icon indicating copy to clipboard operation
10up-experience copied to clipboard

Clarify password-protected content warning in admin

Open benlk opened this issue 1 year ago • 1 comments

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:

  • 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

  • [X] I agree to follow this project's Code of Conduct

benlk avatar Oct 18 '23 14:10 benlk

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.

benlk avatar Oct 18 '23 14:10 benlk