[wp-trac] [WordPress Trac] #50027: Retire Phpass and use PHP native password hashing

[WordPress Trac]

#50027: Retire Phpass and use PHP native password hashing
-------------------------------------------------+-------------------------
 Reporter:  ayeshrajans                          |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Security                             |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  2nd-opinion needs-unit-tests needs-  |     Focuses:
  patch                                          |
-------------------------------------------------+-------------------------

Comment (by craigfrancis):

 1. As to using a hash like sha256 before using bcrypt (ref 72 character
 limit, and null bytes), an approach used by [https://dropbox.tech/security
 /how-dropbox-securely-stores-your-passwords DropBox] and
 [https://paragonie.com/blog/2016/02/how-safely-store-password-in-2016#why-
 bcrypt ParagonIE], we should be aware of
 [https://www.scottbrady91.com/authentication/beware-of-password-shucking
 Hash/Password Shucking] ([https://www.youtube.com/live/OQD3qDYMyYQ?t=1413
 video]). [[BR]][[BR]]
    i.e. other websites do use fast hashes like sha256, and get
 compromised, so the attacker can take those those hashes and check them
 against these bcrypt hashes, if any work, then their password guessing can
 target the fast hash instead (ignoring/shucking the bcrypt
 part).[[BR]][[BR]]
    But this is just one thing to consider, as many people use same or
 similar passwords on different websites, or simple/well-known passwords
 (e.g. RockYou), the attacker can try those apporaches instead...
 personally, I wouldn't worry about 73+ character passwords (the first bit
 is probably strong enough already), and I'd be tempted to remove null
 bytes so any characters afterwards would still be considered.

 2. [https://wiki.php.net/rfc/bcrypt_cost_2023 PHP 8.4 is changing the
 default bcrypt cost from 10 to 12], this ''might'' be problematic for low
 powered servers, or shared hosting providers. [[BR]][[BR]]
    Imagine getting ~20 logins at a time (a server hosting many websites,
 or maybe someone sends an email to a few thousand customers); with a cost
 of 10, that will slow down requests for every other non-login page, e.g.
 from ~0.09 seconds to ~1.1 seconds, while not good, it's still manageable;
 cost of 11 takes that to ~2.1 seconds; cost of 12 goes to ~4.2 seconds
 (timings from a simple `ab -n 200 -c 20` to call password_hash, and `while
 true; do curl -o /dev/null -s -w '%{time_total}\n'` to time a basic page
 while this is running)... that said, a denial of service **attack** is a
 different consideration (i.e. don't allow hundreds of requests from a
 single source).

 3. Maybe we should also use `normalizer_normalize($password,
 Normalizer::FORM_KD)`, ref [https://www.quora.com/Why-are-high-ANSI-
 characters-not-allowed-in-passwords/answer/Jeffrey-Goldberg UTF
 normalization], and [https://pages.nist.gov/800-63-3/sp800-63b.html
 800-63B, section 5.1.1.2].

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