[Feature] Dual password support (ALTER USER ... RETAIN CURRENT PASSWORD) for zero-downtime credential rotation #66113

Search before asking

• I had searched in the issues and found no similar issues.

Description

ALTER USER ... IDENTIFIED BY in Doris is a hard cutover: the old password stops working the instant the statement commits. Every client that embeds that account's password must be updated at exactly the same moment, or it fails to authenticate. In practice this means credential rotation requires a maintenance window — or simply never happens.

MySQL 8.0 solved this with dual passwords (WL#11544, documented under Dual Password Support):

ALTER USER u IDENTIFIED BY '<new>' RETAIN CURRENT PASSWORD;  -- old password stays valid
ALTER USER u IDENTIFIED BY '<new>';                          -- (secondary unchanged)
ALTER USER u DISCARD OLD PASSWORD;                           -- evict the retained one

The previous password remains valid as a secondary password until the next rotation (or an explicit DISCARD OLD PASSWORD), so consumers migrate to the new password on their own schedule with zero downtime.

Doris already mirrors MySQL's account-management surface — PASSWORD_HISTORY, PASSWORD_EXPIRE, FAILED_LOGIN_ATTEMPTS, PASSWORD_LOCK_TIME, ACCOUNT_UNLOCK. Dual password is the missing piece: PASSWORD_EXPIRE can force a rotation, but there is currently no way to comply with it online.

Why this matters now — the AI era multiplies machine credentials

Analytical databases like Doris are increasingly accessed not by a handful of applications but by a large and growing population of machine identities: AI agents, MCP servers exposing SQL to LLMs, autonomous data pipelines, notebook and BI tools, and agent frameworks that pass credentials through several layers of tooling. Each holds a long-lived database credential, and each new layer widens the surface on which that credential can leak (tool runners, agent memory, logs, prompt context).

Two consequences make dual password close to a prerequisite for credential hygiene in these deployments:

1. Rotation has to be frequent and automated, and it cannot take a fleet down. Security policy (and, increasingly, compliance regimes) push toward short credential lifetimes. But you cannot coordinate a simultaneous password swap across dozens of autonomous agents and BI connections. An overlap window is the only way to rotate a shared credential online — rotate, let every consumer reconnect on its own cadence, then evict the old secret. A secret manager can drive this end to end only if the engine supports an overlap.

2. Audit attribution must stay clean. The usual workaround for a hard cutover is to alternate between two accounts (e.g. AWS Secrets Manager's "alternating users" strategy). That fragments the audit trail across two usernames — and in an AI setting, where you need to answer "which identity ran this query" from fe.audit.log for every autonomous actor, a stable principal is far more valuable than a rotating one. Dual password keeps one identity with two live secrets; alternating accounts can never do that.

As the number of automated, credential-bearing consumers grows, safe rotation stops being a nice-to-have and becomes a baseline requirement — and dual password is the engine primitive that makes it possible without downtime or audit fragmentation.

Proposed behavior (MySQL-compatible)

Exactly one secondary password per user (the next RETAIN replaces it); RETAIN on an account with an empty primary fails; an empty new password empties the secondary too.

Solution

I have a working FE-only implementation (~420 LOC incl. unit tests) that mirrors the MySQL semantics above, plus an FE metric that counts authentications made with the retained secondary password so operators can confirm every consumer has converged on the new password before evicting the old one. I will open a PR.

Use case

Automated, scheduled credential rotation (driven by a secret manager) for BI tools, service accounts, and AI/MCP consumers that share a Doris account, with convergence verified before the old password is evicted — no maintenance window, no username churn in the audit log.

Related issues

None found.

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct