Increase password hashing iterations

Created on 2 February 2020, over 4 years ago
Updated 25 January 2023, over 1 year ago

Problem/Motivation

There is an @todo note in core.services.yml to increase the number of iterations used when hashing passwords for every Drupal core release.

We last increased this value almost a decade ago in #1203852: Increase hashing iterations for D7 and D8. β†’ . It was noted at the time that we should do this "every version" assuming we are on 18-24 month release cycles, but also really this is all about execution time, and single core CPU clocks have still not really increased since then.

Proposed resolution

Either increase the password iterations log2 value from 16 (to 17 or 18), or remove the todo.

Remaining tasks

Benchmark how long a password hash takes on a modern CPU to decide whether we should change this or not.

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

πŸ“Œ Task
Status

Closed: duplicate

Version

10.1 ✨

Component
BaseΒ  β†’

Last updated 44 minutes ago

Created by

πŸ‡¬πŸ‡§United Kingdom longwave UK

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡ΊπŸ‡ΈUnited States mfb San Francisco

    I did some quick benchmarking to see where things are at and found that password hashing is approximately twice as fast on a newish laptop compared to a ~10-year-old, budget-grade server. And the laptop was actually running around a third of its max clock rate - maxing out one core was not enough to get it to switch to a higher clock rate.

    Based on this, I'd say increasing to 17 iterations is very reasonable - it's a little slow on old hardware but still under 100 milliseconds. And those hosting on better hardware could reasonably go higher than 17. Of course, I'd hope that phpass will be phased out any day now in the related issue, i.e. fingers crossed this issue doesn't need to be worked on?

    Newish laptop (AMD Ryzen 7 PRO 6850U):

    ./vendor/bin/drush scr test.php
    16 => 20 milliseconds
    17 => 41 milliseconds
    18 => 82 milliseconds
    19 => 163 milliseconds
    20 => 327 milliseconds
    21 => 654 milliseconds
    22 => 1312 milliseconds
    23 => 2628 milliseconds
    24 => 5259 milliseconds

    Old server (Intel Xeon E3-1265L v3):

    ./vendor/bin/drush scr test.php
    16 => 44 milliseconds
    17 => 87 milliseconds
    18 => 175 milliseconds
    19 => 349 milliseconds
    20 => 698 milliseconds
    21 => 1397 milliseconds
    22 => 2797 milliseconds
    23 => 5593 milliseconds
    24 => 11177 milliseconds

    Test script is as follows:

    $start = microtime(TRUE);
    $end = microtime(TRUE);
    $iterations = range(16, 24);
    foreach ($iterations as $countLog2) {
      $password = new Drupal\Core\Password\PhpassHashedPassword($countLog2);
      $start = microtime(TRUE);
      $password->hash('lololololololololol');
      $end = microtime(TRUE);
      echo $countLog2, ' => ', round(1000 * ($end - $start)), ' milliseconds', PHP_EOL;
    } 
  • πŸ‡ΊπŸ‡ΈUnited States mfb San Francisco
  • Status changed to Needs review over 1 year ago
  • πŸ‡ΊπŸ‡ΈUnited States mfb San Francisco

    I think this issue should be closed in favor of πŸ“Œ Replace custom password hashing library with PHP password_hash() Fixed - but setting to needs review until that happens

  • Status changed to Closed: duplicate over 1 year ago
  • πŸ‡ΊπŸ‡ΈUnited States smustgrave

    Do agree this can be closed in favor of πŸ“Œ Replace custom password hashing library with PHP password_hash() Fixed that one seems like a closer. I'll move over credit.

Production build 0.71.5 2024