[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:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  Security                             |     Version:  3.4
 Severity:  major                                |  Resolution:
 Keywords:  2nd-opinion has-patch needs-testing  |     Focuses:
  dev-feedback                                   |
-------------------------------------------------+-------------------------

Comment (by mbijon):

 Regarding Base64/basE91...

 The truncation of passwords to 72-chars happens automatically in
 `password_hash()`. Using baseXY methods does not increase the supported
 password length and does not increase the keyspace.

 As for increasing info density, I'm not sure of the point in this
 situation @paragoninitiativeenterprises. Using `base64_encode(
 password_hash('', '' true) )` could be un-done with a one-time operation
 on a leaked DB. then you'd be right back to rainbow table attacks.

 ----

 <red herring alert...>

 @paragoninitiativeenterprises:
 Did you mean to suggest `password_hash( base64_encode( $password ) )`?

 I think that's not really the right debate for a thread aiming to upgrade
 from MD5 ... but it also runs against the recommendations in NIST
 800-63-3:

   Pre-encoding does appear to offer some marginal amount of improvement on
 bad passwords... First, by converting "abc123" -> "YWJjMTIz". But password
 complexity is largely ineffective against modern rainbow tables. Longer
 passwords (ideally passphrases) are a strong recommendation instead of
 complexity.

   Base64 does offer a 4/3rds stretching effect on passwords.
 Unfortunately, the stretching effect of base64 means that password_hash's
 built-in truncation will limit passwords to 54 characters. Anything above
 that length would be discarded. This means a reduced keyspace and
 decreases overall or network-effect security. For example:
   * A 54-char input will base74 to 72-chars. Then `password_hash` would
 use the whole 72-chars
   * A 55-char input would base64 to 74-chars and `password_hash` would
 truncate that to 72-chars

 A better option (once password_hash() is in-use of course) would be to
 have a "sliding salt" that ensured a minimum-length of 72-chars, ie:
 `password_hash( $password . $salt_72_char, PASSWORD_DEFAULT )`. Even a
 short password would get salted to max-out the 72-char limit in
 password_hash.

 This strategy would allow `password_verify()` to STILL WORK, and also
 ensure the larger 14-16 char MD5 rainbow tables do nothing if your DB ever
 is leaked.

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