Strengthening caching_sha2_password: Adding PBKDF2-SHA512 Support

MySQL is extending caching_sha2_password to support PBKDF2 with SHA-512 as a new password storage format.

This is a meaningful step forward for password security because it strengthens stored password transformations without requiring a new authentication plugin, without breaking clients, and without forcing an all-at-once migration. Existing accounts continue to work, new passwords can use the stronger format, and administrators get runtime controls to guide or enforce adoption.

That is the core value of this change: stronger password storage, minimal disruption, and a clean migration path.

In short, this is a security upgrade designed to be both stronger and deployable.

Why this change

Password storage needs to evolve with cryptographic expectations. As long-term resilience becomes more important, including preparation for post-quantum security scenarios, using larger and stronger password transformations is a sensible step.

Until now, caching_sha2_password has relied on CRYPT5 with SHA-256 for stored password transformations. With this enhancement, MySQL adds support for PBKDF2-SHA512, giving deployments a stronger storage option while preserving the authentication flow.

What changes in caching_sha2_password

First, the plugin will support two password storage formats:

• CRYPT5 with SHA-256 for existing behavior
• PBKDF2 with SHA-512 for stronger password transformation

Administrators can dynamically choose the format to be used for newly created or reset passwords.

Second, MySQL adds runtime controls that makes it possible to enforce the password storage format. When enforcement is enabled, accounts stored in a different format can still log in, but they are forced to change their password so it is rewritten using the preferred format.

Third, related password storage configuration becomes more consistent. The existing option to control digest rounds is being made dynamic, so it aligns with the new runtime-configurable storage settings.

The following sections take a closer look at each of these changes and explain how they work in practice.

Runtime control over password storage format

A new global dynamic variable controls which format is used when passwords are created or reset:

--caching_sha2_password_storage_format

Because this setting is dynamic, administrators can change it at runtime. Any later CREATE USER or ALTER USER operation will use whatever format is preferred at that moment.

This makes rollout straightforward. Teams can move to PBKDF2 gradually, on their own schedule, without service interruption or plugin changes.

Backward compatibility is built in

A critical part of the design is that verification relies on the stored password format, not the currently preferred one.

That means if an account was created using the older format, it still authenticates normally even after the server preference changes. New policy affects newly set passwords, not existing ones retroactively.

This is exactly what a safe migration path should look like: forward movement without accidental breakage.

Optional enforcement for migration

Preference is useful, but some deployments want stronger policy controls. For that, MySQL adds another global dynamic variable:

--caching_sha2_password_enforce_storage_format

When enforcement is off, accounts using non-default formats continue to work normally. Their storage format changes only when the password is changed next.

When enforcement is on, users with a non-preferred storage format can still authenticate, but they are immediately forced to change their password. That password change moves them onto the preferred format.

This is a smart compromise. It avoids lockouts while still pushing the system toward policy convergence.

Authentication cache behaviour

When --caching_sha2_password_enforce_storage_format changes at runtime, the fast-authentication cache is cleared. That ensures the new policy takes effect consistently.

Also, when enforcement is enabled and a user logs in with a password stored in a non-preferred format, that password is not cached for fast authentication. This prevents old-format credentials from continuing to benefit from cached logins while the account is meant to be rotated.

Accounts with dual passwords

For dual-password accounts, the enforcement decision is based on the password actually used during login.

Useful consistency improvement

As part of this work, --caching_sha2_password_digest_rounds becomes dynamic as well.

This aligns it with the other storage-format related settings and makes runtime administration more consistent.

Replication and rollout considerations

Replication behavior remains unchanged. If a password hash is generated on the primary in a specific format, that same representation is replicated to secondaries and replicas.

Operationally, three points matter:

• secondaries and replicas should be upgraded before the primary
• enforcement settings should be kept consistent across nodes
• mismatched enforcement settings can produce inconsistent user experience across the topology

So the feature fits naturally into existing replication semantics, but coordinated rollout still matters.

X Plugin support

The change also extends to X Plugin authentication, which will be updated to verify passwords stored in PBKDF2 format.

That ensures this is not a partial enhancement limited to one authentication path. PBKDF2 support becomes part of the broader MySQL authentication surface.

Under the hood: Developer-facing details

Beyond the operational benefits, this change also introduces a few implementation details that are especially relevant to developers working on authentication, plugin integration, or protocol-level behavior.

PBKDF2 storage representation

The new PBKDF2-based password format is serialized in a way that allows the server to identify the transformation directly from the stored value and verify it accordingly.

Its serialized form has these characteristics:

• digest type identifier: B
• iteration count: 3-digit hex (multiplied with 1000 to derive the actual count)
• salt length: CRYPT_SALT_LENGTH
• digest stored in base64 form

From an implementation standpoint, the important point is that verification remains format-aware. The server does not reinterpret stored password data based on current policy; it uses the format encoded in the stored transformation itself.

Authentication plugin ABI support

To support storage-format enforcement without rejecting otherwise valid credentials, the authentication plugin ABI is extended with a new return code:

CR_OK_FORCE_PASSWORD_CHANGE

When returned, the connection’s password-expired attribute is marked as true in the security context, which forces the user to change the password immediately after login.

Within caching_sha2_password, this return code is used when both of the following are true:

• --caching_sha2_password_enforce_storage_format=1
• the account’s stored password format (password being used in case of dual-password) does not match --caching_sha2_password_storage_format

This gives the authentication layer a clean way to distinguish between successful authentication and successful authentication that must be followed by password rotation.

Conclusion

Adding PBKDF2-SHA512 support to caching_sha2_password gives MySQL a stronger and more future-ready password storage option without disrupting applications or users. It improves cryptographic posture, keeps deployment friction low, and provides a clear path from legacy storage to stronger password handling.

For administrators, that means better security with less migration friction. For users, it means the transition can happen with minimal disruption. That combination is exactly what makes this change valuable. If you are using caching_sha2_password, this is a good time to evaluate PBKDF2-SHA512 in your environment and start planning a gradual move toward the stronger storage format.

As always, a big THANK YOU for using MySQL.