WP uses md5 with key stretching to hash passwords. This is moderately secure, but using bcrypt instead would be significantly more secure. (Argon2 might be even better, but I have no experience with it, whereas I have been using bcrypt for a couple of years, so I know it works fine.)
WP hasn’t done this because it supports PHP versions lower than 5.5. Since we have already agreed to drop support for versions of PHP below 5.6, we should be in a position to implement this. See PHP: password_hash - Manual
So what’s the current state of password hashing? We’ve used bcrypt on websites we manage for a few years now. There’s now Argon2 (PHP 7.2) and Argon2id (PHP 7.3).
Can we introduce stronger algorithms based on user’s PHP version? If we detect 7.2 and up, we use Argon2. Anything below that would fall back on the current method. As we move forward and drop support for older PHP versions, Argon2 would eventually become the default without the need to check PHP version.
This can be dangerous for people downgrading PHP version. Like: try php 8… password are converted… something is not working well… back to 7 and password are lost. Not a common scenario but…
But I am now wondering whether an approach something like this would be better: Ticket Diff – WordPress Trac (though I’d modify it to make the default use brcypt). Using a filter like that is simple and would allow use of argon2 or other encryption methods for those that wanted to use them.
I would go as far as integrating argon2 into core and allowing users to enable it either with a filter or constant. I don’t know which one would be more appropriate. We could also add PHP version detection and alert if argon2 is enabled. Something like “You have enabled Argon2 password hashing, which is available for PHP 7.2 and up. We detected a change to an unsupported PHP version. Please change PHP to 7.2 or above, otherwise, your passwords will not work and users won’t be able to log in.”
The main thing is adding support for Argon2 to the core and allowing users who want it, like us, to enable it easily.
Sure it’s pluggable, and it’s also possible to use a plugin without plugging that function, but I think it’s good for CP from a branding perspective to provide better security by default.