raghav-reglobe opened a new issue, #66113: URL: https://github.com/apache/doris/issues/66113
### Search before asking - [X] I had searched in the [issues](https://github.com/apache/doris/issues?q=is%3Aissue) 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](https://dev.mysql.com/worklog/task/?id=11544), documented under [Dual Password Support](https://dev.mysql.com/doc/refman/8.0/en/password-management.html)): ```sql 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](https://modelcontextprotocol.io) 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](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html)). 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) | Statement | Effect | |---|---| | `ALTER USER u IDENTIFIED BY 'new' RETAIN CURRENT PASSWORD` | current primary becomes the secondary; both authenticate | | `ALTER USER u IDENTIFIED BY 'new'` | primary replaced; existing secondary unchanged | | `ALTER USER u DISCARD OLD PASSWORD` | drop the secondary, if any | 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? - [X] Yes I am willing to submit a PR! ### Code of Conduct - [X] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
