Reassess the best way to store, hash, and check post passwords

[johnbillion]

Previously:

• #3316
• #19797

Post passwords are a curiosity. They are stored in plain text in the posts.post_password field (so they can be displayed to an editorial user on the post editing screen). When a user visits a password-protected post and enters a password, the entered value gets hashed with phpass and the hash is stored in the wp-postpass cookie in their browser. Validation happens server-side by validating the user-provided hash against the plain text password in the database.

This is backwards. Storing a password in plain text in the database and then providing its hash via a cookie means that the hash is user-controllable. A malicious actor could use this to exploit a weakness in the hash checking process that they would not otherwise be able to do by providing only the plain text password. There is no known such weakness in the phpass library used in core, but this does prevent us from switching to password_verify() for post passwords where the algorithm, cost, and hash would all be user-controlled.

Given that a post password is actually a shared secret and its hash is not tied to a session or a user, stealing the cookie achieves the same thing as discovering the plain text post password. Hashing the cookie doesn't protect against XSS stealing the cookie for the same reason.

So what is the threat model for the current post password storage, hashing, and checking mechanism? Password re-use is one potential threat, what about others? Let's assess and determine if there is a better mechanism to use for post passwords that doesn't allow the hash to be user-controlled.

Perhaps an access token system can be implemented instead of password hashing. Ideas welcome.