[wp-trac] [WordPress Trac] #21022: Use bcrypt for password hashing; updating old hashes

[WordPress Trac]

#21022: Use bcrypt for password hashing; updating old hashes
-------------------------------------------------+-------------------------
 Reporter:  th23                                 |       Owner:
                                                 |  johnbillion
     Type:  enhancement                          |      Status:  reopened
 Priority:  normal                               |   Milestone:  6.8
Component:  Security                             |     Version:  3.4
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-testing has-unit-    |     Focuses:
  tests has-dev-note                             |
-------------------------------------------------+-------------------------
Changes (by dd32):

 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 re-opening, for visibility.

 For sites that run with `DO_NOT_UPGRADE_GLOBAL_TABLES` defined, which are
 generally larger sites with many users, they may be running with a
 severely outdated DB schema which causes the changes in [59828] to be
 truncated in the database.

 For example, 9 years ago, [35638] changed the field length for the
 user_pass & user_activation_key from 64/60 to 255char. Thankfully it
 appears these fields had been set to 64/60char since the beginning of time
 (Well, WP time at least).

 It seems like the new bcrypt passwords will fit within the 64char length,
 but the user_activation_key is a different story.

 The value that ends up in this field during password resets is `time() .
 ':' . wp_fast_hash( $key )` which is 84 characters. The last 24char will
 be silently truncated upon insert into the DB causing password reset to
 then fail.
 This likely also affects user registrations, as they use that field too.

 I can personally think of three potential options here:
  1. Maybe fire a warning, devnote it, and expect sites to update their
 schema. A Devnote may be required anyway, to warn that previous password
 reset hashes have been broken.
  1. Detect it was truncated, and store in user_meta
  1. Change wp_fast_hash() to be a shorter key length (48char max to work
 with a time() prefix and 60chars) - base64 gets the hash part down to
 44char compared to 64char with bin2hex, but there's still the '$generic$'
 prefix.

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