[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             |  Resolution:
 Keywords:  2nd-opinion        |     Focuses:
-------------------------------+------------------------------

Comment (by SirLouen):

 Replying to [ticket:62954 johnbillion]:
 > Perhaps an access token system can be implemented instead of password
 hashing. Ideas welcome.

 This makes sense to me. Recently I've been playing around with certain
 tickets referencing troubles with the password protected posts. Probably
 because of a local hashing limitation that it's hard to debug given how
 hard to retrieve is their environment variables.

 I'm trying to figure out what would be a good patch for this.

 For password generation I assume that `password_hash` is the way to go
 here. But I wonder if this could not cause some backwards compatibility
 troubles, on how `post_password` is currently defined and made.
 Considering that this is a flaw, I assume that we thinking on a new
 option, must override any BC limitations, right? (I don't have much
 experience on how this has been approached historically)

 Handling of the password could be in this form (I've picked part of this
 content, like the randomization, from a plugin snippet that does something
 similar).

 {{{
 $pw = $_POST['post_tokenized_pass'];
 $hash = get_post_meta($post->ID, '_hashed_post_password', true);
 if ($hash && password_verify($pw, $hash)) {
     $token = bin2hex(random_bytes(24));
     setcookie('post_token_' . $post->ID, $token, time() + 30 *
 DAY_IN_SECONDS, COOKIEPATH, COOKIE_DOMAIN, is_ssl(), true);
     update_post_meta($post->ID, '_tokenized_access_token', $token);
 }
 }}}

 Which could end up generating a bunch of access tokens in the DB (given
 the structure of the non-indexed WP post-meta database, could be
 inefficient, especially if for some reason the post has a massive activity
 volume, there is no single meta-key that is stored massively for a single
 post). If we could index the users and posts in a 3-column table, this
 would be extremely performant, but we don't have this structure in the DB.

 So basically, with an access token approach, two potential issues come to
 my mind:
 - BC issues
 - Potential DB Performance issues

 Any thoughts?

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