CONCEPT Cited by 1 source

MySQL `caching_sha2_password` authentication¶

caching_sha2_password is the default authentication plugin in MySQL 8.0+, replacing the long-standing mysql_native_password plugin that was the default on MySQL 5.7 and earlier. The change is the auth-layer backward-compatibility break of the 5.7 → 8.0 upgrade: old clients that speak only mysql_native_password cannot authenticate against an 8.0 server's default user accounts until either the client library or the account's plugin declaration is updated.

The two plugins¶

Plugin	MySQL default	Security properties
`mysql_native_password`	5.7 and prior	SHA-1 based challenge-response. Deprecated but still shipped.
`caching_sha2_password`	8.0+	SHA-256 based challenge-response with server-side cache for perf.

The plugin determines how the client proves knowledge of the password to the server at connection-handshake time. It does not change how the password is stored at rest (both plugins hash; SHA-256 is just a stronger hash).

Why MySQL changed the default¶

SHA-1's cryptographic weakening made SHA-1-based protocols progressively harder to defend; SHA-256 is the modern default. The caching_ prefix refers to a server-side cache of successfully-authenticated hashes, added so that SHA-256's higher per-authentication cost doesn't regress connection-establishment latency on repeat connections.

The backward-compatibility break¶

A MySQL 5.7 server with default config produces user accounts whose plugin is mysql_native_password. When such a server is upgraded in-place to MySQL 8.0, existing accounts keep their mysql_native_password plugin declaration — existing clients keep working. But new accounts created on the upgraded server default to caching_sha2_password, and client libraries built against a connector that predates MySQL 8.0's release (2018) may not ship support for the new handshake.

The symptom: a client library running mysql_connect() gets:

ERROR 2059 (HY000): Authentication plugin
'caching_sha2_password' cannot be loaded

Or, if the client library speaks an old protocol version, a mysterious handshake-phase disconnect.

(Source: sources/2026-04-21-planetscale-how-to-upgrade-from-mysql-57-to-80.)

Three mitigation paths¶

From the post: "Legacy accounts that use the old authentication plugin must be converted to the new one using the ALTER USER statement. It is also important to update any client applications that interact with the database to support the new authentication mechanism."

Option 1 — Upgrade the client libraries. Any MySQL connector released in 2018+ should speak caching_sha2_password. This is the forward-compatible path — it works regardless of which plugin the server uses.

Option 2 — Convert legacy accounts to the new plugin via ALTER USER. Done on the server side after the client libraries are upgraded:

ALTER USER 'appuser'@'%'
    IDENTIFIED WITH caching_sha2_password BY '<password>';

This rotates the stored hash to SHA-256 and marks the account as caching_sha2_password on the server.

Option 3 — Pin new accounts back to mysql_native_password. Useful as a transitional workaround if not all clients can be updated in one step:

CREATE USER 'legacyapp'@'%'
    IDENTIFIED WITH mysql_native_password BY '<password>';

Or set it server-wide as a config default:

[mysqld]
default_authentication_plugin=mysql_native_password

This is a stopgap — mysql_native_password is deprecated and scheduled for eventual removal.

Operational sequencing¶

Because upgrading all clients atomically is usually impossible, the upgrade sequence is:

Audit every client library for caching_sha2_password support.
Upgrade client libraries first, verify no regression.
Upgrade the server.
Rotate account plugins via ALTER USER to clear the mysql_native_password deprecation.

Stopping at step 1 or 2 is acceptable — the server can be upgraded to 8.0 with accounts remaining on mysql_native_password. The cost is deferred technical debt.

Caveat — the TLS requirement¶

caching_sha2_password requires either a TLS-encrypted connection or an RSA-key-based password exchange for the initial authentication (before the server cache is populated). Plain-TCP connections without TLS fail authentication with caching_sha2_password even with a compatible client. This is a second hidden compatibility axis — upgrading the auth plugin can force a TLS-required posture that infrastructure may not be ready for.

Classification¶

This is a canonical backward-compatibility hazard at the auth-protocol altitude, sibling to the charset default flip and reserved-word expansion on the MySQL 5.7 → 8.0 upgrade axis. Unlike charset (affects storage + queries) or reserved words (affects DDL parsing), this hazard affects connection establishment — the failure mode is at the wire-protocol handshake, not in query execution.

Seen in¶

sources/2026-04-21-planetscale-how-to-upgrade-from-mysql-57-to-80 — canonical wiki introduction of caching_sha2_password as the MySQL-8 default auth-plugin flip. JD Lien's upgrade checklist names it as the third of five orthogonal breaking-change classes, alongside charset, deprecated data types, SQL mode, and reserved words. Canonical mitigation recipe: "Legacy accounts that use the old authentication plugin must be converted to the new one using the ALTER USER statement."

MySQL caching_sha2_password authentication¶