What it means
Every MySQL account has an authentication plugin, the method used to check its password.
mysql_native_password, the method from before MySQL 8, was deprecated in 8.0.34, is disabled
by default in MySQL 8.4, and is removed in 9.0. Its replacement, caching_sha2_password, has been
the default for new accounts since 8.0.
Error 1524 means a statement or a sign-in needed a plugin the server hasn’t loaded:
- Signing in to an account that still uses
mysql_native_password, typically after upgrading to 8.4. The server refuses before it even checks the password, so a wrong password gets the same 1524. CREATE USER … IDENTIFIED WITH mysql_native_passwordor the sameALTER USER, often from an old setup script or from advice written for older clients.
MariaDB is different: mysql_native_password is still its usual method, and MariaDB 11.4 has it
loaded.
Common causes
- An upgrade from MySQL 8.0 to 8.4 (or a new 8.4 server restored from an 8.0 dump) with
accounts created as
mysql_native_password. - Accounts set to
mysql_native_passwordon purpose in the past, for clients that couldn’t usecaching_sha2_password. - A Docker Compose file or setup script that runs
IDENTIFIED WITH mysql_native_password, or starts the server with the old--default-authentication-plugin=mysql_native_passwordoption, which MySQL 8.4 no longer has.
How to fix it
Find the accounts that use it
As an administrator:
SELECT user, host, plugin FROM mysql.user WHERE plugin = 'mysql_native_password';
Move them to caching_sha2_password
Give each one its password again with the new method:
ALTER USER 'app'@'%' IDENTIFIED WITH caching_sha2_password BY '<password>';
You need the password (or a new one), since the old hash can’t be converted. Clients from the last
several years support caching_sha2_password; older ones fail with
“Authentication plugin cannot be loaded”,
and should be updated.
caching_sha2_password sends the password over TLS or encrypted with the server’s RSA key, so a
client connecting without TLS may need its option for fetching the key (for the mysql client,
--get-server-public-key) the first time an account signs in after a restart.
Or turn the plugin back on, for now
In the server’s configuration, then restart:
[mysqld]
mysql_native_password = ON
That gives you time to move accounts, but the plugin is gone in MySQL 9.0, and the server logs a deprecation warning when an account uses it.
In setup scripts
Remove IDENTIFIED WITH mysql_native_password and let new accounts use the default:
CREATE USER 'app'@'%' IDENTIFIED BY '<password>';
Reproduce it
On the shared MySQL 8.4.11 server, as root:
CREATE USER 'seo_err_native'@'%' IDENTIFIED WITH mysql_native_password BY '<password>';
ALTER USER 'seo_err_sha2'@'%' IDENTIFIED WITH mysql_native_password BY '<password>';
ERROR 1524 (HY000): Plugin 'mysql_native_password' is not loaded
ERROR 1524 (HY000): Plugin 'mysql_native_password' is not loaded
information_schema.plugins listed mysql_native_password as DISABLED.
For the upgrade case, a temporary MySQL 8.4.11 container was started with
--mysql-native-password=ON, an account seo_legacy was created with the plugin, and it signed in
(the server logged 'mysql_native_password' is deprecated and will be removed in a future release).
After restarting the server on the same data without the option, signing in failed, with the right
password and with a wrong one:
mysql -h127.0.0.1 -useo_legacy -p -e 'select current_user()'
ERROR 1524 (HY000): Plugin 'mysql_native_password' is not loaded
As root through the socket, ALTER USER 'seo_legacy'@'%' IDENTIFIED WITH caching_sha2_password BY '<password>' worked, and the account signed in again. The container and its volume were removed
afterwards.
On the shared MariaDB 11.4.13 server, every account, root included, uses mysql_native_password.
In Inlet
Inlet’s MySQL driver signs in with caching_sha2_password, with or without TLS, so moving an account
off mysql_native_password doesn’t stop Inlet connecting. If a sign-in fails, the connection window
shows the server’s message and links to this page.