[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):

 I'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.

 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.

 > 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.

 This is the only part I'm not strictly sure if its an advantage though
 (not the `password_verify`part but the fact that someone could take or
 intercept the sent hash and use it for anything in particular). After all
 the only difference here is that the `post_password` is constantly being
 hashed in `post_password_required` and compared towards the hash of the
 cookie session for the editors thing that john mentioned. But still I
 think its more about the fact that `phpass` is a little outdated vs newer
 alternatives than the fact that could be broken anytime soon.

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