Make WordPress Core

Changes between Initial Version and Version 1 of Ticket #62954, comment 1


Ignore:
Timestamp:
09/07/2025 02:12:29 PM (3 months ago)
Author:
SirLouen
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #62954, comment 1

    initial v1  
    66I'm trying to figure out what would be a good patch for this.
    77
    8 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)
     8For password generation I assume that `password_hash` on the fly is the way to go here.
    99
    1010Handling 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).
     
    1212{{{
    1313$pw = $_POST['post_tokenized_pass'];
    14 $hash = get_post_meta($post->ID, '_hashed_post_password', true);
     14$hash = password_hash(the_post_password());
    1515if ($hash && password_verify($pw, $hash)) {
    1616    $token = bin2hex(random_bytes(24));
     
    2323
    2424So basically, with an access token approach, two potential issues come to my mind:
    25 - BC issues
     25- BC potential issues?
    2626- Potential DB Performance issues
    2727