user.setPassword(password) allocates a fresh Password, and only the next line fills in the secondary. In between there's a window where the account has the new primary and no secondary, so a client still using the old password gets rejected — during exactly the rotation this feature exists to make seamless.

matchUserPassword also calls user.getPassword() twice, and the compare loop in checkPasswordInternal runs after rlock is released, so those two reads can land on different Password objects.

Cheap fix, User already has a setPassword(Password) overload:

Password newPwd = new Password(password);
newPwd.setSecondaryPassword(carried);
user.setPassword(newPwd);

and hoisting Password pwd = user.getPassword() into a local in matchUserPassword makes that a consistent snapshot.

Done as suggested — the change now builds the full Password (primary + carried secondary) and swaps it via the setPassword(Password) overload, and matchUserPassword reads user.getPassword() once into a local so both slots come from the same generation. Same treatment for the resolver path: createUserWithoutLock gained a Password-taking variant so resolved-IP users are built with both slots before being published.

This is not backward-readable through the existing OP_ALTER_USER payload. An older FE deserializes the unknown enum name as null, then its switch (opType) throws; EditLog.loadJournal treats that replay exception as fatal and exits. Thus a downgrade from an image whose journal boundary precedes a DISCARD operation is not safe, despite the PR's stated downgrade compatibility. Please use a representation an old reader can safely ignore, or explicitly gate/forbid downgrade after first use and add an old-reader image+journal test.

Fixed — DISCARD OLD PASSWORD now journals via OP_SET_PASSWORD/PrivInfo (discard flag, passwd = the unchanged primary), never OP_ALTER_USER. An older FE replays it as a harmless same-password set; the enum value remains for in-memory dispatch only. Test pins that logAlterUser is never called for DISCARD and that a legacy binary's interpretation of the entry is a no-op.

For ordinary username+remote-IP authentication, this secondary check fails for domain-host accounts. checkPasswordInternal skips the persistent isDomain() entry, while addUserPrivEntriesByResolvedIPs rebuilds the matched IP User from only domainUser.getPassword().getPassword(), creating a fresh Password with no pwd2. After p1 -> p2 RETAIN, the next resolver refresh makes that entry p2-only instead of p2 plus retained p1. Please clone both password slots when materializing resolver-created users and add a domain-account rotation test across a refresh.

Fixed — resolver-materialized IP users are built from a full Password carrying both slots; new test rotates a domain account with RETAIN and asserts the retained password survives a resolver refresh.

The success telemetry is emitted too early. Both callers run checkAccountLockedAndPasswordExpiration only after this helper returns; for an expired or currently locked account, that check throws and the client receives no session, but this line has already logged “authenticated” and incremented secondary_password_auth_total. Please return which slot matched and emit the log/counter only after account policy succeeds, with locked/expired tests proving rejected attempts do not affect success telemetry.

Fixed — matchUserPassword returns the matched slot; the log + secondary_password_auth_total increment happen only after checkAccountLockedAndPasswordExpiration passes. Test locks an account and asserts both slots reject and the counter does not move.

This SET parser test discards the returned command, while the behavioral assertion calls Auth.setPassword(..., true) directly. A SET builder regression—or a downstream SET/ALTER validation, redirect-status, or journal-payload regression—can therefore leave the suite green (ALTER parsing checks its flags, but never executes the command). Please execute the parsed SET and ALTER commands under a suitable ConnectContext, assert their redirect status and emitted PrivInfo/AlterUserOperationLog, and verify the resulting login state and negative privilege cases.

Done — parsed SET PASSWORD ... RETAIN and ALTER USER commands are executed under a ConnectContext with redirect-status, journaled-PrivInfo, login-state, and negative-privilege assertions.

One remaining detail: on an older FE, replaying DISCARD as SET_PASSWORD preserves the primary password value, but still appends password history and resets expiration. The password-policy state therefore changes.

The rest looks good to me. Please also add regression tests for dual-password rotation and discard. Sorry for the late review!

Good catch, thanks. You're right: the primary value survived that replay, but a pre-feature setPasswordInternal still runs passwdPolicyManager.updatePassword, which appends the primary to the history again and refreshes the creation time.

Fixed in 1a08a3c (the branch is also rebased onto current master, and the test class moved to JUnit 5 with the rest of the tree). DISCARD now journals an OP_ALTER_USER entry whose carrier op is SET_PASSWORD_POLICY with every option UNSET, plus a discardOldPasswd marker on AlterUserOperationLog:

• a pre-feature binary drops the unknown field and replays a policy update that changes nothing (ExpirePolicy.update(UNSET), HistoryPolicy.update(null, UNSET) and both FailedLoginPolicy setters return early, and nothing is journaled on replay);
• a current binary reads the marker and drops the secondary password. The policy is not touched on this side either, since DISCARD is not a password change.

A new AlterUserOpType name is still not journaled (an unknown enum name deserializes as null and replay fails), so this keeps the same readable-by-older-binaries property, now without the side effect. PrivInfo.discardPasswd is gone; retainPasswd stays for RETAIN.

Tests:

• DualPasswordTest.testDiscardReplayLeavesPasswordPolicyUntouched replays the entry the way a pre-feature binary sees it (marker dropped, same alterUserInternal path) and the way a current one does, asserting the history size and passwordCreateTime are unchanged in both cases, with the old OP_SET_PASSWORD carrier as the contrast that does change them.
• testDiscardJournalsAsNoOpPolicyEntry pins the journal shape and its GSON round trip.
• New regression suite account_p0/test_dual_password covers rotation (both statement forms), eviction, a plain change leaving the secondary alone, discard, the empty-password rules, the privilege gate on the clause, the password-history and expiration interplay, SHOW CREATE USER, and DISCARD/OLD staying usable as identifiers. Run green against an FE+BE built from the branch.

The concern behind the GRANT gate was a credential parked in this slot that nothing surfaces. After this PR an admin still has no way to see which accounts hold a secondary. SHOW ALL GRANTS / SHOW PROC '/auth' already have a Password column driven by User.hasPassword() (Auth.getAuthInfo), so exposing it is a one-liner there, e.g. Yes (dual). I'd rather have that in this PR than wait for #66198, since it is the auditing half of the same concern.

Added here: Auth.getAuthInfo now prints Yes (dual) while the account holds a retained secondary (via a new User.hasSecondaryPassword()), so SHOW ALL GRANTS, SHOW GRANTS FOR and SHOW PROC '/auth' all show it. Covered in DualPasswordTest and the regression suite across retain, a plain change and discard. The follow-up in #66198 is now only the delegated privilege.

Two small things here.

For a domain account (u@['example.com']) this only clears the domain entry; the resolved-IP entries keep their copy until the next DomainResolver tick (10s) rebuilds them, so the old password stays valid for up to that long after DISCARD. Same lag a plain password change has today, so fine, but the "evict early" wording in the comments does not hold for domain accounts. A note here would save the next reader the trace.

Also this mutates the Password in place while setPassword swaps the whole object. It is safe because both run under the Auth write lock and every auth path holds the read lock, but it contradicts the single-snapshot comment on matchUserPassword. Swapping in a new Password(primary) would keep one rule.

Both taken. discardOldPassword swaps in new Password(primary) instead of clearing the slot, so a password change and a discard follow the same one-snapshot rule, and the javadoc says that a domain account is cleared in its domain entry only, with the resolved-IP entries following at the next resolver refresh (10 s), the same lag a plain password change has. The "evict early" comment in Auth is reworded to match.

One INFO line per connection that authenticates with the secondary. For the fleet-of-agents case in the description this fires on every reconnect until they converge, which can be a lot of log for information the counter already carries. DEBUG here, or keep INFO and accept the volume; just flagging it.

Moved to DEBUG (guarded). The metric carries the count; the line was only ever useful to name the account, and at INFO it would indeed be one line per reconnect for every consumer still on the old password.

Confirmed the pre-feature replay is a no-op for the policy values (every UNSET branch returns early, HistoryPolicy.update skips a null password). The one side effect left is getOrCreatePolicy inserting a default PasswordPolicy for a user that had none. Harmless, but it means the carrier is not strictly a no-op, so worth a word in the Javadoc for whoever next touches SET_PASSWORD_POLICY replay.

Added to the javadoc: the one side effect a pre-feature replay keeps is getOrCreatePolicy inserting a default PasswordPolicy for a user that had none, the same row its next login check would create, so the carrier is a no-op for the policy values rather than for the policy table.

This constructs an AlterUserOperationLog with op = DISCARD_OLD_PASSWORD, which is the one shape the PR promises never to journal; it only works because replayAlterUser falls through to log.getOp(). Use AlterUserOperationLog.discardOldPassword(user) so the test exercises the entry a follower actually sees (same at the second call below).

Right, that op is the one shape the PR never journals. Both call sites now replay AlterUserOperationLog.discardOldPassword(user), so the test sees the same entry a follower does.

Timing is tight here: an 8-second expiry with 5s + 4s sleeps and about six JDBC connects in between leaves roughly 2s for the e1 check after DISCARD to land under 8s. test_alter_user runs with similar margins so not blocking on it, but doubling both the interval and the sleeps would make this less likely to flake on a loaded runner.

Doubled: PASSWORD_EXPIRE INTERVAL 16 SECOND with 10 s + 8 s sleeps, so the check after DISCARD has about 6 s of margin instead of 2.

[P1] Clear retained credentials when authentication bindings change

With a valid bound integration and a local account initially using p1, execute ALTER USER u IDENTIFIED BY 'p2' RETAIN CURRENT PASSWORD, then ALTER USER u IDENTIFIED WITH AUTHENTICATION INTEGRATION bound AS 'external', then ALTER USER u IDENTIFIED BY 'p3'. Both binding transitions reach this no-retain branch, so p1 survives beside the generated bound password and is carried again when the binding is cleared. The final native account unexpectedly accepts p1 as well as p3; the bound-user guard suppresses it only during the external-auth period. Clear local secondary state when the authentication binding changes, reject RETAIN of a bound placeholder, and cover bind/unbind plus replay starting with a retained credential. This also follows the MySQL dual-password rule that changing authentication plugins discards the secondary.

Fixed in 0f8b492: a binding transition (into, out of or between integrations) now discards the retained secondary instead of carrying it (UserManager.setPassword(..., discardSecondary) from Auth.setPasswordInternal, derived from the account's state plus the journal's binding so replay matches), and RETAIN CURRENT PASSWORD is refused into and out of a binding — the current password of a bound account is a generated placeholder. Tests: testBindingTransitionDiscardsRetainedPassword, testRetainIsRefusedAcrossBindingTransitions, testBindingTransitionReplayDiscardsRetainedPassword.

[P2] Preserve the secondary in the immediate domain refresh

For an already resolved domain account, retaining p1 while setting p2 builds both slots here, but the same method then calls refreshAuthenticationBinding at lines 1258-1259. That helper still executes user.setPassword(domain.getPassword().getPassword()) (UserManager.java:523), replacing every resolved-IP entry with a primary-only Password. Clients using p1 are rejected immediately after the successful RETAIN until the next resolver tick; ACCOUNT_UNLOCK and REQUIRE changes can erase the working secondary through the same helper. The earlier domain thread covered the periodic rebuild, which now repairs this separate immediate-copy failure. Copy both slots in refreshAuthenticationBinding too, and test login immediately after RETAIN/unlock/TLS changes without forcing a periodic refresh first; the new domain unit test currently forces that refresh before checking either password.

Fixed in 0f8b492: refreshAuthenticationBinding copies both slots through the new Password.copyOf (the periodic resolver copy uses it too), so the retained password authenticates immediately after RETAIN, ACCOUNT_UNLOCK and REQUIRE changes on a domain account. testDomainRetainAuthenticatesBothSlotsBeforeTheResolverTick asserts the immediate path without a periodic refresh; the existing resolver test keeps covering the periodic one.