[10.x] Increase bcrypt rounds to 12

[valorin]

PHP is increasing the default bcrypt cost to either 11 or 12 to keep up with increases in computing, so we should do the same within Laravel. The current default of 10 was set in PHP 11 years ago, which is no longer a suitable default.

12 appears to be the sweet spot between performance and security, as confirmed by a member of the Hashcat team. Symfony uses a cost of 13, however that may be too high for some servers.

Due to the way hashing works, there are no backwards compatibility issues - older passwords with lower rounds will still be handled properly, and code that automatically rehashes passwords will upgrade them over time. It's also worth pointing out that since rounds are defined in config/hashing.php, existing projects won't automatically get the new rounds cost and thus won't have any performance impacts. The RFC contains hash calculation timings if you'd like more information on the impacts.

Increasing rounds to 12 in config/hashing.php should be a recommended upgrade step for Laravel 11 (and possibly added to the guide for 10?).

Framework PR: laravel/framework#48494

[GrahamCampbell]

Probably we should change the default from bycrypt to argon2id in laravel 11.

[valorin]

PHP recently discussed changing the default to Argon2, but were advised that Argon2 is not appropriate for use within web applications. See: https://externals.io/message/120993 & https://twitter.com/TerahashCorp/status/1155119064248913920

[roycewilliams]

Concur with @valorin here. To summarize, even some of the PHC judges acknowledge that, in order to achieve auth speeds in alignment with UX tolerance studies (500ms to 1 second of auth delay per user), both the Argon2 family and scrypt have to be tuned "downward" so much that they end up being less resistant to offline attack than bcrypt at equivalent auth speeds(!)

Paradoxically, for the multi-user interactive login use case, and the "resist offline attack of multiple hashes" case, properly tuned bcrypt remains superior.

In other words ... the simplest, most backward-compatible option (increasing bcrypt cost) is also the most secure option at this time.

[roycewilliams]

One more note: between CPU speed increases (for both attacker and defender), and the rise of GPU password cracking, in the decade since PHP's default bcrypt work factor was set to 10 ... it would have been better to have moved to bcrypt cost 11 in 2017 or so. A bcrypt cost of 12 is the more defensible choice in 2023.