[wp-trac] [WordPress Trac] #62954: Reassess the best way to store, hash, and check post passwords

[WordPress Trac]

#62954: Reassess the best way to store, hash, and check post passwords
-------------------------------+-----------------------------
 Reporter:  johnbillion        |      Owner:  (none)
     Type:  enhancement        |     Status:  new
 Priority:  normal             |  Milestone:  Awaiting Review
Component:  Posts, Post Types  |    Version:
 Severity:  normal             |   Keywords:  2nd-opinion
  Focuses:                     |
-------------------------------+-----------------------------
 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.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/62954>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform