Make WordPress Core

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


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

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #62954, comment 2

    initial v1  
    11I've been giving this a second thought, and I think that the performance issues could be solved if, instead of storing user hashes in the posts table as I originally thought, they are stored in the users table. Now wondering if it would be better to store a single record with all the post key pairs, or separate records. Probably separate records with and the meta key being the name and the post like `_tokenized_access_token_{post_id}` and the value being the hash.
    22
    3 For the BC part, the fact that the passwords are being stored in plain text its obviously an advantage to implement anything because we can receive the password in plain text, check it in plain text without having to deal with nothing in particular during the first check, after that the tokenized hashes will do the thing. Anyway, with a XSS the cookie could be stolen anyway. AFAIK, I'm not too savvy on security topics, but anything-access-token could be stolen, including JWT are prone to XSS attacks. I feel that this falls more into `Security` than `Post/Posts Types` component, by the way.
     3For the BC part, the fact that the passwords are being stored in plain text its obviously an advantage to implement anything because we can receive the password in plain text, check it in plain text without having to deal with nothing in particular during the first check, after that the tokenized hashes will do the thing. Anyway, with a XSS the cookie could be stolen anyway. AFAIK, I'm not too savvy on security topics, but anything-access-token could be stolen and is prone to XSS attacks. I feel that this falls more into `Security` than `Post/Posts Types` component, by the way.
    44
    55> 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.